Exception java.lang.OutOfMemoryError: requested 36616 bytes for Chunk::new. Out of swap space

[Keith Holdaway]

We are running our Portal endurance LoadRunner test and we noted that after 17 hrs we fail with the following error message:

Exception java.lang.OutOfMemoryError: requested 36616 bytes for Chunk::new. Out of swap space?

Assuming this to be a native heap issue I told them to reduce the Java heap and the perm Gen and cut back on -Xss thread stack size to alleviate the pressure on the native heap:

 -Xms1000m -Xmx1000m -XX:PermSize=87m -XX:MaxPermSize=87m -Xss96k -XX:-UseTLAB -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:NewSize=128m -XX:MaxNewSize=128m -Dcom.sun.management.jmxremote -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true -Dsas.svcs.http.max.connections=50

This lasted 24 hrs and then failed with the same error as stated above.

I noted CMS was being curtailed the majority of the time, and that most of the short-lived objects were being immediately promoted, so I adjusted again, by adding the following to the above:

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=30 -XX:SurvivorRatio=4 and -XX:MaxTenuringThreshold=4

This lasted 42 hrs, and then the same failure.

We have run with JDK 6.0 successfully for longer, but unfortunately, owing to the application servers we have to support such as WebLogic, we cannot support JDK 6.0.

Do I keep reducing the CMS initiating occupancy down to something similar to iCMS? - perhaps increase the NewSize to keep the short-lived objects around longer?

Does the error message indicate ONLY native heap issues - perhaps a memory leak with some of the third party software such as STRUTS, Spring Framework etc.

thanks

keith