-----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:ch...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
