Java 8 JVM зависает, но не вылетает / сбрасывает кучу, когда не хватает памяти

Question

При нехватке памяти Java 8 под управлением Tomcat 8 никогда не останавливается после дампа кучи. Вместо этого он просто зависает, поскольку он максимально исчерпывает память. Сервер становится очень медленным и не реагирует на запросы из-за обширного GC, поскольку он медленно приближается к максимальному объему памяти. График памяти в плоских линиях JConsole после нажатия макс. 64-разрядная версия Linux / Java "1.8.0_102" / Tomcat 8. Jconsole

Я установил -XX: HeapDumpOnOutOfMemoryError и -XX: HeapDumpPath. Кто-нибудь знает, как заставить дамп кучи вместо перехода JVM в режим неотвечающего / очень медленного ответа?

Answer 1

jmap - это утилита, которая создаст дамп кучи для любого работающего jvm.Это позволит вам создать дамп кучи перед сбоем

https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr014.html

Тем не менее, это вопрос времени, чтобы знать, когда вы должны его создать.Вы можете взять последующие кучи и использовать инструменты для сравнения кучи.Я настоятельно рекомендую Eclipse Memory Access Tool и его вид дерева доминирования для выявления потенциальных проблем с памятью (https://www.eclipse.org/mat/)

Answer 2

Кто-нибудь знает, как заставить дамп кучи вместо перехода JVM в режим без ответа / очень медленный ответ?

Вам нужно использовать -XX:+UseGCOverheadLimit. Это говорит GC выбросить OOME (или сбросить кучу, если вы настроили это), когда процент времени, потраченного на сбор мусора, становится слишком высоким. Это должно быть включено по умолчанию для недавней JVM ... но вы, возможно, отключили его.

Вы можете настроить пороги «накладных расходов» для отказа коллектора, используя -XX:GCTimeLimit=... и -XX:GCHeapFreeLimit=...; см https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html

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

Другая возможность состоит в том, что вашей JVM требуется очень много времени, чтобы сбросить кучу. Это может произойти, если реальная проблема заключается в том, что ваша JVM вызывает перегрузку виртуальной памяти, поскольку использование памяти Java значительно превышает объем физической памяти.