Проникновение памяти без увеличения количества или размера объектов

Ответ 1

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

Однако в этом процессе я продемонстрировал, что IBM J9 JVM, используемая в AS/400 (aka iSeries, Systemi, i5 и др.), имеет утечку 1336 байт в минуту в сумме 2 МБ/день. Я могу наблюдать эту утечку с помощью множества программ из "однострочной" тестовой программы вплоть до нашего сервера приложений.

Однострочная тестовая программа такова:

public class ZMemoryLeak2
extends Object
{

static public synchronized void main(String... args) {
    try { ZMemoryLeak2.class.wait(0); } catch(InterruptedException thr) { System.exit(0); }
    }

}

И отдельная тестовая программа, которая ничего не делала, кроме использования памяти монитора через JMX API, убедительно показала, что 1336 B просачивается ровно через 1 минуту, никогда не восстанавливается (ну, не регенерируется после 2 недель работы). OP Примечание: на каждой вариации JVM на самом деле было несколько разное количество.

Обновление 2012-04-02. Это было принято как ошибка IBM несколько недель назад; он был фактически найден и исправлен на Java 5 примерно в середине прошлого года, и ожидается, что патч для Java 6 будет доступен в течение следующей недели или двух.

Ответ 2

Отличный вопрос. Думал, что я отвечу некоторые из моих комментариев в ответ.

• Вы отмечаете, что простаивающая система растет с точки зрения памяти. Это важный бит информации. Либо есть некоторые внутренние запланированные задания (автоматизация, таймеры и т.д.), Либо внешний мониторинг процесса, который вызывает пропускную способность объекта. Я хотел бы отключить мониторинг, чтобы увидеть, затронуты ли графики. Это может помочь вам выяснить, какие объекты являются частью проблемы.

• Когда объект находится под нагрузкой, я подозреваю, что существует определенная пропускная способность объекта. Ваша конечная проблема может заключаться в том, что IBM JVM не обрабатывает фрагментацию памяти, а также другие JVM - я удивлен этим. Я бы работал с ними, чтобы попробовать другие варианты GC, чтобы увидеть, как вы можете это решить. Я бы подумал, что это было бы легко смоделировать, если бы вы написали тестовый сервер, который выполнял целую кучу операций с памятью, и посмотрел, растет ли в течение нескольких дней использование памяти. Это может показать, что настало время уйти от IBM JVM. Опять же, это меня удивило бы, но если то, что вы говорите, верно, а количество или размер объектов не растет...

• Я бы посмотрел графики различных разделов памяти. Я подозреваю, что вы видите, как пространство старого поколения поднимается и опускается, и выжившие постоянно стекаются. Если верно, что количество объектов не меняется, то @Stephen должен быть прав относительно их внутреннего размера или чего-то еще, что он работает. Возможно, учет объекта не может сообщить о них по какой-либо причине.

• Я обнаружил, что кнопка gc JMX на вкладке памяти выполняет более полную развертку. Это должно быть эквивалентно использованию System.gc(), который вы пробовали. Просто FYI.

• Было бы неплохо включить вывод журнала GC, чтобы увидеть, можете ли вы видеть любые шаблоны: http://christiansons.net/mike/blog/2008/12/java-garbage-collection-logging/ и http://java.sun.com/developer/technicalArticles/Programming/GCPortal/

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

Надеюсь, что-то здесь полезно.

Ответ 3

Одно из возможных объяснений заключается в том, что вы видите создание объектов в кеше, реализованных с помощью WeakReference или аналогичных. Сценарий выглядит следующим образом:

• Циклы GC, которые вы видите на графике, являются коллекциями нового пространства и не вызывают нарушения ссылок. Таким образом, кеш продолжает расти и использовать больше кучи.

• Когда вы делаете снимок, это приводит к запуску полного GC, который (возможно) разбивает ссылки и освобождает кешированные объекты.

(Обратите внимание на "возможно". Я не уверен, что это объяснение содержит воду...)

Другим возможным объяснением является то, что ваше приложение имеет одинаковое количество объектов, но некоторые из них больше. Например, у вас может быть массив некоторого примитивного типа, который вы будете перераспределять с большим размером. Или StringBuilder/StringBuffer продолжает расти. Или (в некоторых случаях) ArrayList или подобное, которое продолжает расти.

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