Java CMS가 무시되고 대신 전체 GC 가져 오기

Question

보유 된 콜렉터에 대해 CMS를 사용하는 Java 서버를 실행 중입니다. 부하 테스트를 받으면서 매 5 초마다 1 초마다 젊은 콜렉션이 보급되고 (동시 발생) 보입니다. 이것은 좋다.

약 2 분의 1 용량의 실제 트래픽으로 실행하면 매 7 초마다 약 4 초마다 어린 콜렉션이 생기고 (평행, 세계를 멈 춥니 다!). 왜 JVM은 CMS 콜렉터를 사용하는 대신 전 세계적인 콜렉션을 수행하기로 결정합니까?

gc.log에서 "Full GC"가 실행 중이고 3 초 이상 완료됨을 볼 수 있습니다. 여기에는 동시 모드 오류가 없습니다. 명시 적으로 콜렉션을 요청하는 것은 없습니다.

1350.596: [GC 1350.596: [ParNew 
Desired survivor size 119275520 bytes, new threshold 3 (max 3) 
- age 1: 34779376 bytes, 34779376 total 
- age 2: 17072392 bytes, 51851768 total 
- age 3: 24120992 bytes, 75972760 total 
: 1765625K->116452K(1864192K), 0.1560370 secs] 3887120K->2277489K(5009920K), 0.1561920 secs] [Times: user=0.40 sys=0.04, real=0.16 secs] 
1355.106: [GC 1355.107: [ParNew 
Desired survivor size 119275520 bytes, new threshold 3 (max 3) 
- age 1: 44862680 bytes, 44862680 total 
- age 2: 20363280 bytes, 65225960 total 
- age 3: 16908840 bytes, 82134800 total 
: 1747684K->123571K(1864192K), 0.1068880 secs] 3908721K->2307790K(5009920K), 0.1070130 secs] [Times: user=0.29 sys=0.04, real=0.11 secs] 
1356.106: [Full GC 1356.106: [CMS: 2184218K->1268401K(3145728K), 3.0678070 secs] 2682861K->1268401K(5009920K), [CMS Perm : 145090K->145060K(262144K)], 3.0679600 secs] [Times: user=3.05 sys=0.02, real=3.07 secs] 
1361.375: [GC 1361.375: [ParNew 
Desired survivor size 119275520 bytes, new threshold 3 (max 3) 
- age 1: 33708472 bytes, 33708472 total 
: 1631232K->84465K(1864192K), 0.0189890 secs] 2899633K->1352866K(5009920K), 0.0191530 secs] [Times: user=0.19 sys=0.00, real=0.02 secs] 
1365.587: [GC 1365.587: [ParNew 
Desired survivor size 119275520 bytes, new threshold 3 (max 3) 
- age 1: 33475320 bytes, 33475320 total 
- age 2: 22698536 bytes, 56173856 total 
: 1715697K->67421K(1864192K), 0.0229540 secs] 2984098K->1335822K(5009920K), 0.0231240 secs] [Times: user=0.25 sys=0.00, real=0.03 secs] 

다음은 JVM 플래그이다 : 당신의 생존 공간이 충분하지 않은 경우

이

-server -Xss256K -Xms5120M -Xmx5120M -XX:NewSize=2048M -XX:MaxNewSize=2048M 
-XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 
-XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80 
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1 
-XX:SoftRefLRUPolicyMSPerMB=73 -verbose:gc -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -Xloggc:logs/gc.log 
-XX:MaxPermSize=256m -XX:PermSize=256m -XX:MaxTenuringThreshold=3 

Answer 1

, 그것은 전체 GC를 트리거 할 수 있습니다. (생존자 비율에 대해 불평하는 것으로 보입니다.)

생존자 비율을 줄이거 나 더 나은 해결책은 에덴 공간에서 생존하는 개체가 적어 지도록 NewSize를 늘리는 것입니다. 나는 6GB의 에덴 공간을 가지고있다.)

Answer 2

나는 완전한 GC를 피하기 위해 커다란 힙을 튜닝 할 때 비슷한 현상을 보았다. 나는 에덴의 크기를 줄이고 싶을지도 모른다고 생각합니다. 이것은 종신 세대에 비해 상당히 큽니다.

내가 믿는 것은 당신의 eden이 1/2 속도의 트래픽으로 한 번에 "오래"을 얻는 것이 최대 속도 (생존하지 않는 곳)보다 많다는 것입니다. 즉, 더 많은 사람들이 일제히 재임을해야합니다. 그리고 그 시간에 맞지 않으면 방안을 마련하기 위해 전체 GC를 실행할 수 있습니다. 여기에 참고로

우리가 24기가바이트 힙에 6기가바이트 지금 무엇을 사용 :

-XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC 
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled 
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:logs/gc.log 

그것은 이미 당신과 상당히 유사하다. 모든 비율을 사용하는 것에 대한 좋은 점은 힙 크기를 쉽게 변경할 수 있고 일반적으로 적절하게 비율을 조정할 수 있다는 것입니다. 또 하나의주의 사항은 일반적으로 -XX:+UseCompressedOops은 64 비트 주소 지정을 32 비트로 줄임으로써 메모리를 40 % 적게 사용할 수 있다는 것입니다 (최대 32GB까지만 작동).