JBoss application server tutorials

JBoss Performance Tuning part 1

Page 1 of 3

Performance tuning is not a silver bullet. Simply put, good system performance depends on: good design, good implementation, defined performance objectives, and performance tuning.
Since JBoss Performance tuning involves also tuning the environment on which jBoss is run, the first tutorial will start discussing about JVM settings and OS settings on which JBoss can produce best results. Then we'll see some specific JBoss config settings.

JBoss Performance Tuning Part 1

This tutorial is updated to the release 4.x of the application server. If you want to learn all about JBoss 4.x-5.x-6.x Performance tuning, Optimal data Persistence, Clustering tuning, Web application tuning and much more you should not miss the JBoss Performance tuning book

Read here more about the book

JBoss tuning tip 1: Tune the garbage collector

One strength of the J2SE platform is that it shields the developer from the complexity of memory allocation. However, once garbage collection is the principal bottleneck, it is worth understanding some aspects of this hidden implementation

An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms simply iterate over every reachable object. Any objects left over are then considered garbage. The time this approach takes is proportional to the number of live objects,

The complete address space reserved for object memory can be divided into the young and tenured generations.

The young generation consists of eden and two survivor spaces. Most objects are initially allocated in eden. One survivor space is empty at any time, and serves as the destination of any live objects in eden and the other survivor space during the next copying collection. Objects are copied between survivor spaces in this way until they are old enough to be tenured (copied to the tenured generation).

A third generation closely related to the tenured generation is the permanent generation which holds data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation

Use the the command line option -verbose:gc causes information about the heap and garbage collection to be printed at each collection. For example, here is output from a large server application:

jboss performance tuning It's demonstrated that an application that spends 10% of its time in garbage collection can lose 75% of its throughput when scaled out to 32 processors
(http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html)

JBoss tuning tip 2: Set -Xms and -Xmx to the same value

By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range.

Setting -Xms and -Xmx to the same value. This increase predictability by removing the most important sizing decision from the virtual machine.

JBoss tuning tip 3: Use server VM

The server JVM is better suited to longer running applications. To enable it simply set the -server option on the command line.

JBoss tuning tip 4: Turn off distributed gc

The RMI system provides a reference counting distributed garbage collection algorithm. This system works by having the server keep track of which clients have requested access to remote objects running on the server. When a reference is made, the server marks the object as "dirty" and when a client drops the reference, it is marked as being "clean.". However this system is quite expensive and by default runs every minute.

Set it to run every 30 minute at least
-Dsun.rmi.dgc.client.gcInterval=1800000
-Dsun.rmi.dgc.server.gcInterval=1800000

JBoss tuning tip 6: Turn on parallel gc

If you have multiple proessors you can do your garbage collection with multiple threads. By default the parallel collector runs a collection thread per processor, that is if you have an 8 processor box then you'll garbage collect your data with 8 threads. In order to turn on the parallel collector use the flag -XX:+UseParallelGC. You can also specify how many threads you want to dedicate to garbage collection using the flag -XX:ParallelGCThreads=8.

JBoss tuning tip 7: Don't use Huge heaps, use a cluster

More JVMs/smaller heaps can outperform fewer JVMs/Larger Heaps. So instead of huge heaps, use additional server nodes. Set up a JBoss cluster and balance work between nodes.