You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by kulbir Saini <ku...@gmail.com> on 2009/11/16 23:52:25 UTC
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,
[root@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
Posted by Elli Albek <el...@sustainlane.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Java Out of Heap Issue
Posted by Pid <pi...@pidster.com>.
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-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
Re: Java Out of Heap Issue
Posted by Anthony Jay <an...@fastmail.fm>.
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" <el...@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-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
Re: Java Out of Heap Issue
Posted by Elli Albek <el...@sustainlane.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Java Out of Heap Issue
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: kulbir Saini [mailto:kulbir.saini1@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org