tomcat-users mailing list archives

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

Jon,

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.

Hmm.

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 
> [mailto:chris@christopherschultz.net] 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] 
> http://stackoverflow.com/questions/2915276/what-is-the-default-maximum
- -h
>
>
> 
eap-size-for-suns-jvm-from-java-se-6
> 
> ---------------------------------------------------------------------
>
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
>
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYCmNYAAoJEBzwKT+lPKRYT90P/jPh8rDdBNEamXBXLzAEkSE2
UVObMtiM64RY6eJg5i+Rv0O5UWXH9HZuEofqMbyArbSfAWjraCymA0e0pfI4MzNu
FpOSBbBQyGXTfQzA2uyOwytMVmG5pARz21mWFF5VDQr2P+wFU+Dyp+vBdKJo+FZ2
Y0V5trVKon7ou6qpOUn8pAoT+P0qUxr2J5in2I2ilBBNORi4Pwuzbs2Xver0ktUL
eqtpDveRFyvq9ewXtE1k92o6WF0eEMqFZ/BJX7bP21087wqJwDf7MLmFnzdLhHMV
yJqrdKzI24Vj5cTSgVyWLVvM2MmL5iDfPurpY4yQFHw56ZSvo9fSZsrUM8UYbvOc
ujeJcaPXZU3+jNm5UvVw1PIZmUDvAsYC4y06kxc+L5A7pikTFuOAWc9MlxSw3mbR
E2/BRFgzk1OXE73LuVjIEaBhwFnJ/telA2r42dw38SkNvH7GZl6Yn9FoYsq7gVXQ
7RS3PNoQFeGzS8saaXv2GaemLoceRxQOodQYBh0e2Xb5RJ8s8HqiJPgSP8VxqfQU
fbwGJ91z7Er7SLsEJGE78M31uJsfcagyc6rUIJ7b5Z+F/Q6CV7vzUCU0gWnRugds
+Bzv3B1kVqrpLSPBbO6idObD7+Was9OKzrYMiYAWd6BIlYs8ElT0FIyLRWmQcf2S
YIOJpeQHwiONWEQkJj53
=2zin
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message