tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: java.lang.OutOfMemoryError: PermGen space
Date Fri, 21 Oct 2016 18:50:01 GMT
Hash: SHA256


On 10/21/16 3:46 AM, Moore, Jon, Vodafone UK wrote:
> Yes I am a novice at Java as well. I support the IVR system that 
> points to the application servers and have ended up trying to
> resolve this issue as our developers of the applications can't
> help.

Understood. Welcome to the Java world. :)

> The way we are told on the training to deploy the application in
> the IVR is to use the deploy/un-deploy options in tomcat manager. I
> have also seen a colleague make a copy of the applications war file
> away from its normal folder (webapps), stop the tomcat Windows
> service, delete the applications deployed folder and restart the
> tomcat windows service to re-deploy the application.

Since you are using manager-based deply/undeploy, you could very well
be running into a classloader-pinning error. If there's no hope of
modifying the code to fix any leaks, the only remedy is to bounce the
entire JVM after a certain number of redeploy operations. If you find
that you can redeploy 10 times before you get permgen OOMEs, then
you'll need to keep a count and restart after e.g. 8 redeployments.

If you *can* fix the code, the manager has a "find memory leaks"
button that can help you find out if an application has not undeployed
properly: deploy the application in a fresh Tomcat start-up. Then,
undeploy the application, wait 5-10 seconds, and click the "find
memory leaks" button. If it syas there are no leaks, then you may just
need a slightly larger permgen in general and you'll be fine.

If it says there are problems, start a new thread on this mailing list
asking for help identifying and fixing those leaks.

> I have tried to run the commands you suggested from a CMD box but 
> nothing gets outputted.


Try NOT piping-through the FINDSTR program and looking at the output
of the initial "java" command. I don't have a Windows system to play
with ATM so I'm doing a bit of guesswork, here. "FIND" is garbage
compared to a proper "grep". I had never even heard of FINDSTR before.

- -chris

> -----Original Message----- From: Christopher Schultz 
> [] Sent: 20 October 2016 17:40
> To: Tomcat Users List Subject: Re: java.lang.OutOfMemoryError:
> PermGen space
> Jon,
> On 10/20/16 6:00 AM, Moore, Jon, Vodafone UK wrote:
>> I have a problem where our customers application server stops 
>> working intermittently and when we check the Tomcat logs we get
>> the message " java.lang.OutOfMemoryError: PermGen space" but the
>> Tomcat service is still running, and we have to restart the
>> Tomcat service. I am a complete novice when it comes to Tomcat
>> but am expected to resolve this issue as this server is part of
>> the Avaya telephony solution.
>> I have 2 questions please.
>> 1 - What would be causing this.
> Are you also a Java novice as well? No judgement... I just want to 
> adjust my level of snark appropriately :)
> Java has a special heap space called the "permanent generation" (a 
> term which becomes less descriptive as time goes on) but basically 
> all java.lang.Class objects loaded by the JVM go there. The more 
> libraries and other stuff that gets loaded, the more space in
> permgen is used. The defaults for the size of permgen are often
> fairly small, and you may have to raise them. This is especially
> true for applications that use large frameworks like Spring.
> Raising the permgen space is almost always the right decision
> under normal circumstances when you get an OOME:permgen error. I
> would double whatever its current value is and monitor the
> application for a while to see if that improves things.
> The only situation I know of where raising the permgen size is not 
> the right move is when there is a "classloader-pinning leak". That 
> happens when you hot-deploy an application many times, but the old 
> versions of the application are not undeploying cleanly. This 
> situation is quite the rabbit-hole, so I'll stop there unless you
> can confirm that you do hot-deployments without restarting Tomcat
> and the JVM.
> If you instead get OOME for other reasons, it's frequently NOT the 
> right decision to increase the heap size because it usually
> indicates that there is a memory leak in the application and giving
> it more heap just means you'll wait longer between failures.
> Instead, the application should be fixed to not leak memory :)
>> 2 - What are the default Java memory settings for Initial memory 
>> pool, maximum memory pool size and thread stack size when the 
>> fields are blank when you use the "Configure Tomcat" interface
>> on Windows. I was wondering if changing one or more of these
>> settings would help ?
> The default depends upon the JVM and the OS.
>> We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard
>> and JVM version is 1.6.0_20-b02
> Best way to find out for sure[1] is:
> C:\> java -XX:+PrintFlagsFinal -version 2>&1 | findstr HeapSize
> The two settings you are looking for are MaxHeapSize and 
> InitialHeapSize. Those values are in bytes, so you'll probably
> have to divide by 1024 a couple of times to get at the "real" value
> in human-readable terms.
> The best way to find the default permgen size is:
> C:\> java -XX:+PrintFlagsFinal -version 2>&1  | findstr PermSize
> Hope that helps, -chris
> [1] 
- -h
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message