A step-by-step approach toward high quality OutOfMemoryError analysis

© 2016 NetCracker Technology Corporation Confidential
Разбор сложных случаев OutOfMemoryError
Владимир Ситников
JEEConf 2016

2© 2016 NetCracker Technology Corporation Confidential
• Владимир Ситников
• Performance engineer @ NetCracker
• sitnikov@netcracker.com
• @VladimirSitnikv
Кто я

О чём доклад
• Разбор некоторых out of memory: OS, JVM
• Примеры подходов к анализу/защите от OOM
• OpenJDK/OracleJDK

Как понять, что память закончилась?
Видим в логах OutOfMemoryError – значит наш случай
• OutOfMemoryError: Java heap space
• OutOfMemoryError: heap allocation failed
• OutOfMemoryError: PermGen/Metadata space
• OutOfMemoryError: unable to create native thread
• ...

Дело о потерянном процессе
• Java процесс работал и пропал

• hs_err файл не появился

• В out, err, log пусто

• В out, err, log пусто
• Как так?

OOMkiller
У Linux память конечна, и если она
заканчивается, то может случиться разное:
• умрёт невезучий процесс (по умолчанию)

OOMkiller
• malloc вернёт ошибку «нет памяти»

OOMkiller
• malloc вернёт ошибку «нет памяти»
Ключевое слово в Linux: vm.overcommit_memory=0

vm.overcommit_memory=0
• Выглядит хорошо (не будет overcommit)

• Выглядит хорошо (не будет overcommit)
• Работает не всегда: многие процессы выделяют,
но не используют память (~fork syscall)

Смотрим потребление памяти
$ top
PID VIRT RES COMMAND
18133 9606m 7.3g ora_dbw0_DB11
32600 2163m 843m /jdk170_55/bin/java -Xmx200m

$ top
18133 9606m 7.3g ora_dbw0_DB11
$ free –g (http://www.linuxatemyram.com/)
total used free
Mem: 31 31 0
-/+ buffers/cache: 10 21
Swap: 8 3 5
Занимаемая память
Свободная
память

$ top
18133 9606m 7.3g ora_dbw0_DB11

Следим за native памятью
• -XX:+NativeMemoryTracking=[off|summary|detail]

• Работает начиная с 1.7u40

• Работает начиная с 1.7u40
• Получить разбивку можно через
• jcmd <pid> VM.native_memory <output_file_name>
• -XX:+PrintNMTStatistics -XX:+UnlockDiagnosticVMOptions
• Или JMX: com.sun.management:type=
DiagnosticCommand/vmNativeMemory

NMT на практике

Ценный мех NMT
NMT позволяет
• более адресно заводить тикеты на OpenJDK
• проверять наличие утечек «служебной» памяти
Пример: GROOVY-7498 Groovy native memory leak

Накладные расходы
• В 1.7u40 активация NMT замедляет на 5-10%
• http://hirt.se/blog/?p=401
• В 1.8u40 вошла доработка масштабируемости
NMT
• JEP 195: Scalable Native Memory Tracking

Запускаем процесс
new ProcessBuilder("ping","123.321.123.321")
.start();

Запускаем процесс
new ProcessBuilder("ping", "8.8.8.8")
.start();

На самом деле, можно
Если версия JDK свежая, то проблем нет:
• https://bugs.openjdk.java.net/browse/JDK-5049299
• 1.7u60+ всё ок
• 1.8u??+ (в 8u60 исправление есть наверняка)

В предыдущих серияхверсиях
• ProcessBuilder#start() использует fork()
• -Xmx8g «по наследству» передаётся в ping
• В итоге ping либо не запустится, либо есть
шанс разбудить oomkiller

Как запускать процессы в OpenJDK<1.7u60
• Либо вообще не запускать процессы

Как запускать процессы в OpenJDK<1.7u60
• Либо вообще не запускать процессы
• Либо использовать jnr-posix (напрямую или из JRuby)
• https://github.com/jnr/jnr-posix

OutOfMemoryError: unable to create native thread
• Кто виноват?

• 32bit JVM и в адресном пространстве уже негде выделить
место для стека (thread native stack)

• Что делать?
• Переходить на 64bit JVM

• Переходить на 64bit JVM
• Или уменьшать -XX:ThreadStackSize, уменьшать -
XX:MaxPermSize

А какая у нас версия?
$ java -Xmx800m -version
Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new
native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.lang.ref.Finalizer.<clinit>(Finalizer:226)

limits
$ ulimit –a

limits
$ ulimit –a
virtual memory (kbytes, -v) unlimited

limits
$ ulimit –a
open files (-n) 16384

limits
$ ulimit –a
max user processes (-u) 100000

limits
$ ulimit –a
max user processes (-u) 100000
stack size (kbytes, -s) 10240

Действия в случае OutOfMemoryError
try {
"основной_монитор".notifyAll();
} catch (OutOfMemoryError e) {
log.info("Нужно больше памяти", e);
}

Реальные проблемы
• OOM может получить любой поток в любой
момент времени

• Например, ReentrantLock в момент unlock

• И мы получим вечнозанятую блокировку,
сломанную ArrayBlockingQueue, …

• И мы получим вечнозанятую блокировку,
сломанную ArrayBlockingQueue, …
• Аналогично и в случае StackOverflowError

В случае аварии
В случае OutOfMemoryError/StackOverflowError
гораздо правильнее делать так:
• System.exit(146)
• -XX:OnError="kill -9 %p"

• Но как же ReentrantLock?

• Но как же ReentrantLock?
• JEP 270: Reserved Stack Areas for Critical Sections
доработка включена в JDK9

В случае аварии
В случае OutOfMemoryError/StackOverflowError
гораздо правильнее
делать так:
• java 1.8u92+: JDK-8138745
-XX:+ExitOnOutOfMemory
-XX:+CrashOnOutOfMemory

Java heap
• Хранит java объекты, их содержимое

Java heap
• Очищается сборщиком мусора

Java heap
• Очищается сборщиком мусора
• Бывает, заканчивается

OutOfMemoryError: PermGen space
• Размер PermGen слишком мал
• Загружено слишком много классов

• Увеличивать perm gen: -XX:PermSize=512M -
XX:MaxPermSize=512M
• Искать лишние классы: jmap –histo

• Увеличивать perm gen: -XX:PermSize=512M -
XX:MaxPermSize=512M
• Искать лишние классы: jmap –histo
• Обновлять java (в 8-ке будет ошибка Metadata space:)

OutOfMemoryError: Java heap space
• Выделено мало памяти
• Garbage Collector не успел собрать мусор
• Выделять больше памяти: -Xms, -Xmx
• Анализировать использование памяти

Как анализировать занятость heap
GC log фиксирует приход-расход памяти по времени

• Как собрать: -Xloggc:logs/gc.log, -XX:+PrintGCDetails, и т.д.

• Чем смотреть: GCViewer

• Чем смотреть: GCViewer
• На что смотреть: «занятость памяти после full gc»

GC лог здорового человека
• 60мс minor, 3sec major паузы

GC лог курильщика
• Сплошные full gc

Недоперепил
• Бывает, памяти остаётся мало
• GC постоянно как-то находит крохи мусора

• А OutOfMemory всё нет и нет!

• А OutOfMemory всё нет и нет!
• Что делать, шеф?

Варианты действий, когда почти OOM
• Jmap – снимать дамп вручную

• GC overhead limit

• -XX:GCHeapFreeLimit=20 (2 по умолчанию)
‒Если после full GC останется меньше X%, то OOM

• -XX:GCHeapFreeLimit=20 (2 по умолчанию)
‒Если после full GC останется меньше X%, то OOM
• -XX:GCTimeLimit=Y (98 по умолчанию)
‒Если сборка мусора занимает более Y%
времени, то OOM

Чисто там, где не мусорят
• Java Flight Recorder / Java Mission Control

Как понять, кто создаёт объекты?
Java Flight Recorder
• Позволяет узнать stack trace где создавались объекты
• Позволяет узнать объём выделяемой памяти

• Бесплатно на test серверах

Запуск:
• -XX:+UnlockCommercialFeatures -XX:+FlightRecorder
-XX:FlightRecorderOptions=repository=jfr,defaultrecording=false

Запуск:
• -XX:+UnlockCommercialFeatures -XX:+FlightRecorder
-XX:FlightRecorderOptions=repository=jfr,defaultrecording=false
• jcmd <pid> JFR.start duration=2m filename=logs/myrecording.jfr
settings=profile stackdepth=2000

OOM: heap space
Дамп памяти содержит снимок содержимого java heap
• Как собрать: -XX:HeapDumpOnOutOfMemoryError

OOM: heap space
• jmap -dump

OOM: heap space
• jmap -dump
• jmap -dump -F (force режим, если обычный не работает)

OOM: heap space
• jmap -dump
• jmap -dump -F (force режим, если обычный не работает)
• Чем смотреть: Eclipse Memory Analyzer, VisualVM, jol, jvm-tools

Скорость работы jmap
$jmap –dump ..
real 0m7.992s
user 0m0.304s
sys 0m0.067s
$ jmap –dump –F ..
real 24m4.378s
user 21m56.321s
sys 6m51.676s

В тяжёлых случаях
• core dump быстрее и надёжнее чем jmap -dump <pid>
$ ulimit –c
core file size (blocks, -c) 33’222’111

В тяжёлых случаях
• core dump быстрее и надёжнее чем jmap -dump <pid>
$ ulimit –c
core file size (blocks, -c) 33’222’111
• Из core dump можно получить hprof (через jmap …)

• Дамп памяти содержит данные всех объектов
• Состояние потоков (thread dump)
• Значения локальных переменных
Дампы памяти

• Дамп памяти содержит данные всех объектов
• Состояние потоков (thread dump)
• Значения локальных переменных
Дампы памяти
Да, пароли там
тоже есть

• -Xmx2G, OracleJDK 1.8u60
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid59998.hprof ...
Heap dump file created [1’650’484 bytes in 0.023 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap
space
at Demo1.main(Demo1.java:6)
Маловато будет

• -Xmx2G, OracleJDK 1.8u60
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid59998.hprof ...
Heap dump file created [1’650’484 bytes in 0.023 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap
space
at Demo1.main(Demo1.java:6)
Маловато будет
long len = Runtime.getRuntime().maxMemory();
long[] array = new long[(int) len];  Demo1.java:6

Терминология
«утекла память», «потребилась память»
== кто-то мешает GC её освободить

Кто может держать память?
• Потоки (threads)

• Локальные переменные

• Кишки JVM

• Кишки JVM
• И далее по цепочкам простых ссылок,
WeakReferences, SoftReferences,
PhantomReferences

• Кишки JVM
• И далее по цепочкам простых ссылок,
WeakReferences, SoftReferences,
PhantomReferences, FinalReferences
‾√

‾√
WeakHashMap<K, V>
K1 V1
K2 V2

‾√
WeakHashMap<K, V>

WeakHashMap<K, V>
K1 V1
K2 V2
√‾

И освободится ли WeakHashMap<K, V>?
K1 V1
K2 V2
?√‾

√‾
Освобождению не подлежит
K1 V1
K2 V2

√‾
K1 V1
K2 V2

И кто же так делает?
• XML element
• Элемент хранит ссылку на документ, а тот на всё
остальное

И кто же так делает?
• XML element
• Элемент хранит ссылку на документ, а тот на всё
остальное
• java.beans.…

Пример из жизни
•Запускаем Groovy

•Из JSR223 API (scripting API)

•Из JSR223 API (scripting API)
•И получаем OutOfMemoryError

Терминология
Для любого объекта Ы есть 2 основных метрики
• Shallow heap – объём памяти, занимаемый самим
объектом
• Retained heap – объём памяти, который освободится,
если Ы окажется мусором

Dominator tree
2 3
4 5
№2 не доминирует №3
№4 доминирует №5
√‾

Groovy + Scripting for Java (JSR 223) = печаль (demo1)
Демо: groovy

Dominator Tree (demo1)
• Показывает объекты, которые держат больше всего других

Разбираем строку в число
* http://shipilev.net/blog/2014/exceptional-performance
static long toLongFast(char[] c)
throws IllegalArgumentException {
if (c.length == 1)
return c[0] - '0';
// Пусть с дробными разбираются другие
throw new IllegalArgumentException(); *
}

Так быстрее, но не утечёт ли память?
static final IllegalArgumentException
CFE = new IllegalArgumentException();
static long toLongFast(char[] c)
throws IllegalArgumentException {
if (c.length == 1)
return c[0] - '0';
throw CFE;

Throwable наносит ответный удар
• StackTraceElement это сплошные строки, но в
Throwable есть скрытое поле backtrace

• Оно прекрасно держит ссылки на классы из стектрейса

• Оно прекрасно держит ссылки на классы из стектрейса
• Иногда это может быть неожиданной ссылкой на класс

Мораль
• Либо не используем «ControlFlowException»
• Либо не заполняем stacktrace
static final IllegalArgumentException
CFE = new IllegalArgumentException() {
public Throwable fillInStackTrace() {
return this;
}
}

Object#finalize
Не стоит использовать finalizer’ы для «освобождения ресурсов»
• Finalizable объекты живут на 1 цикл GC (падают в old gen, ужас-
ужас)

Object#finalize
Не стоит использовать finalizer’ы для «освобождения ресурсов»
• Finalizable объекты живут на 1 цикл GC (падают в old gen, ужас-
ужас)
• Невозможно объяснить JVM, что объект не надо
финализировать (если вручную вызвали .close)

Object#finalize -> PhantomReference
PhantomReference позволяет организовать «автоматическое
освобождение ресурсов» с поддержкой ручного:
• PhantomReference сохраняется в какую-нибудь map/set

• Если объект выходит из видимости, GC обрабатывает Phantom

• Если объект выходит из видимости, GC обрабатывает Phantom
• Если пользователь закрыл объект вручную, то там же и
очищается Phantom

PhantomReference
Map<Reference<Statement>, String> resources;
ReferenceQueue<Statement> queue = new ReferenceQueue<>();
public void autoCleanup() throws Throwable {
PreparedStatement ps = con.prepareStatement("select 1");
PhantomReference<Statement> ref = new PhantomReference<>(ps,
queue);
resources.put(ref, "name");
/* В методе .close(): */ ref.clear();
}

На практике
• PostgreSQL JDBC драйвер pgjdbc использовал
Statement#finalize
• @Benchmark на «создание statement» падал с OOM
• После исключения finalize, стало 45ns/create даже
при 100% утекании (т.е. без ручных вызовов close):
https://github.com/pgjdbc/pgjdbc/pull/299

• @shipilёv: не все хипдампы одинаково полезны
Eclipse Memory Analyzer

Puzzler
++i--
Что это?

Puzzler
++i--
^^^ оператор подёргивания

Демо

Dominator Tree
• Отображает то, сколько освободится, если удалить объект

• Quiz: Может ли объект дважды попасть в Dominator Tree?

Основные окна Eclipse MAT (demo2)
• Class Histogram
• Показывает суммарную информацию по классам

• Как не погрязнуть в вечном разворачивании плюсиков?

Алгоритм анализа дампов в Eclipse MAT
• Retained Set
• Immediate Dominators

• Dominator Tree
• Retained Set

• Dominator Tree
• Retained Set
• Retained Set
• Retained Set

Dominator Tree
• “Show Retained Set” показывает плоский список удерживаемых
объектов

Immediate dominators
• Кто-то очень любит HashMap$Entry. Как узнать кто?
• Immediate dominators!

HashMap$Entry
• Если очень захотеть, то можно сделать Map с
накладными расходами в 4 байта на запись

HashMap$Entry
• Если очень захотеть, то можно сделать Map с
накладными расходами в 4 байта на запись
• https://github.com/vlsi/compactmap
• См. v8/design.html#prop_access

Но как же автоматизация?
• В Eclipse есть Object Query Language

• В Eclipse есть Object Query Language
• В простых случаях даже работает

• В Eclipse есть ограниченный :( Object Query Language
• Нет group by
• Нет join
• Нет distinct

OQL!
• В Eclipse есть ограниченный :( Object Query Language
• Нет group by
• Нет join
• Нет distinct
• Может, оно и не нужно?

Примеры, когда OQL пасует
• Если в одной коллекции хранятся разнородные
данные, то OQL не подходит
• EJB bean cache
• Свои кэши данных
• Если данные разбиты по разным java-объектам, то
OQL не подходит

Ты ж программист
• Берём SQL engine: Apache Calcite

• Прикручиваем его к MAT: mat-calcite-plugin

• Прикручиваем его к MAT: mat-calcite-plugin
• Получаем:
• JOIN, WHERE, GROUP BY, ORDER BY, HAVING
• UNION, INTERSECT
• Подзапросы
• Аналитические функции (WINDOW, OVER)

Пример SQL
-- Tables:
-- "java.lang.BigInteger" list of all BigIntegers
-- "instanceof java.lang.BigInteger" BigIntegers and all
select u."@THIS", s."@RETAINED"
from "java.lang.String" s
, "java.net.URL" u
where s."@THIS" = u.path

Mat-calcite-plugin
• Плюсы:
• Хорошая поддержка SQL
• Ставится из MAT (“install new software…”)

Mat-calcite-plugin
• Плюсы:
• Хорошая поддержка SQL
• Ставится из MAT (“install new software…”)
• Минусы:
• Подходит не для каждого запроса: Calcite заточен
под full scan
• Обход графа на SQL это та ещё радость

VisualVM
• VisualVM UI работает неторопливо, но OQL позволяет
выполнять javascript map-reduce
• Распечатка System.properties:
select map(filter(heap.findClass('java.lang.System').props.table
, 'it != null && it.key != null && it.value != null')
, function (it) {
var res = it.key.toString() + ' = ' + it.value.toString();
return res; });

aragozin/jvm-tools
• На очень больших дампах, dominator tree построить
невозможно
• В таких случаях поможет HeapPath из состава
aragozin/jvm-tools:
• field1.field2.field3.*.field4
• arrayField[0].arrayField2[*].field5
• hashMap?entrySet[key=name].value

Ты ж java программист
• Java object layout хорошо подходит для анализа
индивидуальных объектов:
http://hg.openjdk.java.net/code-tools/jol/…/samples/

• Плюсы:
• Управляется из java кода
• Выдаёт точные значения

• Плюсы:
• Выдаёт точные значения
• Минусы:

Выводы
• До OOM стараемся не доводить (-Xmx, thread pools)
• Если довели, то снимаем хипдамп (jmap, coredump)
• Обновляем JVM ради: исправления ошибок,
инструментария

• Владимир Ситников
• Performance engineer @ NetCracker
• sitnikov@netcracker.com
• @VladimirSitnikv
Спасибо

Спасибо

A step-by-step approach toward high quality OutOfMemoryError analysis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to A step-by-step approach toward high quality OutOfMemoryError analysis

Similar to A step-by-step approach toward high quality OutOfMemoryError analysis (20)

A step-by-step approach toward high quality OutOfMemoryError analysis