Есть ли способ идентифицировать сбои параллельного режима CMS через JMX? - PullRequest
Новая
       34

Есть ли способ идентифицировать сбои параллельного режима CMS через JMX?

1 голос
/ 29 марта 2011

Итак, я пытался найти хороший способ отслеживать, когда JVM может потенциально приближаться к ситуации с OOM. Лучший способ, который, кажется, работает с нашим приложением, - это отслеживать параллельные сбои параллельного режима через CMS. Это указывает на то, что штатный пул заполняется быстрее, чем он может на самом деле себя очистить, или его восстановление очень мало.

Компонент JMX для отслеживания GC имеет очень общую информацию, такую ​​как использование памяти до / после и т.п. Эта информация была в лучшем случае относительно противоречивой. Есть ли лучший способ, которым я могу отслеживать этот потенциальный предупреждающий знак умирающей JVM?

Ответы [ 2 ]

2 голосов
/ 30 марта 2011

Если вы используете Sun JVM, мне известны 2 варианта;

  1. mxbeans для управления памятью (ссылка на API здесь ), которую вы, похоже, уже используете, хотя обратите внимание, что есть некоторые внутренние точки доступа, к которым вы можете получить доступ, см. в этом блоге приведен пример использования
  2. jstat: cmd: здесь , вам понадобится опция -gccause.Вы можете либо написать скрипт для запуска этого и проанализировать выходные данные, либо, теоретически, вы можете создать процесс из хоста jvm (или другого), который затем считывает выходной поток из jstat для обнаружения причин gc.Я не думаю, что информация о причинах является на 100% полной, хотя.Я не знаю способ получить эту информацию программно из Java-кода.
0 голосов
/ 29 марта 2011

При использовании стандартного JRE 1.6 GC использование кучи со временем может увеличиваться, а сборщик мусора работает реже и реже, в зависимости от характера вашего приложения и вашего максимального заданного размера кучи. Тем не менее, трудно сказать, что происходит, не имея больше информации.

Несколько методов для дальнейшего изучения:

Вы можете получить дамп кучи вашего приложения во время его работы с использованием jmap, а затем проверить кучу с помощью jhat, чтобы увидеть, какие объекты находятся в куче в любой момент времени.

Вы также можете запустить ваше приложение с -XX: + HeapDumpOnOutOfMemoryError, которое автоматически создаст дамп кучи при первом исключении из нехватки памяти, с которым сталкивается JVM.

Вы можете создать bean-компонент мониторинга, специфичный для вашего приложения, и создать методы доступа, которые можно использовать с удаленным клиентом JMX. Например, методы для возврата размеров очередей и других коллекций, которые, вероятно, являются местами использования памяти в вашей программе.

НТН

...