The IBM JVM 1.5 or later has a 'stop the world' garbage collector while JVM1.4 used parallel CG. IBM says that the locking issues in parallel GC cause more performance problems than it solves and also has thread scalability issues.
My own experience is that the heap size tuning knob for the IBM JVM 'operates backward'. That is, increasing the heap size actually slows applications down. While I have never tuned JBOSS, when I tune Websphere, I have found that it runs best with remarkably small heaps - typically less than 256MB. Basically, I turn on verboseGC and adjust (typically downwards) the heap until the CG completes in less than 500mS (typically 100-200mS). Usually, I find that CG runs every 30 secs or so, frees perhaps 30-40% of the heap and completes in 150mS. Everytime I have used a large heap with IBM JVM1.5 or later, there have been big performance problems. Matthew On Wed, Jun 24, 2009 at 7:45 PM, Rodger Donaldson <[email protected]>wrote: > Agblad Tore wrote: > > Check HEAP size for the zLinux server, does it really need 6 GB ? > > A big heapsize causes Garbage Collection to take long time, so it's > important > > to tune that HEAP size right. > > This is an extreme oversimplification. With a 1.3 JVM or an old > non-parallel GC algorithm on newer JVMs the behaviour for large heaps is > what you describe. Using any modern JVM (1.5 or 1.6) and an appropriate > parallel GC policy a large heap is unlikely to cause a performance penalty. > > Having spent some time recently looking into precisely this pain, I > suggest your starting point is to ensure you aren't either paging at the > zVM layer or swapping the JVM. Assuming those things are true you need > to start doing verbose GC logging and dumping into, e.g., the pmat tool > (http://www.alphaworks.ibm.com/tech/pmat) in order to understand what > your JVM is doing with GC. > > Another tool we've found invaluable is JInsightLive > (http://www.alphaworks.ibm.com/tech/jinsightlive), which is one of the > few profiler tools for Java on Z, and will give you a detailed breakdown > of where your code is spending its time (amongst other things). > > Obviously profiling tools are subject to the usual caveats re: accuracy > of reporting in a virtualised environment, but these are a good starting > point. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
