I found exactly the same thing ( memory usage climbing) but when I removed the -Xincgc it's all OK memory useage fine etc etc etc ...
D Matthew Boeckman wrote: > We have figured this out, although for the life of me I can't > understand why. We had been running with java -server -Xms128m > -Xmx256m -Xincgc and saw the VM climb way up to 2GB, then drop the > tomcat process. > > By removing the -server flag, everything is fine. I realise this means > that the JVM is defaulting to 'client'... so I guess is anyone aware > of memory holes in the 1.3.1 JVM on linux? I've dug around deja &c and > seen a few references to this suspicion but nothing concrete. > > I'm going to start working on Tomcat 4 and jdk1.4.0 in my lab this > morning, hopefully the problem is fixed in 1.4.0! > > Thanks for all the responses! > > > Jari Ikavalko wrote: > >> Hi Matthew and co., >> >> have you tried to examine tomcat -behaviour with a profiler? I tried >> with >> OptimizeIt, and it seems to me that the Garbage Collector doesn't free >> memory that is reserved for sessions. I mean that session itself ends >> ok, >> but the gc just won't free the memory. >> >> Does anyone else have noticed something similar? >> >> My system: >> Windows 2000 >> JDK 1.4.0 >> Tomcat 4.0 >> >> -- Jari Ik�valko -- >> >> >> On Wed, 1 May 2002, Matthew Boeckman wrote: >> >> >>> Are you running java 1.3 or 1.4 ? We're really trying to nail this >>> down. We've had the Xms and Xmx options in place now for some time, >>> and the java proc just grows right past Xmx, up to nearly full >>> system memory, then tomcat dies. >>> >>> I'm ready to hear any suggestions, but I want to try to narrow the >>> scope somewhat. >>> >>> Laurent F�ral-Pierssens wrote: >>> >>>> Hi Matthew, >>>> >>>> I have been experiencing the same problems but with T3.2.x. >>>> >>>> You should try to use Tomcat options -Xms and -Xmx >>>> >>>> I added those 2 lines: >>>> >>>> TOMCAT_OPTS="-server -Xms256m -Xmx256m -Xincgc" >>>> export TOMCAT_OPTS >>>> >>>> in my /etc/init.d/tomcat script >>>> This increase the default heap size of the JVM to 256Meg (from 64Meg) >>>> and make sure incremental Garbage collection is done. Since I changed >>>> those, I have no more OutOfMemory errors. >>>> >>>> Hope it helps, >>>> Laurent >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Matthew Boeckman [mailto:[EMAIL PROTECTED]] Sent: May 1, >>>> 2002 12:08 PM >>>> To: [EMAIL PROTECTED] >>>> Subject: OutofMemoryError >>>> >>>> >>>> Hello List. >>>> >>>> I'm running tomcat 3.1.1 on RH7.1, kernel 2.4.9-31 with JDK1.3.1, >>>> mysql 3.23.43 >>>> I am occasionally seeing tomcat go postal with the following errors: >>>> Exception in thread "CompileThread0" java.lang.OutOfMemoryError: >>>> requested 32760 bytes >>>> >>>> >>>> **************** >>>> Another exception has been detected while we were handling last error. >>>> No information available. Please check ERROR REPORT FILE for further >>>> information, if there is any. Good bye. >>>> >>>> An unexpected exception has been detected in native code outside >>>> the VM. >>>> Unexpected Signal : 11 occurred at PC=0x419852cb Function name=(N/A) >>>> Library=(N/A) >>>> >>>> NOTE: We are unable to locate the function name symbol for the error >>>> just occurred. Please refer to release documentation for >>>> possible >>>> reason and solutions. >>>> >>>> >>>> Current Java thread: >>>> >>>> >>>> **************** >>>> Another exception has been detected while we were handling last error. >>>> Dumping information about last error: ERROR REPORT FILE = (N/A) >>>> PC = 0x0x419852cb >>>> SIGNAL = 11 >>>> FUNCTION NAME = (N/A) >>>> LIBRARY NAME = (N/A) >>>> Please check ERROR REPORT FILE for further information, if there is >>>> any. >>>> Good bye. >>>> >>>> Any thoughts on what might be the cause? There is nothing in the >>>> log files to tell me more than this, which gets dumped to the console. >>>> >>>> -Thanks! >>>> >>> >>> >>> -- >>> Matthew Boeckman (816) 777-2160 >>> Manager - Systems Integration Saepio Technologies >>> == == >>> ...Many say that DOS is the dark side, but actually UNIX is more >>> like the dark side: It's less likely to find the one way to destroy >>> your incredibly powerful machine, and more likely to make upper >>> management choke. >>> -Lore Sjoberg >>> >>> >>> -- >>> To unsubscribe: <mailto:[EMAIL PROTECTED]> >>> For additional commands: <mailto:[EMAIL PROTECTED]> >>> Troubles with the list: <mailto:[EMAIL PROTECTED]> >>> >> >> >> -- >> To unsubscribe: <mailto:[EMAIL PROTECTED]> >> For additional commands: <mailto:[EMAIL PROTECTED]> >> Troubles with the list: <mailto:[EMAIL PROTECTED]> >> >> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
