Я думаю, что наиболее эффективный способ анализа журнала сборщика мусора - это посмотреть на сам вывод.Все наши производственные серверы работают с использованием Concurrent Mark Sweep Collector, и у меня есть журнал, работающий с параметрами -Xloggc:$GCLOGFILE -XX:+PrintGCDetails
, и если в среде возникают проблемы, я
- сначала проверим количество Full GC, выполнив команду grepдля "Full GC" и
- Проверьте количество и частоту CMS и найдите сообщения об ошибках на этапе сбора (обычно начинайте с "failed to ...").
Я также обычно смотрю на список потоков и проверяю количество процессорного времени, которое потребляет сборщик мусора.Я делаю это, выполняя команду top с параметром -p <java-pid>
и затем нажимая «H», и вы видите пиды, которые потребляют больше всего времени процессора.Затем его можно сопоставить с дампом потока, чтобы узнать, являются ли потоки gc самыми трудоемкими.Каждый поток имеет pid, отображаемый в дампе потока, который находится в шестнадцатеричном формате, его можно сопоставить с pids сверху.
Очень важно видеть, сколько процессор потребляет GC, и сопоставлять его с вашим журналом.выход.Я пробовал GCViewer несколько раз, но никогда не получал полезных подсказок от визуального отображения GC-Data.