Jean-Francois Arcand's Blog

Configuring Grizzly for performance part I: JVM options

I'm getting a lot of questions those days about how to configure Grizzly to get the best performance. In part I, I will share what we have learned so far(thanks to Scott for his help!)

First, if you are using Grizzly in GlassFish, makes sure you remove in domain.xml the following jvm-options:

-Xmx512 -client -Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000

and replace it with

-server -XX:+AggressiveHeap -Xmx3500m -Xms3500m -Xss128k
-XX:+DisableExplicitGC
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

For anything other than Solaris/SPARC, 3500m needs to be 1400m. On a multi-CPU machine, add:

-XX:ParallelGCThreads=N -XX:+UseParallelOldGC

where N is the number of CPUs if < 8 (so really, you can leave it out altogether in that case) and N = number of CPUs / 2 otherwise. On a Niagara, add:

-XX:LargePageSizeInBytes=256m

Et voila!

technorati: grizzly performance glassfish

Comments

• What about -d64 / -d32 ??

  Posted by: bachst on January 12, 2007 at 04:58 AM

• We still have to do more performance test on a 64 OS before I can recommend something. Right now I would say use -d32.....

  Posted by: jfarcand on January 12, 2007 at 07:05 AM

• I have read through your blog, but not found how to combine grizzly with tomcat.
  Originally, grizzly is a http connector for tomcat, but how can I adopt grizzly as connector for 'official' tomcat release?
  

  Posted by: sinoswiss on January 15, 2007 at 07:21 PM

• Grizzly wasn't designed for Tomcat, but for GlassFish. GlassFish WebContainer is based on Tomcat 5.0.X and will not work as it is right now. I'm planning to investigate how difficult it will be to make it work, but didn't have time as of now. Should be one or two days of work. Stay tuned!

  Posted by: jfarcand on January 17, 2007 at 10:26 AM

• I though the 1400m heap "limit" was fixed with the latest jvm and i could safely/efficiently use a 3500m heap size on my linux amd64 server.

  Posted by: tlvenn on February 07, 2007 at 04:21 AM

• It is true for Linux AMD 64 only. There are two Linux distributions: Linux i586 (which runs on all platforms and is 32-bit) and Linux AMD 64(which runs only on 64-bit AMD processors and is 64-bit). Because it's a 64-bit JVM, the Linux AMD 64 release can have really large heaps (over the 4GB theoretical limit for 32-bit processors).

  Posted by: jfarcand on February 07, 2007 at 09:07 AM

• Merci Jean François, it's what i though !

  Posted by: tlvenn on February 07, 2007 at 05:11 PM

• After making these changes, I got the following message when starting a node agent in my cluster:

  Java HotSpot(TM) Server VM warning: Failed to reserve shared memory (errno = 22).

  It's a single CPU, dual-core Inel Xeon machine with 2 GB of memory. Any idea why the changes above might cause that warning? Also, what exactly does that warning mean? And is it a big problem?

  Posted by: rwillie6 on November 12, 2007 at 12:45 PM

• No idea...I've never saw that exception. Can you post the question on the users@glassfish.dev.java.net so our performance team can comments? Thanks!

  Posted by: jfarcand on November 13, 2007 at 12:41 PM

This work is licensed under a Creative Commons License.