Odi's astoundingly incomplete notes

The default VM parameters are not suitable to run a large J2EE application in production. For JBoss I recommend the following settings (x86 architecture):

-server 
-Xms512m -Xmx1024m 
-XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=64m 
-XX:+UseConcMarkSweepGC
-Djava.awt.headless=true
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.net.inetaddr.ttl=60
-Dsun.net.client.defaultConnectTimeout=30000

On server machines we typically have multiple CPUs, so we select the Concurrent Mark and Sweep Garbage Collector. It provides the best performance. On 32bit architectures we have a maximum of 2GB per process. JBoss starts lots of threads which all need stack space, plus there are non-heap memory pools that need space. So we can't just assign 2GB of heap, instead we use a 1GB heap. The VM's auto tuning mechanism sets the permanent generation pool too low (64MB). Out of memory conditions would take down the system immediately. Peaking into the memory pools at runtime with jconsole or through JBoss' JMX console quickly reveals that 128MB or 256MB are more appropriate. Also the code cache should be increased because J2EE applications have many classes and EJB3 even creates new classes at runtime (e.g. lazy loading proxies). We also set the RMI GC intervals to reasonably large values to avoid unnecessary GC. Last but not least we don't want the VM to cache DNS names forever (which effectively causes a leak).

posted on 2007-03-28 15:49 UTC in Code | 0 comments | permalink