Сборка мусора YGCT и время сборки мусора продолжают расти

У меня проблема со сборкой мусора, когда в нашей системе время сборки мусора постоянно увеличивается, пока не достигнет константы около 25 секунд.

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0.00  84.18  76.65  35.47  60.16    441   15.581    16    1.834   17.415
 75.72   0.00  97.32  35.47  60.16    442   15.770    16    1.834   17.604
  0.00  64.69  35.56  35.86  60.16    443   16.318    16    1.834   18.153
100.00   0.00  19.91  35.87  60.16    444   16.381    16    1.834   18.215
  0.00  70.61  40.85  36.82  60.17    445   17.488    16    1.834   19.322
 28.80   0.00  19.61  36.82  60.17    446   17.535    16    1.834   19.369
 34.51   0.00  48.01  36.82  60.18    448   17.561    16    1.834   19.395
  0.00  10.86  20.48  37.11  60.21    453   17.979    16    1.834   19.813
  9.04   0.00  47.39  37.12  60.23    454   18.063    16    1.834   19.898
  0.00  71.26   2.65  37.14  60.23    455   18.173    16    1.834   20.007
 63.64   0.00  90.91  38.04  60.23    456   19.562    16    1.834   21.396
  0.00  76.45  42.70  38.04  60.23    457   19.592    16    1.834   21.426

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

Я просмотрел какой-то снимок, в котором я не эксперт, и действительно обнаружил некоторые проблемы с памятью. Очевидные теперь решены.

Машина имеет следующие настройки

JAVA_OPTS="$JAVA_OPTS 
-server 
-Xms704m 
-Xmx704m 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/log/tomcat6 
-XX:MaxPermSize=192m 
-XX:+UseConcMarkSweepGC 
-XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing 
-XX:+DisableExplicitGC
" 

Мы используем Java 6, Tomcat6, Spring Framework, Hibernate, EHCache для кеширования и используем Quartz для различных задач планирования. На самом деле этот элемент ссылка помог решить некоторые проблемы, которые привели к тому, что MAT сообщал о потенциальных утечках памяти, что больше не так.

Мы много играли со всевозможными настройками JVM на нашем тестовом блоке, но во всех случаях время сборки мусора продолжало расти до неприемлемых уровней, в основном из-за постоянно растущего YGCT. Первоначально я думал, что виноват кеш, поскольку мы кэшируем графы объектов, а не просто используем кеш второго уровня Hibernate. Но использование кеш-памяти в MAT не выглядело чрезмерным при размере около 18 Мбайт.

Это утечка памяти или мне просто нужно добавить больше памяти? Если это утечка памяти, как мне лучше всего отладить ее в MAT?


person Marc    schedule 27.06.2012    source источник
comment
ПОЧЕМУ -Xms И -Xmx равны? в идеале не должно быть равных.   -  person Akhi    schedule 27.06.2012


Ответы (2)


Насколько я понимаю, это абсолютно нормально. В столбце YGCT отображается сумма всех действий YGC с момента запуска JVM. То же самое, конечно, касается FGCT и GCT.

Заметили ли вы какое-то снижение производительности через некоторое время или это вопрос чисто научного характера?

person Tomasz Jędzierowski    schedule 27.06.2012
comment
Нет, я замечаю периодические резкие всплески обработки, приводящие к тайм-аутам. Обычно это длится около 30 секунд. После этого все снова супер быстро. Я предполагаю, что это из-за обработки мусора. - person Marc; 27.06.2012

YGC YGCT FGC FGCT GCT со временем будет увеличиваться, поскольку они накапливаются. Что вас должно интересовать, так это разница.

Либо вы недостаточно быстро выполняете мониторинг, либо собираете мусор довольно часто. Я бы попытался увеличить объем памяти до тех пор, пока это не будет иметь большого значения. например Обычно я начинаю с кучи 8 ГБ с пространством eden 6 ГБ, но вы можете предпочесть что-то другое.

person Peter Lawrey    schedule 27.06.2012