Here are some commonly used JVM parameters that every application developer should review, some may be appropriate for your application, some may not.
This post is a quick reference for these parameters, please refer to the official java docs for complete technical documentations.
-Xms -Xmx
e.g. -Xms16g -Xmx16g
The min and max of your heap size. When you set them the same, you fixed the size which helps avoid any change in real time, but of course you want to make sure you don’t waste the size. NOTE: If you use a big heap ( or are using large page size ( default is 4KB ), consider using -XX:+AlwaysPreTouch also.
-XX:+PrintGCApplicationStoppedTime
When you set this, in your GC log you will start seeing entries like
- Total time for which application threads were stopped: 0.0002480 seconds
- Total time for which application threads were stopped: 0.0001090 seconds
It reports the duration of time when your application is paused due to any kind of GC activity, and is used as another meter to measure your application throughput of the system CPU.
-XX:+PrintGCDetails
It prints the GC in details in old gen, young gen and perm gen. Your gc log won’t be very useful without this.
-XX:+PrintGCDateStamps
It prints the timestamp of GC event, without this, the only timestamp would be the time since the application start.
-XX:+PrintTenuringDistribution
This reports the tenuring statistics (how old the objects are) and the desired threshold of when objects will be promoted. This information gives you insight of how long your application may be holding on to objects.
-XX:NewSize -XX:MaxNewSize (or use -XX:NewRatio )
e.g. -XX:NewSize=4096m -XX:MaxNewSize=4096m
The min and max size of young gen. Alternatively, you can use NewRatio to specify the size of the young gen relative to the size of the entire heap. e.g. -XX:NewRatio=4 means 1GB will be designated as young gen in a 4GB heap (where old gen is about 3GB + perm gen).
-XX:SurvivorRatio
e.g. -XX:SurvivorRatio=2
The young gen is comprised of eden space and 2 survivor spaces, the survivor ratio specifies the size of the survivor space relative to the eden space. e.g. if you have a 4GB young gen and survivor ratio is 2, then your eden space is 2GB and each of your survivor space has 1GB in size. In other words, your survivor space size = ( size of young gen / ( SurvivorRatio + 2 ) ). The ratio can be tuned for your application, the smaller the survivor space, the fewer iteration the objects can be tenured which could lead to more promotions.
-XX:+UseConcMarkSweepGC
Use the concurrent mark sweep garbage collector. This collector is responsible for collecting in old gen and will run in parallel to young gen parallel collector. Its IM ( initial mark ) and RM ( remark ) are the operations that will pause the application. Other times reported in the GC such as CS ( concurrent sweep ) are non-pausing so they won’t really affect your JVM as much as IM and RM.
-XX:CMSInitiatingOccupancyFraction
e.g. -XX:CMSInitiatingOccupancyFraction=85
Assuming you already have UseConcMarkSweepGC, this tells the CMS (Concurrent Mark Sweep Collector) in the old gen to start collection process when old gen is 85% full, if it hasn’t already. Note that CMS could start before old gen reaches 85% even if you have already set the CMSInitiatingOccupancyFraction. CMS has its own logic to decide when to start. If you absolutely wants CMS to start only at 85%, then set also -XX:+UseCMSInitiatingOccupancyOnly. The default is 65%.
-XX:+AlwaysPreTouch
Consider using this when you have a big heap or are using large page. It pretouchs and set zero all the pages you have allocated during the initialization of your application. Normally a page is touched when it is used, but in the cases where you have big heap or big page size, this may increase your startup time, but is probably better than doing the pretouch in run time with performance impact.
-XX:+CMSClassUnloadingEnabled
This will allow CMS to also do some garbage collection in the permanent generation. If you use this option, be sure to also use UseConcMarkSweepGC. This has been seen to solve an apparent perm gen memory leak in Voltron: (described in this page: Perm Gen memory increases)
Java Works 