tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: 100% CPU Usage when stopping Tomcat after OOM condition
Date Wed, 04 May 2011 05:07:09 GMT

"Christopher Schultz" <> schrieb:

>Hash: SHA1
>On 5/3/2011 10:52 AM, Mark Thomas wrote:
>> On 03/05/2011 15:46, André Warnier wrote:
>>> Mark Thomas wrote:
>>>> On 03/05/2011 15:22, Christopher Schultz wrote:
>>>>> All,
>>>>> Moments ago in our development environment, our webapp suffered an
>>>>> after many re-reployments (we know we have an undeploy-related
>>>>> When attempting to bounce Tomcat, the shutdown failed and I took a
>>>>> thread dump which included the one non-trivial thread shown below.
>>>>> I haven't looked at the code yet to see if there is some kind of
>>>>> around this code, but top reported 100% CPU usage from this
>process so I
>>>>> suspect something like that was happening.
>>>>> We are using TC 6.0.32 on Debian Lenny and Sun/Oracle 32-bit
>>>>> 1.6.0_22-b04 Server VM.
>>>>> This is less of a "help" request as it is an observation of an
>>>>> unfortunate situation: the OOME is clearly the real problem and
>>>>> nothing to do with Tomcat itself. Unfortunately, after the OOME,
>>>>> was unable to shut down gracefully and that could be a problem in
>and of
>>>>> itself.
>>>> After an OOME there are no guarantees as to the state of the JVM.
>>>> Tomcat is unable to shut down cleanly in that case is not
>Chuck's assertion is that an OOME isn't fatal to the JVM but almost
>always fatal to the application since it's unlikely equipped to handle
>the bizarre situations that arise from it's occurrence. A bit of a
>hair-split if you ask me, but it's always worth examining any options
>has to at least be able to stop itself gracefully.
>>> Do I not remember seeing somewhere, at some point, a parameter named
>>> "OOMParachute" or similar ?
>> Yes, in the NIO connector. It may, or may not, provide the JVM with
>> enough memory to exit gracefully.
>Since this is a PegmGen issue, it's unlikely that the NIO connector's
>OOM parachute will help, here. Also, I'm not using the NIO connector :)
>Any reason the parachute is in the /connector/ and not somewhere more
>I was mostly interested in why I was getting 100% CPU usage... checking

It could've been the garbage collector itself. Just yesterday I had an oom on permgen, which
lead to a major-gc loop.
I could see the loop nicely as I had enabled logging of gc activity with -Xloggc:$CATALINA_BASE/logs/gc.log
-XX:+PrintGCDetails -XX:PrintGCTimeStamps

>the code, I *do* see a loop in
>WebappClassLoader.clearReferencesStaticFinal but it's over an iterator
>that will presumably run out of entries. The CPU spike seems to be
>happening within the native code in java.lang.Class.getDeclaredFields,
>so there's nothing TC can do to prevent it. :(
>- -chris
>Version: GnuPG v1.4.10 (MingW32)
>Comment: Using GnuPG with Mozilla -
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message