Tuning a Sun Java System Application Server

The “Tuning the Application Server” chapter, in the latest Sun Java System Application Server Performance Tuning Guide, contains information about tuning a Sun Java System Application Server. This document is available from the following URL at http://docs.sun.com/app/docs.

In addition, if you are using Sun Java System Application Server 8.2 Enterprise Edition, the following changes solve “concurrent mode failures,” and should give you better and more predictable performance:

• If you are constantly running old generation collections, review your application’s heap footprint and consider increasing the size. For example:

  • 500 Mbytes is considered a modest size, so increasing this value to 3 Gbytes might improve performance.

  • With a 2–Gbyte young generation collection, each scavenge promotes about 70 Mbytes. Consider giving this 70 Mbytes at least one more scavenge before promoting. For example, you might need the following SurvivorRatio:

    2 GB/70 M X 2 = 4096/70 = 55

    where:

    -XX:SurvivorRatio=32 -XX:MaxTenuringThreshold=1

    This ratio prevents premature promotion and the added problem of “nepotism,” which can degrade scavenge performance.

• If you specified -XX:CMSInitiatingOccupancyFraction=60, and the CMS collections are still starting before they reach that threshold. For example:

  56402.647: [GC [1 CMS-initial-mark: 265707K(1048576K)] 1729560K(3129600K), 3.4141523 secs]

  Try removing -XX:CMSInitiatingOccupancy=60 (using the default value of 69percent), and add the following line:

  -XX:UseCMSInitiatingOccupancyOnly

• If your young generation collection is 2 Gbytes and the old generation collection is 1 Gbyte, this situation might also be causing premature CMS collections. Consider reversing this ratio. Use a 1–Gbyte young generation collection and a 2–Gbyte old generation collection, as follows

  -Xms3G -Xmx3G -Xmn1G

  Also, remove -XX:NewRatio. This ratio is redundant when you have explicitly specified young generation and overall heap sizes.

• If you are using a 5uXX version of the Java Development Kit (JDK^TM software), and have excessively long “abortable preclean” cycles, you can use -XX:CMSMaxAbortablePrecleanLoops=5 as a temporary workaround.

You might have to adjust this value further.

• Add the following line to view more information about garbage collector performance.

  -XX:+PrintHeapAtGC

  ---

  Note –

  Use this command with caution because it increases how much verbose garbage collection data is produced. Be sure that you have enough disk space on which to save the garbage collector output.

  ---

• If you are using the Sun Fire^TM T2000 server, large-heap data Translation Look-aside Buffers (DTLBs) can become a scarce resource. Using large pages for the Java heap often helps performance. For example:

  -XX:+UseLargePages