Как уменьшить Java параллельный отказ режима и чрезмерный gc

Question

Как уменьшить Java параллельный отказ режима и чрезмерный gc

В Java параллельный отказ режима означает, что параллельному коллектору не удалось освободить достаточно пространства памяти, формируют штатного и постоянного генерала и должен сдаться и впустить full stop-world удары gc. Конечный результат мог быть очень дорогим.

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

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

Я хотел бы учиться от разработчиков здесь, как Ваш опыт? Если Вы встретились с такой проблемой производительности, какова была причина и как Вы обратились к ней?

Если у Вас есть рекомендации кодирования, не будьте слишком общими.Спасибо!

44

java garbage-collection concurrency

задан Gunner 21 February 2014 в 03:27

2 ответа

Другие вопросы по тегам:

java garbage-collection concurrency

Похожие вопросы:

score 12 · Answer 1

Цитируется по "Understanding Concurrent Mark Sweep Garbage Collector Logs"

Сбоя одновременного режима можно либо можно избежать, увеличив размер поколения или инициируя CMS при меньшей занятости кучи установив CMSInitiatingOccupancyFraction на меньшее значение

Однако, если в вашем приложении действительно есть утечка памяти, вы просто выигрываете время.

Если вам нужен быстрый перезапуск и восстановление и вы предпочитаете "умереть быстро", я бы предложил вообще не использовать CMS. Я бы придерживался '-XX:+UseParallelGC'.

Из "Эргономика сборщика мусора"

Параллельный сборщик мусора (UseParallelGC) выбрасывает исключение вне памяти, если чрезмерное количество времени тратится на сбор небольшого объема кучи. Чтобы избежать этого исключения, вы можете увеличить размер кучи. Вы можете также установить параметры -XX:GCTimeLimit=time-limit and -XX:GCHeapFreeLimit=space-limit

score 4 · Answer 2

Иногда OOM довольно быстро убивался, иногда долго терпел период gc (последний раз было более 10 часов).

Мне кажется, что утечка памяти лежит в основе ваших проблем.

Сбой CMS не будет (насколько я понимаю) вызвать OOM. Скорее всего, сбой CMS происходит из-за того, что JVM нужно слишком быстро делать слишком много коллекций, и CMS не успевает. Одна из ситуаций, когда за короткий период происходит множество циклов сбора, - это когда ваша куча почти заполнена.

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

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

РЕДАКТИРОВАТЬ - вариант -XX: GCHeapFreeLimit = nnn , где nnn - число от 0 до 100, указывающее минимальный процент кучи, который должен быть свободным после GC. По умолчанию - 2.Этот параметр указан на странице «Самый полный список параметров -XX для Java 6 JVM» . (Там перечислено множество параметров -XX, которых нет в документации Sun. К сожалению, на странице мало подробностей о том, что на самом деле делают эти параметры.)

Вам, вероятно, следует начать поискать, есть ли в вашем приложении / веб-приложении утечки памяти. Если это так, ваши проблемы не исчезнут, пока эти утечки не будут обнаружены и устранены. В долгосрочной перспективе возиться с опциями Hotspot GC не удастся исправить утечки памяти.