Отладка странной утечки памяти - Java / Tomcat

Question

У меня очень странная проблема с Java-приложением, запущенным под Tomcat.

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

Очень странно то, что при взгляде на VisualVM для использования памяти он никогда не превышает максимальный размер кучи, JVM не выбрасываетOutOfMemory, машина только начинает обмениваться, и JVM продолжает работать даже после этого.

Итак, кажется, что откуда-то происходит утечка памяти, кажется, что это из нового кода, но странно, что это не внутри JVMЛюбые идеи в том, как это отладить?

Спасибо!

Answer 1

Обмен не является окончательным показателем утечки.Это связано с недостатком физической памяти.Используйте vmstat в Linux, чтобы использовать своп.Попробуйте использовать другую машину, поэкспериментируйте с конфигурациями - размер свопа, размер физической памяти, адресное пространство.

Если вы уверены, что проблема в вашей программе, попробуйте следующее:

1. Оцените медиану и пиковую память, которую ваша программа должна использовать.Вы должны быть в состоянии учесть все отклонения от этих показателей.Если вы не можете, перейдите к шагу 3.

2. Предполагая, что вы выполнили шаг 1 правильно и смогли учесть все отклонения, вы можете исключить утечку (извините за такие расплывчатые предложения, но отладкатолько так хорошо, как детектив).Теперь вы должны сосредоточиться на настройке GC.Сначала включите ведение журнала GC.Посмотрите, заполнена ли ваша куча и где GC тратит большую часть своего времени на сбор. может быть хорошей отправной точкой для начала оптимизации.Попробуйте посмотреть, помогает ли настройка параметров GC.Попробуйте поэкспериментировать с алгоритмами сбора, максимальными / минимальными размерами кучи, соотношениями генераторов и т. Д. Экспериментируйте только тогда, когда вы исключили утечку (шаг 1).

3. Предполагая, что вы выполнили шаг 1 правильно и не смогли учесть все отклонения, вы можете предположить, что где-то произошла утечка.Используйте профилировщик памяти, чтобы увидеть, какие объекты способствуют увеличению размера кучи.Оставьте профилировщик включенным на длительный период времени - обработайте вашу программу некоторыми запросами, которые она обычно ожидает получить, а затем оставьте ее относительно изолированной после этого.Если уровень памяти продолжает расти, возможно, где-то произошла утечка.Если нет, то это, вероятно, не утечка памяти.Можете ли вы указать ту часть вашей программы, которая может их создавать?Если да, попробуйте отправить несколько запросов, предназначенных только для этой части вашей программы.Это дублирует проблему детерминистически?Если нет, повторите шаг 3. Если да, используйте «разделяй и властвуй» и повторяйте шаг 3, пока не найдете класс / метод, которые являются виновниками.Это может быть также определенная комбинация нескольких частей (это означает, что по отдельности они могут выглядеть невинными, но вместе они могут образовать блестящий преступный синдикат).

Надеюсь, что это поможет, если нет, то, пожалуйста,оставить комментарий к моему посту.

Всего наилучшего в ваших упражнениях!

Answer 2

Я бы посоветовал вам заняться созданием дампов кучи без использования jvisualvm. Для Oracle JVM на основе Unix это обычно делается отправкой сигнала 3 в JVM с помощью kill.

Для получения полной информации см. http://www.startux.de/index.php/java/45-java-heap-dumpyvComment45

Затем вы можете увидеть, изменится ли шаблон.

Если вы не получаете представление об этом, то это может быть связано с тем, что вы храните подстроку из очень большой исходной строки (которая содержит базовый массив строк), или потому что вы держитесь за ресурсы операционной системы. например, соединения с открытой базой данных и т. д.

Вы проверили, что ваш пул соединений выглядит хорошо?

Answer 3

Если вы не используете его, я бы порекомендовал использовать visual VM версии 1.3.2 и все плагины. Это большой скачок с более ранних версий.

Что происходит с Пермским пространством?

Какие настройки памяти вы используете? Мин и макс, конечно, но как насчет размера пермского пространства?