I am working on a project to convert a handful of J2EE applications from an Oracle OC4J application (no longer supported) server to JBoss 5.1.0. Among the many challenges in the conversion is the fact that JBoss’s default profile has a significantly larger memory footprint than OC4J. In the past I have just accepted that Jboss uses over 400MB of heap space before you even deploy anything. This time however we were hoping to reuse the same hardware from the old application server with the new application server. When the test system started paging and eventually using up all of the physical memory available, we were forced to choose between ordering more memory and trying to tune jboss to reduce the memory footprint.
We ended up having a lot of success reducing the footprint through tuning. Bottom line: we reduced the memory footprint by 120MB, and the startup time from 53s to 24s
Here were the steps taken
|Heap Size (MB)||Used (MB)||Reduction in Used (MB)|
|commented out debug level MBeans annotation in deployers.xml||322||247||67|
|removed ejb3 services||317||238||9|
|removed messaging folder & props||310||238||0|
|removed seam & admin-console||256||205||33|
|Removed xnio-deployer and xnio-provider||256||203||2|
The instructions for each step can be found : http://community.jboss.org/wiki/JBoss5xTuningSlimming
Notes on my environment and testing process:
- Windows XP, JDK 1.6.0_22,
- JBoss 5.1.0.GA. Xmx=512M , Xmx=256 (this is why heap didn’t drop below 256)
- I used jvisualvm to watch the heap and “used” memory values
- For the “Used” memory, I took the maximum observed value while JBoss was starting. If you understand that a time vs. memory usage graph follows a sawtooth pattern as objects are instantiated and garbage collected, then I took the value from the tip of the highest tooth.