Geek Answers Handbook

Xms / Xmx / XX Optimization: MaxPermSize in JVM

What are the necessary steps to get the optimized value of Xms/Xmx/XX:MaxPermSize ?

Definitely, I can set a lot of value, but as you know, the GC takes time in big memory. What is the general recommendation when I can save time while testing and find this value ?

For example, the following numbers help?

 Eden Space heap usage - 42MB / 62MB (used / committed) Survivor Space heap usage - 8.5MB / 8.5MB (used / committed) CMS Old Gen heap usage - 100MB / 217MB (used / committed) Non-heap memory pool usage - 36MB
+4
source share
3 answers

The general rule is that you should not change the JVM memory settings before you discover a problem that needs to be resolved. The JVM does a great job of setting most of the parameters at runtime to suit your application.

If you find it necessary to optimize memory settings, it depends on what you need to optimize. The parameters that you would use will vary greatly depending on what aspect you need to optimize (for example, settings to minimize pauses are very different from settings that maximize throughput).

If you really need to optimize, please provide more information about which aspect you need to optimize.

+1
source

When setting up GC, you need to collect GC statistics for a longer period of time, and then act on it. Just a single shot of Generation size is not enough.

You must:

  • Enable full GC logging . Lightweight but powerful.

    • Use -XX:+PrintTenuringDistribution -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log -XX:+HeapDumpOnOutOfMemoryError -Xloggc:gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -showversion

  • Consider additional tools for collecting information about your GC . Logging is OK, but sometimes lightweight command line tools are available that will give you even more information. For instance. jstat for Hotspot, which will show you the occupation / ability of Eden, Survivor and Old Gen.

  • Compute:

    • Live Data Set , Distribution Frequency and . . This will tell you if you need a big pile or if you, for example, the Young General is too small, or if your places to survive are crowded, etc.
    • total GC time , it should be <5% of the total working time. This way you can judge if your overall GC strategy is working.
    • observe the occupation of the Permian general

Once you have this data, you can start setting up Generations and again monitor the impact of the changes made. common calibration recommendations for throughput:

  • Old General = 1.5-2x Live Data Set - Your data set should fit comfortably into OldGen space.
  • Perm Gen = 1.5x regular PermGen fill.
  • Young Gen = based on distribution rate. See how much you allocate per second, and then look at the promotion rate, decrease the level of promotion by increasing the YoungGen value.
  • Living for living creatures = control retention threshold and speed of advancement.

Typically, size recommendations depend on the purpose of your setup:

  • Bandwidth settings - see above,
  • Low latency tuning - GC pause monitoring
    • Young GC too long => Decreasing young generation
    • Young GC too frequent => increase in young generation
  • Track customization - customize sizes according to LiveDataSet, advancing speed and distribution speed. You may not need to add an extra room for each place, as in bandwidth settings.

See also GC tuning question: Is there a cookbook guide for problems with GC?

+4
source

On rare occasions when I need to adjust these values, there is a program called JavaVisualVM which is included in jdk (the bin folder that I think), which I find very useful. You can connect to your running vm and analyze all its execution parameters.

In the plugins section you can also find a very useful gc monitoring plugin where you can see what exactly is going on there.

+1
source

More articles:


All Articles