Re: Java Out of Heap Issue
I consider old code part of application code :) no age discrimination when it comes to memory leaks. What you describe in your memory graph is a simple memory leak. Generally, I would look in that order: 1a. Old code? Look for improperly closed DB connections. 1. Sessions 2. Application code 3. Other webapps p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Out of Heap Issue
On 16/11/2009 23:54, Elli Albek wrote: You can try getting an object dump from a profiler and see which objects are the source of memory starvation. Simple JSPs are very unlikely to cause memory starvation, but you mentioned “application code”, which implies that you have more than simple JSPs. A few things you want to cross off your performance check list, which will not solve your problem, but are generally necessary: 1. JVM -server option, just in case 2. Disable session persistence 3. If you application does not use sessions, disable them for all JSPs (typical place to do it is header JSP include) 4. Force session termination, no long running sessions. 5. Remove all apps that you do not need. Tomcat comes with a few built in apps and those are not trivial to find. Make sure conf/Catalina and all its sub directories contain only apps that you need. Host manager and such should be deleted. Same with war files. What you describe in your memory graph is a simple memory leak. Generally, I would look in that order: 1a. Old code? Look for improperly closed DB connections. 1. Sessions 2. Application code 3. Other webapps p 1 and 3 are easy to deal with. If you don’t need sessions make sure they are not created at all. If you do, force session termination after a few minutes in master web.xml or other XML files. Notice that one file can define a value and another can overwrite it, so you have to make sure all are checked. If that does not work, application code is the next candidate. You can start with an object dump with a profiler or a simple code review/step through in a debugger. E - 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
Java Out of Heap Issue
Hi, I have a Apache-tomcat environment serving simple .jsp's. Issue - After few days of application been up, we see Java heap out of memory error. Steps taken: The Tomcat was configured to run with default heap size. Seeing Java Heap memory issue, i increased it and the setevn.sh file looks like - CATALINA_OPTS='-Xms256m -Xmx256m -XX:+HeapDumpOnOutOfMemoryError -Xloggc:/appl/gcdata/gcdata.txt -XX:+PrintGCDetails' Looking at Garbage Collection graph it is seen - 1 minor Collections spikes to around 1sec after few hrs in between. 2 The maximum and minimum heap size is configured as 256MB, but slowly in couple days, the total heap size reducing automatically and Full Collections becomes frequent to a extend that minor collections stop happening. JVM starts triggering only full collection. just a snapshot of jmap, [r...@saml-app lib]# jmap -heap 8130 Attaching to process ID 8130, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.5.0_18-b02 using thread-local object allocation. Parallel GC with 4 thread(s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 268435456 (256.0MB) NewSize = 2686976 (2.5625MB) MaxNewSize = -65536 (-0.0625MB) OldSize = 1835008 (1.75MB) NewRatio = 2 SurvivorRatio= 8 PermSize = 21757952 (20.75MB) MaxPermSize = 88080384 (84.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 33947648 (32.375MB) used = 15199704 (14.495567321777344MB) free = 18747944 (17.879432678222656MB) 44.77395311745898% used From Space: capacity = 3276800 (3.125MB) used = 1835008 (1.75MB) free = 1441792 (1.375MB) 56.0% used To Space: capacity = 3735552 (3.5625MB) used = 0 (0.0MB) free = 3735552 (3.5625MB) 0.0% used PS Old Generation capacity = 178978816 (170.6875MB) used = 69737192 (66.5065689086914MB) free = 109241624 (104.1809310913086MB) 38.96393638004623% used PS Perm Generation capacity = 21757952 (20.75MB) used = 15172568 (14.469688415527344MB) free = 6585384 (6.280311584472656MB) 69.73343814711973% used JVM is 64bit. Once thing more, the application code is quite old and was running on Java 1.4. Any suggestions Kulbir
Re: Java Out of Heap Issue
You can try getting an object dump from a profiler and see which objects are the source of memory starvation. Simple JSPs are very unlikely to cause memory starvation, but you mentioned “application code”, which implies that you have more than simple JSPs. A few things you want to cross off your performance check list, which will not solve your problem, but are generally necessary: 1. JVM -server option, just in case 2. Disable session persistence 3. If you application does not use sessions, disable them for all JSPs (typical place to do it is header JSP include) 4. Force session termination, no long running sessions. 5. Remove all apps that you do not need. Tomcat comes with a few built in apps and those are not trivial to find. Make sure conf/Catalina and all its sub directories contain only apps that you need. Host manager and such should be deleted. Same with war files. What you describe in your memory graph is a simple memory leak. Generally, I would look in that order: 1. Sessions 2. Application code 3. Other webapps 1 and 3 are easy to deal with. If you don’t need sessions make sure they are not created at all. If you do, force session termination after a few minutes in master web.xml or other XML files. Notice that one file can define a value and another can overwrite it, so you have to make sure all are checked. If that does not work, application code is the next candidate. You can start with an object dump with a profiler or a simple code review/step through in a debugger. E - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Out of Heap Issue
What I have found works well in some circumstances where you do not have a profiler to hand. 1. Look for static declarations in your code that point to singletons or collection objects. They might just grow and grow 2. You may not be using third party libs correctly, e.g. Not closing connections, performing cleanup etc. RTFM just in case. 3. Perform amputations on your code if possible i.e. replace methods with dummy invocations. You will *eventually* find the source of festering objects that are not being gc'd. Tony On Mon, 16 Nov 2009 15:54 -0800, Elli Albek e...@sustainlane.com wrote: You can try getting an object dump from a profiler and see which objects are the source of memory starvation. Simple JSPs are very unlikely to cause memory starvation, but you mentioned “application code”, which implies that you have more than simple JSPs. A few things you want to cross off your performance check list, which will not solve your problem, but are generally necessary: 1. JVM -server option, just in case 2. Disable session persistence 3. If you application does not use sessions, disable them for all JSPs (typical place to do it is header JSP include) 4. Force session termination, no long running sessions. 5. Remove all apps that you do not need. Tomcat comes with a few built in apps and those are not trivial to find. Make sure conf/Catalina and all its sub directories contain only apps that you need. Host manager and such should be deleted. Same with war files. What you describe in your memory graph is a simple memory leak. Generally, I would look in that order: 1. Sessions 2. Application code 3. Other webapps 1 and 3 are easy to deal with. If you don’t need sessions make sure they are not created at all. If you do, force session termination after a few minutes in master web.xml or other XML files. Notice that one file can define a value and another can overwrite it, so you have to make sure all are checked. If that does not work, application code is the next candidate. You can start with an object dump with a profiler or a simple code review/step through in a debugger. E - 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
RE: Java Out of Heap Issue
From: kulbir Saini [mailto:kulbir.sai...@gmail.com] Subject: Java Out of Heap Issue just a snapshot of jmap, Try using jhat to actually see what's consuming the space in the heap. Heap Configuration: MaxNewSize = -65536 (-0.0625MB) That looks suspicious... Heap Usage: PS Young Generation Eden Space: 44.77395311745898% used From Space: 56.0% used PS Old Generation 38.96393638004623% used PS Perm Generation 69.73343814711973% used None of the above show full heap utilization, so the heap dump you have does not seem representative of the situation you describe. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
