Brief introduction and viewing methods of jvm parameters

Reprinted from: http://www.54chen.com/java-ee/jvm.html

Foundation:
business code
rose framework (the bottom layer is spring)
resin4
java 1.6.0_38-b05
centos

Initial configuration:
Only the following three values ​​have been modified
- Xmx5000M //  The size of the max heap.
-Xms5000M //  The size of min's heap is the size given at the beginning. If it is not enough, it will be GC first, and if it is not enough, it will be added until max.
-Xmn2000M // The size of the young area, generally speaking: heap=Y+O, P is an additional value. Sun recommends Y=heap*(3/8).

gc情况解读：
# jstat -gcutil 20538 1000 100
S0 S1 EOP YGC YGCT FGC FGCT GCT
0.00 51.96 62.53 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 69.83 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 77.75 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 85.79 73.42 99.93 35830 1554.778 185 1089.488 2644.266
0.00 51.96 92.35 73.42 99.93 35830 1554.778 185 1089.488 2644.26

S0\S1 is the survivor area, which is the object that has not been dropped by the gc. It is guided back and forth in these two survivors, and finally enters the O area when the conditions are met.
E is the Eden area, E+S0+S1=Y.
According to the data of jstat, YGC occurs about every 15 seconds on this machine, and there has been no FGC for a long time (more than 1 day), and 99.93% of the P area has been used.

Interpretation of the memory status of each area:

#jmap -heap 20538

Attaching to process ID 20538, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 20.13-b02

using thread-local object allocation.

Parallel GC with 8 thread(s)

Heap Configuration:

MinHeapFreeRatio = 40 // 如果连40％空闲都空不出来，就需要增加heap到xmx了。

MaxHeapFreeRatio = 70  //如果70％空闲了就别折腾了，减少去xms。

MaxHeapSize      = 5242880000 (5000.0MB) -Xmx

NewSize          = 2097152000 (2000.0MB)  // -Xmn

MaxNewSize       = 2097152000 (2000.0MB)

OldSize          = 5439488 (5.1875MB)  // old区的初始大小 此默认值在32位平台上是4M，在64位平台上是5M多。基本无用。

NewRatio         = 2  //  Y/O=1/2  表示Y区要占三分之一

SurvivorRatio    = 8 //  Y区里的S与E的比例：S/E = 2/8，Y区里十分之一当S区（因为有两个S）。

PermSize         = 21757952 (20.75MB)  // P区默认配置初始值

MaxPermSize      = 85983232 (82.0MB) // P区默认配置最大值   32位的服务器时是64M，64位服务器时是64×(0.3*64) =82.2M左右。

Heap Usage:

PS Young Generation

Eden Space:

capacity = 1966604288 (1875.5MB)

used     = 968355296 (923.4955749511719MB)

free     = 998248992 (952.0044250488281MB)

49.23996667294971% used

From Space:

capacity = 64880640 (61.875MB)

used     = 32440384 (30.93756103515625MB)

free     = 32440256 (30.93743896484375MB)

50.00009864267677% used

To Space:

capacity = 65273856 (62.25MB)

used     = 0 (0.0MB)

free     = 65273856 (62.25MB)

0.0% used

PS Old Generation

capacity = 3145728000 (3000.0MB)

used     = 2375317280 (2265.279083251953MB)

free     = 770410720 (734.7209167480469MB)

75.50930277506511% used

PS Perm Generation

capacity = 80805888 (77.0625MB)

used     = 80753328 (77.01237487792969MB)

free     = 52560 (0.0501251220703125MB)

99.93495523494525% used

P区虽然显示的99％used，但是与max相比还有剩余，在spring AOP众多，一次性启动的特点下，相比82M的max，才使用到77M，还有上扬的空间。实测FGC的发生也只是一天一次。

是否需要优化判定：

YGCT/YGC=40ms  且十几秒才一次，健康

FGCT/FGC=5s  但是一天也没几次，业务允许，一般健康可优化。未来可考虑优化为多次FGC减少FGCT的时长。

后续思考：
虽然FGC并不频繁，但因为xmx值比较大，导致了O区相对变大，同时FGC缓慢，考虑从两个方向：1.调整Y区大小，让YGC去到O区的数据更少，让FGC频率更加慢（有可能很难有变化）2.调整整体的大小，让FGC频繁一点点但更加快一点 3.调整FGC的算法，让速度快一点到1秒内来。

对照组结果后续有结论了再来续本文内容。

GC优化永远是最后一项任务。