You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2008/09/08 21:48:17 UTC
DO NOT REPLY [Bug 45765] New: Heap size is growing
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
Summary: Heap size is growing
Product: Tomcat 6
Version: 6.0.16
Platform: HP
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: barak@peer39.com
I'm running Tomcat 6.0.16 on CentoOS 5, linked with native library, with
-security flag. I deployed a Servelt, which on invocation executes an RMI call
to a remote RMI server. Tomcat configured with max heap size of 2G
After short time of running under heavy load, the memory consumption reported
by top is close to 2G. jmap output is:
Attaching to process ID 20248, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.6.0-b105
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 2147483648 (2048.0MB)
NewSize = 1048576 (1.0MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 4194304 (4.0MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 16777216 (16.0MB)
MaxPermSize = 268435456 (256.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 582221824 (555.25MB)
used = 0 (0.0MB)
free = 582221824 (555.25MB)
0.0% used
>From Space:
capacity = 48103424 (45.875MB)
used = 48079216 (45.85191345214844MB)
free = 24208 (0.0230865478515625MB)
99.9496751000511% used
To Space:
capacity = 69402624 (66.1875MB)
used = 0 (0.0MB)
free = 69402624 (66.1875MB)
0.0% used
PS Old Generation
capacity = 1431699456 (1365.375MB)
used = 1424597528 (1358.6020736694336MB)
free = 7101928 (6.772926330566406MB)
99.50395119798104% used
PS Perm Generation
capacity = 35782656 (34.125MB)
used = 28493056 (27.173095703125MB)
free = 7289600 (6.951904296875MB)
79.62811927655677% used
I've dump a file using jmap, and asked MemoryAnalyzer (www.eclipse.org/mat) to
take a look. This tool reported that an instance of java.security.Policy
retained 77.7% of the heap (552,569,816 bytes). Looks like a leak...
I will try to run without SecurityManager, and see whether this is impacting
the results.
Barak.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45765] Heap size is growing
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
Barak <ba...@peer39.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |barak@peer39.com
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #2 from Barak <ba...@peer39.com> 2008-09-12 01:41:15 PST ---
This kind of memory foot print does not exist in standalone java application
running with security manager, and performing the same logic described in the
bug.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45765] Heap size is growing
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
--- Comment #5 from Mark Thomas <ma...@apache.org> 2008-09-14 07:09:07 PST ---
The ideal information would be the steps to reproduce this issue on a clean
Tomcat installation. Failing providing the hprof output obtained from JMap
(either attach it or provide it via a URL) would enable others to analyse it to
ID the source of the leak.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45765] Heap size is growing
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
--- Comment #4 from Barak <ba...@peer39.com> 2008-09-14 00:55:14 PST ---
Please advice - what kind of relevant information should I attached to the bug?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45765] Heap size is growing
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #3 from Mark Thomas <ma...@apache.org> 2008-09-12 01:59:39 PST ---
This remains no information in this report that demonstrates that Tomcat is the
root cause of the leak. Neither is there sufficient information for someone to
try and reproduce it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45765] Heap size is growing
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45765
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> 2008-09-08 13:43:45 PST ---
That isn't enough information to prove a memory leak in Tomcat as nothing in
this report relates to Tomcat classes.
To be a Tomcat leak there needs to be a chain of references back to a Tomcat
class.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org