Java CMS игнорируется и вместо этого получает полный GC - PullRequest
Новая
       2

Java CMS игнорируется и вместо этого получает полный GC

9 голосов
/ 19 апреля 2011

Я использую сервер Java, который использует CMS для штатного коллектора.Работая под нагрузочным тестом, я вижу молодые коллекции примерно раз в 1 с и держу (параллельно) примерно каждые 5 мес.Это хорошо.

Когда я бегу с реальным трафиком около 1/2 емкости, я получаю молодые коллекции примерно каждые 4 секунды и держу (! Параллельно, останови мир!) Примерно каждые 7 метров.Почему JVM решает делать полные коллекции «останови мир» вместо использования сборщика CMS?

Из журнала gc.log видно, что «Полный сборщик мусора» запускается и для его завершения требуется более 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

Ответы [ 2 ]

2 голосов
/ 19 апреля 2011

Если ваше пространство для выживших недостаточно велико, оно может вызвать полный сбор мусора.(Похоже, он жалуется на коэффициент выживаемости)

Либо вам нужно уменьшить коэффициент выживаемости, либо, вероятно, лучшим решением будет увеличение вашего NewSize, чтобы меньше объектов выживало из пространства Эдема.У меня есть eden space 6 ГБ;)

1 голос
/ 19 апреля 2011

Мне кажется, я вспоминал подобное явление в прошлом году, когда настраивал большую кучу, чтобы избежать полной GC.Я думаю, что вы можете уменьшить размер рая.Это довольно большое количество по сравнению с постоянным поколением.

Я полагаю, что может произойти то, что больше вашего eden стареет одновременно с вашим трафиком на 1/2 скорости, чем на полной скорости (где они 'не выжить).Что означает, что больше из этого должно переместиться в арендованный сразу.И если он не помещается в это время, он может запустить полный сборщик мусора, чтобы освободить место.

Для справки вот что мы используем сейчас для кучи от 6 ГБ до 24 ГБ: 

-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 обычно может использовать на 40% меньше памяти, сокращая 64-битную адресацию до 32-битной (работает только до 32 ГБ).

...