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

Question

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

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

Answer 1

Предполагая, что вы используете Sun JVM, я знаю 2 варианта;

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

Answer 2

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

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

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

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

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

НТН