JVM Tuning-Cenozoic Survivor space shortage

0. The new generation of tuning lawsIncrease the Cenozoic space, Minor GC frequency, Minor GC time rise. Reduced Cenozoic space, Minor GC frequency rise, Minor GC time drop

I. Typical problems of the Cenozoic

Take a look at a GC log: New generation uses parnew, old age using CMS

{Heap before GC invocations=0 (full 0): par new generation total 943744K, used 838912K [0x0000000757000000, 0x0000000797 000000, 0x0000000797000000) Eden Space 838912K, 100% used [0x0000000757000000, 0x000000078a340000, 0x000000078a340000) F Rom space 104832K, 0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000) to space 104832K, 0% used [ 0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000) concurrent mark-sweep generation total 1560576K, used 0K [ 0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000) concurrent-mark-sweep Perm Gen Total 159744K, used 38069K [ 0x00000007f6400000, 0x0000000800000000, 0x0000000800000000) 2016-01-19t14:15:34.532+0800:13.812: [GC2016-02-19T14   : 15:34.532+0800:13.812: [parnewdesired Survivor Size 53673984 bytes, new threshold 1 (max 6)-age 1:55521392 Bytes, 55521392 total:838912k->54474k (943744K), 0.0914620 secs] 838912k->54474k (2504320K), 0.0916240 secs] [times:user =0.67 sys=0.06, real=0.09 secs]heap after GC Invocations=1 (full 0): par new generation total 943744K, used 54474K [0x0000000757000000, 0x0000000797000000, 0x000 0000797000000) Eden Space 838912K, 0% used [0x0000000757000000, 0x0000000757000000, 0x000000078a340000) from Space 104 832K, 51% used [0x00000007909a0000, 0X0000000793ED2AE0, 0x0000000797000000) to space 104832K, 0% used [0x000000078a3 40000, 0x000000078a340000, 0x00000007909a0000) concurrent mark-sweep generation total 1560576K, used 0K [ 0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000) concurrent-mark-sweep Perm Gen Total 159744K, used 38069K [ 0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)}{heap before GC Invocations=1 (full 0): par new Generation T Otal 943744K, used 893386K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000) Eden Space 838912K, 100% used [0x 0000000757000000, 0x000000078a340000, 0x000000078a340000) from space 104832K, 51% used [0x00000007909a0000, 0x000000079 3ED2AE0, 0x0000000797000000) to space 104832K, 0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000) concurrent mark-sweep generation Total 1560576 K, used 0K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000) concurrent-mark-sweep Perm Gen Total 159744K, use D 53249K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000) 2016-01-19t14:15:41.943+0800:21.222: [ gc2016-02-19t14:15:41.943+0800:21.223: [parnewdesired Survivor Size 53673984 bytes, new threshold 1 (max 6)-Age 1:10 7256200 bytes, 107256200 total:893386k->104832k (943744K), 1.2389070 secs] 893386k->210614k (2504320K), 1.2391870  secs] [times:user=2.89 sys=0.35, real=1.24 secs]heap after GC invocations=2 (full 0): par new generation total 943744K, Used 104832K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000) Eden Space 838912K, 0% used [0x0000000757000 0x0000000757000000, 0x000000078a340000) from space 104832K, 100% used [0x000000078a340000, 0x00000007909a0000, 0x00 000007909a0000) to space 104832K, 0%Used [0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000) concurrent mark-sweep generation Total 1560576K, used 105782K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000) concurrent-mark-sweep Perm Gen Total 159744K, used 53249K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)}

It is obvious that the GC log above contains two Minor GC. Noting the second Minor GC, the log typed "desired survivor size 53673984 bytes", but survived "-age 1:107256200 Bytes, 107256200 total" which More. It can be seen that the obvious cenozoic Survivor space shortage. Because Survivor space is insufficient, then from Eden survived and originally in Survivor space is not old enough to occupy the Survivor, will ascend to the old age, you can see this round Minor GC after the old age from the original 0K occupancy into 105782 K occupancy, which belongs to a typical JVM memory problem called "premature promotion" (premature elevation).
"Premature promotion" will not be a problem in the short term, but the regular "premature promotion", the most often lead to a large number of short-term objects to be promoted to the old age, eventually leading to the old age space shortage, triggering another JVM memory problems "Promotio  N Failure "(Ascension failure: The old age space is not sufficient to tolerate the ascending object in the Minor GC). "Promotion failure" occurs when the JVM performs a CMS garbage collection and frees up space to accept the new generation of objects, CMS garbage collection time is longer than Minor GC, resulting in reduced throughput, increased latency, will affect the user experience.

two. New Generation tuning RecommendationsFor the above-mentioned Cenozoic problems, if server memory is sufficient, it is recommended to directly increase the Cenozoic space (e.g.-XMN). If memory is not sufficient, increase the Survivor space and reduce Eden space, but note that reducing Eden space increases the Minor GC frequency, taking into account whether the application's metrics for latency and throughput are eventually met.
How much Survivor space do you want to increase? It is necessary to observe the Minor GC process several times, look at the size of the object survived after Minor GC, and finally determine the appropriate size of Survivor. The tuning process may take several adjustments to find the appropriate value. After several adjustments, if the memory is not enough, you need to consider increasing the server memory or sharing the load on more JVM instances.
Survivor Space Calculation formula: Survivor space size =-xmn[value]/(-xx:survivorratio=<ratio> + 2)

JVM Tuning-Cenozoic Survivor space shortage