基礎(chǔ)：

業(yè)務(wù)代碼

rose框架(底層是spring)

resin4

java 1.6.0_38-b05

centos

初始配置：

只修改了以下三個值

-Xmx5000M // max的heap的大小。

-Xms5000M // min的heap的大小，就是一初始給的大小，不夠先GC，還不夠再加，直到max。

-Xmn2000M //young區(qū)的大小，一般來講：heap=Y+O，P是額外的值。Sun推薦Y=heap*(3/8)。

gc情況解讀：

# jstat -gcutil 20538 1000 100

S0 S1 E O P 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.266

S0\S1是survivor區(qū)，就是沒被gc掉的對象，在這兩個survivor里來回導(dǎo)來導(dǎo)去，滿足條件最后進行O區(qū)。

E是Eden區(qū)，E＋S0＋S1＝Y。

從jstat的數(shù)據(jù)看，這個機器大概15s發(fā)生一次YGC，很長時間沒有FGC了(超過1天以上)，而且P區(qū)已經(jīng)99.93％使用了。

各區(qū)內(nèi)存情況解讀：

#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區(qū)的初始大小 此默認值在32位平臺上是4M，在64位平臺上是5M多。基本無用。

NewRatio ? ? ? ? = 2 ?// Y/O=1/2 ?表示Y區(qū)要占三分之一

SurvivorRatio ? ?= 8 //Y區(qū)里的S與E的比例：S/E = 2/8，Y區(qū)里十分之一當(dāng)S區(qū)(因為有兩個S)。

PermSize ? ? ? ? = 21757952 (20.75MB) ?//P區(qū)默認配置初始值

MaxPermSize ? ? ?= 85983232 (82.0MB) //P區(qū)默認配置最大值 ? 32位的服務(wù)器時是64M，64位服務(wù)器時是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區(qū)雖然顯示的99％used，但是與max相比還有剩余，在spring AOP眾多，一次性啟動的特點下，相比82M的max，才使用到77M，還有上揚的空間。實測FGC的發(fā)生也只是一天一次。

是否需要優(yōu)化判定：

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

FGCT/FGC=5s ?但是一天也沒幾次，業(yè)務(wù)允許，一般健康可優(yōu)化。未來可考慮優(yōu)化為多次FGC減少FGCT的時長。

后續(xù)思考：

雖然FGC并不頻繁，但因為xmx值比較大，導(dǎo)致了O區(qū)相對變大，同時FGC緩慢，考慮從兩個方向：1.調(diào)整Y區(qū)大小，讓YGC去到O區(qū)的數(shù)據(jù)更少，讓FGC頻率更加慢(有可能很難有變化)2.調(diào)整整體的大小，讓FGC頻繁一點點但更加快一點 3.調(diào)整FGC的算法，讓速度快一點到1秒內(nèi)來。

對照組結(jié)果后續(xù)有結(jié)論了再來續(xù)本文內(nèi)容。

GC優(yōu)化永遠是最后一項任務(wù)。

總結(jié)

以上是生活随笔為你收集整理的java 0b,java 1.6.0_38-b05 vm 20.13-b02优化手记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。