Всем здравствуйте!

Периодически падает jvm по причине OutOfMemoryError.

Как мне отловить утечку памяти?

Для того, чобы понять, где утечка, я включил опции -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/jmap . Версия jvm - 6.02. Версия ОС: SuSe Linux 10.2.

Но при падении по причине нехватки памяти дамп памяти не создается.

Запись в логе:
авторSEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.LeaderFollowerWorkerThread@1236
1e3, terminating thread
а затем:
автор# java.lang.OutOfMemoryError: requested 2048000 bytes for GrET in /BUILD_AREA/jdk6_02/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space?
#
# Internal Error (414C4C4F434154494F4E0E494E4C494E450E4850500017), pid=15746, tid=601537440
#
# Java VM: Java HotSpot(TM) Server VM (1.6.0_02-b05 mixed mode)
# An error report file with more information is saved as hs_err_pid15746.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
В данном случае он написал две записи об OutOfMemoryError. Но как правило пишет только одну запись - вторую.

По пути /opt свободно 6Гб. Под java машину я выделил 3Гб (-Xmx3g). То-есть, дамп памяти вряд ли не создался по причине нехватки места на диске.

И еще один момент. Через какое-то время после падения сервера я ищу jvm-процес командой
ps -ef | grep java, но java-машины он не находит. То-есть, падение такое, что даже jvm-процесс в Linux убивается...

Еще интерестный момент. Когда я смотрю гистрограмму памяти (jmap -histo:live <pid>), то jvm обычно потребляет 1.2-1.8 Гб памяти (из максимальных 3 Гб). Так вот, примерно в 19:10 jvm потребляла 1.2Гб, а в 19:45 того же дня вся память закончилась... Перед этим сайт простоял 3 суток, и проработал в режиме "каждые 40 минут освобождал память до 1-2Гб, а потом медленно накапливал до 3 Гб). А в этот раз память он просто не освободил.

Таким образом, насколько я понимаю, память в принципе не накапливается постепенно. Похоже, что либо она накапливается в течение 45 минут, либо просто почему-то не освобождается...

Скриншоты приложены. Первый скриншот - jconsole, второй - jmeter.

Скажите, как можно устранить эту утечку памяти? Потому что у меня уже просто нет вариантов :(

Заранее просто огромное спасибо! Вы меня здорово выручите!

Плавали, знаем2. Запускал профайлер Jprofiler
А есть где-нибудь статья, как обнаруживать утечки памяти с Jprofiler?

Потому что, во-первых, сайт потребляет примерно 1-2Гб памяти. Поэтому у меня не хватает памяти для JProfiler, чтобы запускать сайт под JProfiler.

А во-вторых, garbage collector же не работает так, что после каждого пользовательского запроса чистит память. Я вот выполнил запрос, какая-то память была зарезервирована. И после каждого сеанса GC по чуть-чуть эта память освобождается. И я никогда не знаю, объекты, которые в определенный момент еще не освободились после запроса, действительно утекли, или они будут когда-нибудь освобождены при будущих запусках GC?

Вобщем, как мне узнать, объекты действительно утекли, или они мусор? Учитывая еще и то, что у меня куча кешей разной длительности.

И еще один момент. Обратите, пожалуйста, внимание на графики памяти, которые я приложил. Как здесь видно, GC для OldGen срабатывает примерно раз в 45 минут успешно (каждые 45 минут видно, как количество потребляемой памяти падает до 1-2Гб), и в каждые эти 45-минутные интервалы потребляемая память плавно растет. А тут вдруг в этот раз GC для OldGen'а рас - и не освободил ничего!

Вот у меня и возникает вопрос - как это может быть? Может, произошел какой-то сбой в jvm, и она не запустила GC для OldGen? Или как тогда может быть, что за тот же временной интервал вся память, накопленная за 45 минут, стала неосвобождаемой?

Пожалуйста, проанализируйте график!

Софтверный проктолог Vetal
Java имеет весьма широкие возможности тюнинга работы Garbage Collector'а. Может быть вам стоит в них разобраться?
И что мне это даст? Я знаю, какие есть ключики для настройки GC. При этом ни одна из настроек не позволяет избежать утечек памяти. Все эти настройки - только для оптимизации производительности...