[jboss-jira] [JBoss JIRA] Commented: (JBVFS-159) Native memory leak due to ZipEntryInputStream
[
https://jira.jboss.org/browse/JBVFS-159?page=com.atlassian.jira.plugin.sy...
]
Samuel Cai commented on JBVFS-159:
----------------------------------
Hi Marko, I did some tests locally:
Start JBoss (with our war deployed), and do nothing in 10 mins, test three times.
I monitor three values: Mem Usage, Peak Mem Usage, VM Size.
Original:
Mem Usage: 470M-700M after deployment, wide range, every time is totally different. After
about 5 mins, drop to around 10M suddenly, and then increase slowly.
Peak Mem Usage: up to 750M
VM Size: 950-1150M after deployment, wide range, every time is totally different. Almost
no changes later.
My patch:
Mem Usuage: around 550M after deployment. It drops to around 10M suddenly after several
mins, and then increase slowly.
Peak Mem Usage: around 550M.
VM Size: around 930M after deployment. Almost no changes later.
Your patch:
Mem Usuage: around 700M after deployment. It drops to around 10M suddenly after several
mins, and then increase slowly.
Peak Mem Usage: around 750M
VM Size: around 1089M after deployment. Almost no changes later.
I'm using Windows XP and 2 cores CPU, seems windows manages Mem Usage and VM Size
better, but test result still indicates that not closing stream will result in higher VM
Size.
JVM startup parameter: -Xss128k -Xmn250m -XX:PermSize=128m -XX:MaxPermSize=128m -Xms750m
-Xmx750m -server
Could you do some more tests on windows, maybe you'll see the Mem Usuage dropped too.
Also about your patch, you mentioned that it's not for prod, how can we make it for
prod?
Thanks,
Samuel
Native memory leak due to ZipEntryInputStream
---------------------------------------------
Key: JBVFS-159
URL: https://jira.jboss.org/browse/JBVFS-159
Project: JBoss VFS
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.1.2.GA
Environment: Redhat (not sure what version) 2.6.9-78.ELsmp
JBoss 5.1.0.GA
JDK 1.6.0_20
JVM parameter:
-XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -verbose:gc
-Dfile.encoding=iso-8859-1 -server -Djava.net.preferIPv4Stack=true
-Doracle.jdbc.V8Compatible=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000 -Dnetworkaddress.cache.ttl=300 -Xss128k -Xmn500m
-Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -XX:+PrintGCDetails
-XX:PermSize=256m -XX:MaxPermSize=256m -Xms1500m -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError
-XX:+UseConcMarkSweepGC
Reporter: Samuel Cai
Assignee: Marko Strukelj
Attachments: change.tar.gz, JBVFS-159.patch, leakdetector.jar, test.zip,
VFSZipMemoryTestCase.java
We used to use JBoss 4.2.1.GA and JDK 1.6.0_11, and trying JBoss 5.1.0.GA and JDK
1.6.0_20 these days.
I found the process size is more larger than before, 2.5G~2.9G compared to 1.9G.
I was thinking this was a bug of JBoss AS, then filed
https://jira.jboss.org/browse/JBAS-8066
After these days investigation, I think this is a memory leak in VFS, maybe only happen
on our specific environment.
I tried a change on class org.jboss.virtual.plugins.context.zip.ZipFileWrapper, method
openStream:
From:
ZipEntryInputStream zis = new ZipEntryInputStream(this, is);
return zis;
To:
//ZipEntryInputStream zis = new ZipEntryInputStream(this, is);
//return zis;
return is;
That is, don't use ZipEntryInputStream, let any class/method invoking openStream to
close zipFile's inputStream immediatelly.
ZipFile will be in open status, but all steams will be closed well.
This makes the process size down to same as JBoss 4's. I tried going through first 3
pages of site, no problems. May need QA team to test more.
Btw, I tried updating VFS to 2.1.3.SP1/2.2.0.M4/3.0.0.CR5, first two have same size
issue, third one couldn't start.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira