Once you rule out your heap and perm generation, you can look at thread stacks.
Under high loads, you create a lot of threads. There are variations depending on the host OS and VM, but in a 32-bit operating system with thread stacks in the 1-4 MB range and a big heap, you can easily run out of virtual address space. In addition, I'm not sure if there aren't some cases where thread stacks are allocated reserved, which means you could also get an OOME from not having enough swap space. If you think this might be it, try tuning your thread pools (lower the max pool size), lowering perm gen size, heap size, switching to 64-bit, adding swap... "Dale, Matt" <[EMAIL PROTECTED]> wrote on 02/07/2005 07:34:36 AM: > > In that case then it sounds like either a memory leak or you just > don't have enough memory to support your application. Do you have > large objects in your sessions? > > I'd get a profilier and find out what objects are in your heap when > you get the exceptions and it should lead you to the root cause of > your problem. > > Ta > Matt > > -----Original Message----- > From: Michael Cornell [mailto:[EMAIL PROTECTED] > Sent: 07 February 2005 12:01 > To: Tomcat Users List > Subject: Re: outOfMemory exception under high load > > > Hi, > > RE Matt: > // > I am already running visualgc (jvmstat) on it... the behavior is just > that the heap fills up (no gc) and then at about 80% full it just bombs > out. Perm Gen is only 20% full and none of the others are used.. > > RE reynir: > Why are you setting these paremeters : > -Xmn384m -XX:SurvivorRatio=7 -XX:PermSize=64m > -XX:MaxPermSize=128m -Xint > > I usually only set the -Xmx and -server > // > The Permsize params have been put in in case that was the problem > (running out of perm space) and the -Xint as this makes it run without > any optimisations (I believe) ie all interpreted. > Xmn is the New Generation= (eden) + (from + to) and survivor ratio is > just that.. the ratio of eden - survivors > I can see no reason why these should mess anything up sufficiently to > produce this error. > > > > > Dale, Matt wrote: > > >It could be your permanent generation that is running out of space. > Get a hold of jvmstat to determine if this is the case. > > > >Ta > >Matt > > > >-----Original Message----- > >From: Michael Cornell [mailto:[EMAIL PROTECTED] > >Sent: 07 February 2005 11:31 > >To: Tomcat Users List > >Subject: Re: outOfMemory exception under high load > > > > > > > >Sorry, that was a copy and paste typo :( Its set at 2G (4G for the > >whole machine) > >/m > > > >reynir wrote: > > > > > > > >>well, your -Xmx1G set's the limit for memory usage at 1 gig. ? > >>-server -Xms1G -Xmx1G -Xmn384m -XX:SurvivorRatio=7 -XX:PermSize=64m > >>-XX:MaxPermSize=128m -Xint > >> > >>you might want to set that a little higher. > >> > >> > >>Michael Cornell wrote: > >> > >> > >> > >>>Not exactly sure but by running vmstat, it look like I am nearing the 2G > >>>limit .. maybe about 1.8G consumed.. > >>> > >>>/m > >>> > >>>reynir wrote: > >>> > >>> > >>> > >>> > >>> > >>>>how much memory is your process using when it crashes ? > >>>>-r > >>>> > >>>> > >>>>Michael Cornell wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>Hi, > >>>>> > >>>>>I am experiencing a problem many others seem to have had before, but > >>>>>have found no answers. I am running Tomcat 5.0.25 using jdk 1.4.2_06 > >>>>>hotspot vm on RedHat Linux ES with 4G Ram and twin Intel procs. > >>>>> > >>>>>When load-testing, under high stress I receive the error below and the > >>>>>thread dies. > >>>>> > >>>>>04-Feb-2005 13:39:24 org.apache.coyote.tomcat5.CoyoteAdapter service > >>>>>SEVERE: An exception or error occurred in the container during the > >>>>>request processing > >>>>>java.lang.OutOfMemoryError > >>>>> at java.util.zip.ZipFile.open(Native Method) > >>>>> at java.util.zip.ZipFile.<init>(ZipFile.java:112) > >>>>> at java.util.jar.JarFile.<init>(JarFile.java:127) > >>>>>.. > >>>>> > >>>>>I have adjusted the vm parameters to the below ( the perm space > >>>>>does not > >>>>>get full and the Xint to not use the optimised settings.. > >>>>>-server -Xms1G -Xmx1G -Xmn384m -XX:SurvivorRatio=7 -XX:PermSize=64m > >>>>>-XX:MaxPermSize=128m -Xint > >>>>> > >>>>>In addition I have added the" reloading=false and > >>>>>development=false in > >>>>>conf/web.xml. " as per instruction from this thread: > >>>>>http://www.junlu.com/msg/78566.html > >>>>> > >>>>>My connector is configured thus: > >>>>> <Connector > >>>>> port="80" > >>>>> maxThreads="1000" > >>>>> minSpareThreads="1000" > >>>>> maxSpareThreads="1000" > >>>>> enableLookups="false" > >>>>> redirectPort="8443" > >>>>> acceptCount="3000" > >>>>> debug="0" > >>>>> connectionTimeout="20000" > >>>>> disableUploadTimeout="true" /> > >>>>> > >>>>> > >>>>>However all of this is to no avail, and under high stress (80+ > >>>>>concurrent requests, tomcat dies and terminates the thread dumping a > >>>>>hs_pid12345.log with the above message > >>>>> > >>>>>Is this a known hotspot 1.4.x problem (some threads have hinted at > >>>>>this), or does someone have a solution for this?? > >>>>> > >>>>>Thanks, > >>>>> > >>>>>M > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > >------------------------------------------------------------------------ > > > >Any opinions expressed in this E-mail may be those of the > individual and not necessarily the company. This E-mail and any > files transmitted with it are confidential and solely for the use of > the intended recipient. If you are not the intended recipient or the > person responsible for delivering to the intended recipient, be > advised that you have received this E-mail in error and that any use > or copying is strictly prohibited. If you have received this E-mail > in error please notify the beCogent postmaster at [EMAIL PROTECTED] > >Unless expressly stated, opinions in this email are those of the > individual sender and not beCogent Ltd. You must take full > responsibility for virus checking this email and any attachments. > >Please note that the content of this email or any of its > attachments may contain data that falls within the scope of the Data > Protection Acts and that you must ensure that any handling or > processing of such data by you is fully compliant with the terms and > provisions of the Data Protection Act 1984 and 1998. > > > > > > > > > >------------------------------------------------------------------------ > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > [attachment "InterScan_Disclaimer.txt" deleted by David > Wood/TheStreet.com/US] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
