- JVM Settings
- The standard JVM defaults are not suitable for a production system. One of the simplest changes that can be made is to use the –server flag, rather than the default –client.
- Allocate more memory to the JVM by modifying the value of the –Xmx flag. How much depends on the size and complexity of your enterprise application and how much memory you have available. In addition we also want to make sure we allocate all of the memory on startup. This is done with the –Xms flag.
- We set the minimum and maximum perm gen to the same value in order to avoid allocation failures & subsequent full garbage collections.
- Garbage Collection
- -verbose:gc Garbage Collection information as this can prove extremely useful in diagnosing issues.
- -Xloggc:/path_to_log_file/gc.log make sure we log GC information to a file. This will make it easier to separate the GC from other details in the log files.
- -XX:+PrintGCDetails ensure we have as much detail as possible.
- -XX:+PrintGCTimeStamps the information is timestamped for easier diagnosis of long running errors and to be able to ascertain what normal levels are over time
- -XX:+DisableExplicitGC ensure that developers aren’t making explicit calls to System.gc().
- Heap Dumps Heap dumps can be extremely useful for diagnosing memory issues. There are two settings we would definitely recommend. These tell the JVM to generate a heap dump when an allocation from the Java heap or the permanent generation cannot be satisfied. There is no overhead in running with these options but they can be useful for production systems where OutOfMemoryErrors can take a long time to surface.
4. Turn off development features
a. Turn off auto-deploy and dynamic application reloading. Both of these features are great for development, but can affect performance
b. Configure the JSP servlet not to check JSP files for changes on every request.
c. set the parameter genStrAsCharArray to true. This will ensure all String values are declared as static char arrays. One reason for this is that the array has less memory overhead than String.
5. Acceptor Threads and Request Threads: There are two main thread values we would recommend setting, acceptor threads and request threads.
a. Acceptor threads are used to accept new connections to the server and to schedule existing connections when a new request comes in. Set this value equal to the number of CPU cores in your server. So, if you have two quad core CPUs, this value should be set to eight.
b. Request threads run HTTP requests. You want enough of these to keep the machine busy, but not so many that they compete for CPU resources which would cause your throughput to suffer greatly.
6. Thread pools
- Max thread pool and min pool size should be set to the same value.
Monitoring : The fewer monitoring options that are enabled, the better the server’s performance.
What to monitor
1. Used Heap Size – Compare this number with the maximum allowed heap size to see what portion of the heap is in use. If the used heap size nears the max heap size, the garbage collector urgently attempts to free memory and this is something that should be avoided where possible
2. JVM Threads – Important for performance tuning and for troubleshooting JVM crashes. Some of the most essential indicators are the current active JVM thread count and the peak values.
3. Thread pools – You should compare a pools current usage with the maximum number allowed. Problems can start to occur when the current count nears the max threads number.