Метод обнаружения утечки памяти в больших дампах кучи Java

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

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

Я провел последние пару недель, делая именно это, и я использовал итеративный процесс.

Во-первых, я обнаружил, что профилировщики кучи практически бесполезны. Они не могут эффективно анализировать огромные кучи.

Скорее, я почти полностью полагался на гистограммы jmap. .

Я полагаю, вы знакомы с ними, но для тех, кто нет:

jmap -histo:live <pid> > dump.out

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

Я сбрасывал кучу регулярно, каждые 5 минут, 24 часа в сутки. Возможно, это слишком подробно для вас, но суть та же.

Я провел несколько различных анализов этих данных.

Я написал скрипт, который берет две гистограммы и выводит разницу между ними. Таким образом, если java.lang.String было равно 10 в первом дампе и 15 во втором, мой сценарий выдал бы «5 java.lang.String», сообщая мне, что он увеличился на 5. Если он уменьшился, число было бы отрицательным.

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

Тем не менее, некоторые классы сохранились, а другие были GC. Эти классы могут легко повышаться и понижаться в целом, но все равно будут протекать. Таким образом, они могли выпасть из категории «всегда повышающихся» классов.

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

Я нашел этот процесс очень успешным и действительно эффективным. Файлы гистограмм не так уж велики, и их было легко скачать с хостов. Они не были слишком дорогими для запуска в производственной системе (они требуют большого GC и могут немного заблокировать виртуальную машину). Я запускал это в системе с кучей Java 2G.

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

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

Например, вы можете обнаружить, что у вас много классов Map.Entry или какой-то другой системный класс.

Если вы просто не кэшируете String, дело в том, что эти системные классы, хотя, возможно, и «нарушители», не являются «проблемой». Если вы кэшируете какой-то класс приложения, ЭТОТ класс является лучшим индикатором того, в чем заключается ваша проблема. Если вы не кэшируете com.app.youurbean, у вас не будет связанной с ним Map.Entry.

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

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

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

Профилировщик может помочь вам отследить владельцев этого «теперь просочившегося» класса.

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

Взгляните на анализатор памяти Eclipse. Это отличный инструмент (и автономный, не требует установки самого Eclipse), который 1) может очень быстро открывать очень большие кучи и 2) имеет несколько довольно хороших инструментов автоматического обнаружения. Последнее не идеально, но EMA предоставляет множество действительно хороших способов навигации и запроса объектов в дампе, чтобы найти любые возможные утечки.

Я использовал его в прошлом, чтобы помочь выследить подозрительные утечки.

Этот ответ расширяет ответ @Will-Hartung's. Я применил тот же процесс для диагностики одной из моих утечек памяти и подумал, что если поделиться подробностями, это сэкономит время другим людям.

Идея состоит в том, чтобы постгрес «графил» время по сравнению с использованием памяти для каждого класса, рисовал линию, суммирующую рост, и определял объекты, которые растут быстрее всего:

    ^
    |
s   |  Legend:
i   |  *  - data point
z   |  -- - trend
e   |
(   |
b   |                 *
y   |                     --
t   |                  --
e   |             * --    *
s   |           --
)   |       *--      *
    |     --    *
    |  -- *
   --------------------------------------->
                      time

Преобразуйте свои дампы кучи (нужно несколько) в формат, который удобен для использования postgres из формата дампа кучи:

 num     #instances         #bytes  class name 
----------------------------------------------
   1:       4632416      392305928  [C
   2:       6509258      208296256  java.util.HashMap$Node
   3:       4615599      110774376  java.lang.String
   5:         16856       68812488  [B
   6:        278914       67329632  [Ljava.util.HashMap$Node;
   7:       1297968       62302464  
...

В файл csv с датой и временем каждого дампа кучи:

2016.09.20 17:33:40,[C,4632416,392305928
2016.09.20 17:33:40,java.util.HashMap$Node,6509258,208296256
2016.09.20 17:33:40,java.lang.String,4615599,110774376
2016.09.20 17:33:40,[B,16856,68812488
...

Используя этот скрипт:

# Example invocation: convert.heap.hist.to.csv.pl -f heap.2016.09.20.17.33.40.txt -dt "2016.09.20 17:33:40"  >> heap.csv 

 my $file;
 my $dt;
 GetOptions (
     "f=s" => \$file,
     "dt=s" => \$dt
 ) or usage("Error in command line arguments");
 open my $fh, '<', $file or die $!;

my $last=0;
my $lastRotation=0;
 while(not eof($fh)) {
     my $line = <$fh>;
     $line =~ s/\R//g; #remove newlines
     #    1:       4442084      369475664  [C
     my ($instances,$size,$class) = ($line =~ /^\s*\d+:\s+(\d+)\s+(\d+)\s+([\$\[\w\.]+)\s*$/) ;
     if($instances) {
         print "$dt,$class,$instances,$size\n";
     }
 }

 close($fh);

Создайте таблицу, чтобы поместить данные в

CREATE TABLE heap_histogram (
    histwhen timestamp without time zone NOT NULL,
    class character varying NOT NULL,
    instances integer NOT NULL,
    bytes integer NOT NULL
);

Скопируйте данные в новую таблицу

\COPY heap_histogram FROM 'heap.csv'  WITH DELIMITER ',' CSV ;

Запустите запрос slop для запроса размера (количество байтов):

SELECT class, REGR_SLOPE(bytes,extract(epoch from histwhen)) as slope
    FROM public.heap_histogram
    GROUP BY class
    HAVING REGR_SLOPE(bytes,extract(epoch from histwhen)) > 0
    ORDER BY slope DESC
    ;

Интерпретируйте результаты:

         class             |        slope         
---------------------------+----------------------
 java.util.ArrayList       |     71.7993806279174
 java.util.HashMap         |     49.0324576155785
 java.lang.String          |     31.7770770326123
 joe.schmoe.BusinessObject |     23.2036817108056
 java.lang.ThreadLocal     |     20.9013528767851

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

Моя одна из строк кода, создающая этот joe.schmoe.BusinessObject, была ответственна за утечку памяти. Он создавал объект, добавляя его в массив, не проверяя, существует ли он уже. Другие объекты также были созданы вместе с BusinessObject рядом с утечкой кода.

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

Некоторое время назад мы использовали Netbeans для анализа дампов кучи. Это может быть немного медленно, но это было эффективно. Eclipse только что разбился, и 32-битные инструменты Windows тоже.

Если у вас есть доступ к 64-битной системе или системе Linux с 3 ГБ или более, вам будет проще анализировать дампы кучи.

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

Когда все пошло не так? Поговорите с людьми и попытайтесь получить немного истории. Вы можете услышать, как кто-то скажет: «Да, именно после того, как они исправили XYZ в патче 6.43, у нас стали происходить странные вещи».

Мне удалось успешно использовать IBM Heap Analyzer. Он предлагает несколько представлений кучи, в том числе наибольшее уменьшение размера объекта, наиболее часто встречающиеся объекты и объекты, отсортированные по размеру.

Существуют отличные инструменты, такие как Eclipse MAT и Heap Hero, для анализа дампов кучи. Однако вам необходимо предоставить этим инструментам дампы кучи, захваченные в правильном формате и в правильный момент времени.

В этой статье представлены несколько вариантов захвата дампов кучи. Однако, на мой взгляд, первые 3 являются эффективными вариантами, а остальные — хорошими вариантами, о которых следует знать. 1. jmap 2. HeapDumpOnOutOfMemoryError 3. jcmd 4. JVisualVM 5. JMX 6. Программный подход 7. Административная консоль IBM

7 вариантов захвата Java Дампы кучи

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

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

Я использовал jhat, это немного жестко, но это зависит от того, какой у вас был фреймворк.