Отслеживание проблемы утечки памяти / сборки мусора в Java

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

Я пробовал jmap, пока процесс работал, но обычно это приводило к дальнейшему зависанию jvm, и мне приходилось запускать его с --force. Это приводило к дампам кучи, в которых, казалось, не хватало большого количества данных или, по крайней мере, отсутствовали ссылки между ними. Для анализа я попробовал jhat, который представляет много данных, но не так много о том, как их интерпретировать. Во-вторых, я попробовал инструмент анализа памяти на основе eclipse (http://www.eclipse.org/mat/), который показал, что куча - это в основном классы, связанные с tomcat.

Проблема заключалась в том, что jmap не сообщал о фактическом состоянии приложения и улавливал только классы при завершении работы, которые в основном были классами tomcat.

Я попробовал еще несколько раз и заметил, что было очень много объектов модели (на самом деле в 2-3 раза больше, чем было помечено как общедоступные в базе данных).

Используя это, я проанализировал журналы медленных запросов и несколько не связанных с производительностью проблем. Я пробовал выполнять сверхленивую загрузку (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html), а также замену нескольких операций гибернации прямыми запросами jdbc (в основном там, где речь идет о загрузке и работе с большими коллекциями - замены jdbc просто работали непосредственно с таблицами соединения) и заменили некоторые другие неэффективные запросы, которые mysql регистрировал.

Эти шаги улучшили производительность внешнего интерфейса, но по-прежнему не решили проблему утечки, приложение по-прежнему работало нестабильно и непредсказуемо.

Наконец, я нашел вариант: -XX: + HeapDumpOnOutOfMemoryError. В итоге получился очень большой (~ 6,5 ГБ) файл hprof, который точно отображал состояние приложения. По иронии судьбы, файл был настолько большим, что jhat не мог его проанализировать даже на коробке с 16 ГБ оперативной памяти. К счастью, MAT смогла построить несколько красивых графиков и показать некоторые более точные данные.

На этот раз бросился в глаза единственный кварцевый поток, занимавший 4,5 ГБ из 6 ГБ кучи, и большая часть из них была StatefulPersistenceContext в спящем режиме (https://www.hibernate.org/hib_docs/v3/api/org/hibernate/engine/StatefulPersistenceContext.html). Этот класс используется внутри спящего режима в качестве основного кеша (я отключил кеши второго уровня и кеши запросов, поддерживаемые EHCache).

Этот класс используется для включения большинства функций спящего режима, поэтому его нельзя напрямую отключить (вы можете обойти его напрямую, но Spring не поддерживает сеанс без сохранения состояния), и я был бы очень удивлен, если бы у него был такой большая утечка памяти в зрелом продукте. Так почему он протекал сейчас?

Что ж, это была комбинация вещей: экземпляр кварцевого пула потоков с некоторыми вещами threadLocal, spring внедрял фабрику сеансов, которая создавала сеанс в начале жизненного цикла кварцевых потоков, который затем повторно использовался для запуска различные кварцевые задания, которые использовали сеанс гибернации. Затем Hibernate кэшировал в сеансе, что является его ожидаемым поведением.

Проблема в том, что пул потоков никогда не освобождает сеанс, поэтому спящий режим оставался резидентным и поддерживал кеш для жизненного цикла сеанса. Поскольку здесь использовалась поддержка шаблонов спящего режима пружин, явного использования сеансов не было (мы используем иерархию dao -> manager -> driver -> quartz-job, dao вводится с конфигурациями гибернации через spring, поэтому операции делается прямо по шаблонам).

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

Решение: создать метод dao, который явно вызывает session.flush () и session.clear (), и вызывать этот метод в начале каждого задания.

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

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

Можете ли вы запустить производственную коробку с включенным JMX?

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<port>
...

Мониторинг и управление с помощью JMX

А затем прикрепить с помощью JConsole, VisualVM?

Можно ли делать дамп кучи с помощью jmap ?

Если да, вы можете проанализировать дамп кучи на наличие утечек с помощью JProfiler (у вас уже есть), jhat, VisualVM, Eclipse MAT. Также сравните дампы кучи, которые могут помочь найти утечки / шаблоны.

И, как вы упомянули, jakarta-commons. При использовании jakarta-commons-logging возникает проблема, связанная с удержанием загрузчика классов. Для хорошего прочтения этого чека

Один день из жизни охотника за утечками памяти ( _ 2_ < / а>)

Похоже, утечка памяти, отличной от кучи, вы упоминаете, что куча остается стабильной. Классическим кандидатом является permgen (постоянная генерация), которая состоит из двух вещей: загруженных объектов класса и интернированных строк. Поскольку вы сообщаете о подключении к VisualVM, вы должны увидеть количество загруженных классов, если количество загруженных классов продолжает расти (важно, visualvm также показывает общее количество когда-либо загруженных классов, Ничего страшного, если он возрастет, но количество загруженных классов должно стабилизироваться через определенное время).

Если это действительно утечка permgen, то отладка становится более сложной, поскольку инструменты для анализа permgen скорее отсутствуют по сравнению с кучей. Лучше всего запустить на сервере небольшой скрипт, который неоднократно (каждый час?) Вызывает:

jmap -permstat <pid> > somefile<timestamp>.txt

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

После того, как вы определили определенные классы как загружаемые, а не выгружаемые, вы можете мысленно выяснить, где они могут быть сгенерированы, в противном случае вы можете использовать jhat для анализа дампов, созданных с помощью jmap -dump. Я сохраню это для будущего обновления, если вам понадобится информация.

Я бы поискал напрямую выделенный ByteBuffer.

Из файла javadoc.

Прямой байтовый буфер может быть создан путем вызова фабричного метода allocateDirect этого класса. Буферы, возвращаемые этим методом, обычно имеют несколько более высокие затраты на выделение и освобождение, чем непрямые буферы. Содержимое прямых буферов может находиться за пределами обычной кучи, собираемой мусором, поэтому их влияние на объем памяти приложения может быть неочевидным. Поэтому рекомендуется выделять прямые буферы в первую очередь для больших долговечных буферов, на которые действуют собственные операции ввода-вывода базовой системы. В общем, лучше всего выделять прямые буферы только тогда, когда они дают ощутимый выигрыш в производительности программы.

Возможно, код Tomcat использует это do для ввода-вывода; настроить Tomcat для использования другого коннектора.

В противном случае у вас может быть поток, который периодически выполняет System.gc (). "-XX: + ExplicitGCInvokesConcurrent" может быть интересным вариантом.

Любой JAXB? Я считаю, что JAXB - это средство для перманентного пространства.

Кроме того, я считаю, что visualgc, теперь поставляемый с JDK 6, является отличным способом увидеть что происходит в памяти. Он прекрасно показывает райское пространство, пространство поколений и перманентное поведение, а также переходное поведение GC. Все, что вам нужно, это PID процесса. Может быть, это поможет, пока вы работаете над JProfile.

А как насчет аспектов трассировки / ведения журнала Spring? Может быть, вы можете написать простой аспект, применить его декларативно и таким образом сделать профилировщик для бедняков.

"К сожалению, проблема также возникает время от времени, она кажется непредсказуемой, она может работать в течение нескольких дней или даже недели без каких-либо проблем, или она может выходить из строя 40 раз в день, и единственное, что я могу постоянно ловить в том, что сборщик мусора действует. "

Похоже, это связано с вариантом использования, который выполняется до 40 раз в день, а затем уже не в течение нескольких дней. Надеюсь, вы отслеживаете не только симптомы. Это должно быть что-то, что вы можете сузить, отслеживая действия субъектов приложения (пользователей, вакансий, сервисов).

Если это происходит при импорте XML, вам следует сравнить XML-данные за 40 дней сбоев с данными, которые были импортированы в день без сбоев. Может быть, это какая-то логическая проблема, которую вы не найдете только в своем коде.

У меня была такая же проблема, но с некоторыми отличиями ..

Моя технология следующая:

grails 2.2.4

tomcat7

quartz-plugin 1.0

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

Еще одна вещь, которую следует учитывать, - это плагин quartz, вводящий сеанс гибернации в кварцевые потоки, как говорит @liam, и кварцевые потоки все еще живы, пока я не закончу приложение.

Моя проблема заключалась в ошибке ORM grails в сочетании с тем, как плагин обрабатывает сеанс и два моих источника данных.

В плагине Quartz есть слушатель для инициализации и уничтожения сеансов гибернации.

public class SessionBinderJobListener extends JobListenerSupport {

    public static final String NAME = "sessionBinderListener";

    private PersistenceContextInterceptor persistenceInterceptor;

    public String getName() {
        return NAME;
    }

    public PersistenceContextInterceptor getPersistenceInterceptor() {
        return persistenceInterceptor;
    }

    public void setPersistenceInterceptor(PersistenceContextInterceptor persistenceInterceptor) {
        this.persistenceInterceptor = persistenceInterceptor;
    }

    public void jobToBeExecuted(JobExecutionContext context) {
        if (persistenceInterceptor != null) {
            persistenceInterceptor.init();
        }
    }

    public void jobWasExecuted(JobExecutionContext context, JobExecutionException exception) {
        if (persistenceInterceptor != null) {
            persistenceInterceptor.flush();
            persistenceInterceptor.destroy();
        }
    }
}

В моем случае persistenceInterceptor экземпляров AggregatePersistenceContextInterceptor, и у него был список HibernatePersistenceContextInterceptor. По одному для каждого источника данных.

Каждая операция, выполняемая с AggregatePersistenceContextInterceptor, передается в HibernatePersistence без каких-либо изменений или обработок.

Когда мы вызываем init() на HibernatePersistenceContextInterceptor, он увеличивает статическую переменную ниже

private static ThreadLocal<Integer> nestingCount = new ThreadLocal<Integer>();

Я не знаю, зачем нужен этот статический счет. Я просто знаю, что он увеличился в два раза, по одному на источник данных, из-за реализации AggregatePersistence.

Пока здесь я просто объясняю cenario.

Проблема возникает сейчас ...

Когда моя работа с кварцем завершается, плагин вызывает слушателя, чтобы очистить и уничтожить сеансы гибернации, как вы можете видеть в исходном коде SessionBinderJobListener.

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

Упрощение того, что сделал Hibernate:

if(--nestingCount.getValue() > 0)
    do nothing;
else
    close the session;

Это основа моей утечки памяти. Кварцевые потоки все еще живы со всеми объектами, используемыми в сеансе, потому что ORM grails не закрывает сеанс из-за ошибки, вызванной тем, что у меня есть два источника данных.

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