Объем памяти Java растет неограниченно, но MemoryMXBean сообщает о стабильной куче и размере не кучи

Ответ 1

Я попытаюсь частично ответить на ваш вопрос.

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

В вашем случае похоже, что у вас действительно есть проблема с утечкой памяти, которая довольно неприятна и трудно найти.

Вы можете попытаться профилировать память. Посмотрите на корни GC и узнайте, какие из них являются JNI глобальными ссылками. Это может помочь вам узнать, какие классы не могут быть собраны. Например, это общая проблема в awt, которая может потребовать явного удаления компонентов.

Чтобы проверить использование внутренней памяти JVM (которая не принадлежит памяти кучи/неактивной памяти) -XX:NativeMemoryTracking, очень удобно. Он позволяет отслеживать размеры стека потоков, накладные расходы gc/компилятора и многое другое. Самое главное в том, что вы можете создать базовую линию в любой момент времени, а затем отслеживать различия в памяти с момента создания базовой линии.

# jcmd <pid> VM.native_memory baseline
# jcmd <pid> VM.native_memory summary.diff scale=MB

Total:  reserved=664624KB  -20610KB, committed=254344KB -20610KB
...

Вы также можете использовать команду JMX com.sun.management:type=DiagnosticCommand/vmNativeMemory для создания этих отчетов.

И... Вы можете пойти глубже и проверить pmap -x <pid> и/или procfs.

Ответ 2

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

TL;DR:

Проблема была вызвана ошибкой в ​​JDK, которая теперь исправлена ​​и будет транслироваться с помощью JDK 8u152. Ссылка на отчет об ошибке

Вся история:

Мы продолжали следить за производительностью памяти приложений после того, как я впервые разместил этот вопрос, а метод XX: NativeMemoryTracking, предложенный vsminkov, значительно помог сузить и определить область в памяти, которая протекала.

Мы обнаружили, что область "Протектор - Аренас" растет бесконечно. Поскольку такая утечка была чем-то, что мы были уверены, что мы не сталкивались раньше, мы начали тестирование с более ранними версиями java, чтобы узнать, было ли это введено в какой-то конкретной точке.

После возврата к java 8u73 утечки не было, и хотя принуждение использовать более старую версию JDK не было оптимальным, по крайней мере у нас был способ обойти проблему на данный момент.

Несколько недель спустя, во время работы с обновлением 73, мы заметили, что приложение все еще протекает, и мы снова начали искать виновника. Мы обнаружили, что проблема теперь находится в области Class - malloc.

На этом этапе мы почти наверняка обнаружили, что утечка не была нашей ошибкой в ​​приложении, и мы рассматривали возможность обращения к Oracle, чтобы сообщить о проблеме как потенциальной ошибке, но затем мой коллега наткнулся на этот отчет об ошибке в компиляторе JDK hotspot: Ссылка на отчет об ошибке

Описание ошибки очень похоже на то, что мы видели. Согласно тому, что написано в отчете, утечка памяти присутствует с момента выпуска java 8, и после тестирования с ранним выпуском JDK 8u152 мы теперь уверены, что утечка исправлена. По прошествии 5 дней работы область видимости нашей прикладной памяти теперь кажется почти стабильной на 100%. Область malloc класса все еще немного растет, но сейчас она растет со скоростью около 100 КБ в день (по сравнению с несколькими МБ ранее), и, протестировав только на 5 дней, я не могу сказать наверняка, что она не стабилизируется в конечном итоге.

Я не могу сказать наверняка, но, похоже, проблемы, связанные с ростом класса malloc и Thread arenas, были связаны. В любой момент обе проблемы исчезли в обновлении 152. К сожалению, обновление, похоже, не запланировано для официального выпуска до конца 2017 года, но наше тестирование с ранним выпуском кажется многообещающим до сих пор.