Мониторинг пространства кучи Java - мы делаем это неправильно?

Question

У нас есть проверка Nagios, которая проверяет состояние памяти кучи на некоторых экземплярах Tomcat. Команда, которую он использует для получения метрик от ВМ, выглядит следующим образом:

java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Memory HeapMemoryUsage

, который производит вывод, такой как:

committed: 132579328
init: 134217728
max: 401014784
used: 18831512

Предупреждение срабатывает, если значение против used превышает 90% значения против max. Мне это кажется ошибочным, в основном потому, что значение max может уменьшаться, а также увеличиваться :)

Какую информацию мы должны использовать для правильного мониторинга использования пространства кучи?

Должен ли я сравнивать max со значением Xmx?

Я могу получить значение Xmx, используя следующую команду:

java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Runtime InputArguments

Есть ли лучший способ?

Answer 1

По моим наблюдениям, значение "max" колеблется. При мониторинге примера Java-процесса используемая куча изменяется так, как вы и ожидаете, но значения commit и max также динамически изменяются по мере того, как используемая куча приближается к этим пределам (я считаю, что коэффициенты настраиваются).

В моем случае флаг Xmx был установлен на 9 ГиБ, и, как ни странно, зафиксированные и максимальные значения иногда превышали это (9,2 ГиБ)?

Java имеет тенденцию агрессивно использовать доступное пространство кучи, поэтому используемый размер кучи, иногда достигающий 100%, меня не беспокоит. Вместо этого меня больше интересовало бы среднее значение за последние 5, 10 и 15 минут и т. Д. Если используемая куча остается выше 90% в течение длительных периодов, у вас могут возникнуть проблемы - проверка накладных расходов GC будет хорошим индикатором ( и любой OOME очевидно).