Как обнаружить нехватку памяти?

Question

У меня есть приложение, работающее на Websphere Application Server 6.0, и оно почти каждый день вылетает из-за нехватки памяти. Из многословного GC наверняка есть утечки памяти (многие из них)

К сожалению, приложение предоставлено внешним поставщиком, а исправление проблем - медленный и болезненный процесс. В рамках этого процесса мне нужно собирать журналы и heapdumps каждый раз, когда происходит OOM.

Теперь я ищу способ автоматизировать его. Фундаментальная проблема заключается в том, как определить состояние ООМ. Одним из способов будет создание сценария оболочки, который будет периодически искать новые heapdumps. Такой подход мне кажется немного грязным. Другой подход может заключаться в том, чтобы как-то использовать JMX. Но у меня мало или совсем нет опыта в этой области, и я не знаю, как это сделать.

Или в WAS есть какие-то триггеры / зацепки для этого? Большое спасибо за каждый совет!

Answer 1

При запуске вы можете передать следующие аргументы JVM, и в OutOfMemoryError будет автоматически создан дамп кучи. Второй аргумент позволяет указать путь к файлу дампа кучи. По крайней мере, с помощью этого вы можете проверить наличие определенного файла, чтобы увидеть, произошел ли дамп кучи.

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<value>

Answer 2

Я вижу два варианта, если вы хотите автоматизировать дамп кучи, но @ Решение Марка с дампом кучи в OOM не является удовлетворительным.

1. Вы можете использовать MemoryMXBean для обнаружения высокого давления памяти, а затем программно создать дамп кучи , если использование (или дельта использования) кажется высоким.
   • Вы можете периодически получать информацию об использовании памяти и создавать дампы кучи с помощью сценария оболочки cron'd, используя jmap (работает как локально, так и удаленно).

Было бы неплохо, если бы у вас был обратный вызов на OOM, но, возможно, этот обратный вызов просто завершился бы с ошибкой OOM. :)

Answer 3

Вы смотрели на JConsole ? Он использует JMX, чтобы предоставить вам обзор различных метрик JVM, включая информацию о памяти. Вероятно, стоило бы начать мониторинг вашего приложения с помощью этого, чтобы понять, как и когда используется память. Вы можете обнаружить, что память используется равномерно в течение дня или при использовании определенных функций.

Взгляните на раздел обнаружение недостатка памяти в приведенной выше ссылке.

Если вам нужно, вы можете написать JMX-клиент , чтобы автоматически просматривать приложение и запускать любые необходимые действия. JConsole укажет, какие методы JMX нужно опрашивать.

Answer 4

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

Может быть, даже websphere может сделать это для вас!?

Answer 5

Наш опыт работы с ITCAM был менее чем звездным с точки зрения мониторинга. Мы отказались от него в пользу CA Wily Introscope.

Answer 6

Вы можете добавить класс прослушивателя (слушателя атрибута области действия или атрибута области приложения), который будет вызываться при каждом добавлении нового объекта в область сеанса / приложения.

В этом случае вы можете попытаться проверить общий объем памяти, используемой приложением (зарегистрировать его), так как вызов gc запускается (обратите внимание, что при его вызове gc всегда не будет работать)

(Выше приведено для части регистрации и gc в зависимости от роста использования)

Для запланированного gc: Кроме того, вы можете сохранить класс задач таймера, который запускается через каждые несколько часов и выполняет запрос для gc.

Answer 7

Должна быть возможность написать простую программу, которая получит список процессов из ядра и просканирует его, чтобы увидеть, работает ли еще ваш процесс WAS. В Unix-боксе вы, возможно, могли бы за несколько минут что-то вспомнить в Perl (если вы знаете Perl), не зная, насколько это будет сложно под Windows. Запускайте его как запланированное задание каждые пять минут или около того, и, если процесс не обнаруживается, вы можете отключить его от другого процесса, который будет иметь дело с дампом кучи, и перезапустите WAS.

Answer 8

Я бы поспорил, что вам нужны дампы кучи, когда происходит OOM. Периодический сбор информации со временем должен дать представление о том, что происходит.

Как было отмечено, существуют различные инструменты для анализа этих проблем. У меня был успех с ITCAM для WebSphere, как у IBM, у меня есть готовый доступ к этому. Мы очень быстро смогли определить точные строки кода в нашей проблемной ситуации.

Если есть какой-то способ, которым вы можете получить инструмент такого рода, то это путь.

Answer 9

Вы уже знакомы с инструментом jvisualvm в последней версии Java 6 JDK?

Отлично подходит для проверки работающего кода.