Сборка мусора Java G1 в производстве

https://stackoverflow.com/questions/2254041

20-09-2019
|

Вопрос

Поскольку Java 7 по умолчанию будет использовать новую сборку мусора G1, сможет ли Java обрабатывать на порядок большую кучу без предполагаемого «разрушительного» времени паузы GC?Кто-нибудь действительно реализовал G1 в производстве, каковы ваши впечатления?

Честно говоря, единственный раз, когда я видел действительно длинные паузы GC, это на очень больших кучах, гораздо больше, чем на рабочей станции.Чтобы прояснить мой вопрос;G1 откроет шлюз к кучам в сотни ГБ?ТБ?

Решение

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

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

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

РЕДАКТИРОВАТЬ:

при перечитывании мне пришло в голову, что я использую Java ежедневно - Eclipse, Azureus и приложения, которые разрабатываю, и прошло ДОЛГОЕ ВРЕМЯ с тех пор, как я видел паузу.Незначительная пауза, но я имею в виду любую паузу вообще.

Я видел паузы, когда щелкал правой кнопкой мыши по проводнику Windows или (иногда) при подключении определенного USB-оборудования, но с Java - вообще никаких.

Является ли GC по-прежнему проблемой для кого-либо?

Другие советы

Я тестировал это с тяжелым приложением:В куче выделено 60–70 ГБ, в любое время используется 20–50 ГБ.С такими приложениями будет преуменьшением сказать, что ваш пробег может отличаться.Я использую JDK 1.6_22 в Linux.Второстепенные версии важны — примерно до 1.6_20 в G1 были ошибки, вызывавшие случайные исключения NullPointerException.

Я обнаружил, что он очень хорошо удерживается в пределах заданной вами паузы большую часть времени.По умолчанию пауза составляет 100 мс (0,1 секунды), и я просил сделать половину этой паузы (-XX:MaxGCPauseMillis=50).Однако, как только ему становится очень мало памяти, он паникует и выполняет полную остановку сборки мусора.С 65 ГБ это занимает от 30 секунд до 2 минут.(Количество процессоров, вероятно, не имеет значения;вероятно, это ограничено скоростью автобуса.)

По сравнению с CMS (которая не является серверным сборщиком мусора по умолчанию, но должна быть для веб-серверов и других приложений реального времени), типичные паузы гораздо более предсказуемы и могут быть значительно короче.Пока что мне больше везет с CMS в плане огромных пауз, но это может быть случайно;Я вижу их всего несколько раз в 24 часа.Я не уверен, какой из них будет более подходящим в моей производственной среде на данный момент, но, вероятно, G1.Если Oracle продолжит его настройку, я подозреваю, что G1 в конечном итоге станет явным победителем.

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

Хотя я не тестировал G1 в производстве, я решил прокомментировать, что сборщики мусора уже проблематичны для случаев без «огромных» куч.В частности, GC может серьезно повлиять на услуги, скажем, с 2 или 4 гигабайтами.Сборщики мусора молодого поколения обычно не вызывают проблем, поскольку они заканчивают работу за однозначные миллисекунды (или, самое большее, за двузначные цифры).Но коллекции старого поколения гораздо более проблематичны, поскольку они занимают несколько секунд при размерах старого поколения в 1 гигабайт или выше.

Сейчас:Теоретически CMS может здесь очень помочь, поскольку она может выполнять большую часть своей работы одновременно.Однако со временем возникнут случаи, когда он не сможет этого сделать и будет вынужден вернуться к сбору «остановить мир».И когда это произойдет (скажем, через 1 час — не часто, но все же слишком часто), что ж, держитесь за свои чертовы шляпы.Это может занять минуту или больше.Это особенно проблематично для сервисов, которые пытаются ограничить максимальную задержку;вместо того, чтобы обслужить запрос, скажем, за 25 миллисекунд, теперь требуется десять секунд или больше.Чтобы добавить травму к оскорблению, клиенты часто прерывают запрос и повторяют попытку, что приводит к дальнейшим проблемам (также известным как «дерьмовый шторм»).

Это одна из областей, где G1 надеялись очень помочь.Я работал в крупной компании, предлагающей облачные сервисы для хранения и отправки сообщений;и мы не могли использовать CMS, поскольку, хотя большую часть времени она работала лучше, чем параллельные версии, с ней случались сбои.Итак, около часа все было хорошо;а потом что-то попало в вентилятор...и поскольку служба была основана на кластерах, когда у одного узла возникала проблема, другие обычно следовали за ним (поскольку тайм-ауты, вызванные GC, приводят к тому, что другие узлы считают, что узел вышел из строя, что приводит к перенаправлению).

Я не думаю, что GC представляет собой большую проблему для приложений, и, возможно, даже некластеризованные сервисы страдают от этого реже.Но все больше и больше систем кластеризуются (особенно.благодаря хранилищам данных NoSQL) и размеры кучи растут.Сборщики мусора OldGen суперлинейно связаны с размером кучи (это означает, что удвоение размера кучи более чем удваивает время сборки мусора, при условии, что размер живого набора данных также удваивается).

Технический директор Azul, Гил Тене, сделал хороший обзор проблем, связанных со сборкой мусора, и обзор различных решений в своей книге. Понимание сборки мусора Java и что с этим можно сделать презентация, а в этой статье есть дополнительная информация: http://www.infoq.com/articles/azul_gc_in_detail.

Сборщик мусора Azul C4 в нашей JVM Zing работает одновременно и параллельно, и использует один и тот же механизм сбора мусора как для нового, так и для старого поколения, работая одновременно и уплотняя в обоих случаях.Самое главное, что C4 не имеет возможности остановить мир.Все уплотнение выполняется одновременно с работающим приложением.У нас есть клиенты, работающие с очень большими объемами (сотни ГБ) с худшим временем паузы GC <10 мс, а в зависимости от приложения часто меньше 1-2 мс.

Проблема с CMS и G1 заключается в том, что в какой-то момент память кучи Java должна быть сжата, и оба этих сборщика мусора останавливают мир/STW (т.приостановите приложение), чтобы выполнить уплотнение.Таким образом, хотя CMS и G1 могут вытеснять паузы STW, они не устраняют их.Однако C4 от Azul полностью устраняет паузы STW, и именно поэтому у Zing такие низкие паузы GC даже для гигантских размеров кучи.

И чтобы исправить утверждение, сделанное в предыдущем ответе, Zing не требует никаких изменений в операционной системе.Он работает так же, как и любая другая JVM, в немодифицированных дистрибутивах Linux.

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

Мы используем следующие настройки JVM:

-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

Обновлено

-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000

Коллектор G1 снижает влияние полных коллекций.Если у вас есть приложение, в котором вы уже уменьшили потребность в полных коллекциях, сборщик Concurrent Map Sweep так же хорош и, по моему опыту, имеет более короткое время сбора мелких данных.

Похоже, что G1, начиная с JDK7u4, наконец-то официально поддерживается, см. RN для JDK7u4.http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html.

Судя по нашему тестированию на больших JVM, настроенная CMS по-прежнему работает лучше, чем G1, но я думаю, что она будет расти лучше.

CMS может привести к медленному снижению производительности, даже если вы используете ее без накопления постоянных объектов.Это происходит из-за фрагментации памяти, которой предположительно избегает G1.

Миф о том, что G1 доступен только с платной поддержкой – это всего лишь миф.Sun, а теперь и Oracle разъяснили это на странице JDK.

G1 GC должен работать лучше.Но если задать -XX:MaxGCPauseMilli слишком агрессивно, мусор будет собираться слишком медленно.Вот почему в примере Дэвида Леппика сработал полный GC.

Я только что реализовал сборщик мусора G1 в нашем проекте Terracotta Big Memory.При работе с различными типами коллекторов G1 дал нам наилучшие результаты со временем отклика менее 600 мс.

Вы можете найти результаты тестов (всего 26) здесь

Надеюсь, поможет.

Недавно меня перевели из

CMS для G1GC с кучей 4G и 8-ядерным процессором на серверах с JDK 1.7.45.

(JDK 1.8.x G1GC предпочтительнее версии 1.7, но из-за некоторых ограничений мне приходится придерживаться версии 1.7.45)

Я настроил ниже ключевые параметры и сохранил для всех остальных параметров значения по умолчанию.

-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n apart from -Xms and -Xmx

Если вы хотите точно настроить эти параметры, посмотрите это оракул статья.

Ключевые наблюдения:

Использование памяти соответствует G1GC, в отличие от высоких и низких значений у CMS.
Максимальное время паузы GC меньше по сравнению с CMS.
Время, затрачиваемое на сбор мусора, в G1GC немного выше, чем в CMS.
Количество крупных коллекций практически незначительно по сравнению с CMS.
Количество второстепенных коллекций выше, чем в CMS.

Но все же я рад, что время паузы Max GC меньше, чем в CMS.Я установил время паузы Max GC как 1,5 секунды и это значение еще не было пересечено.

Связанный вопрос SE:

Сборка мусора Java 7 (JDK 7) и документация по G1

Недавно я перенес часть Twicsy на новый сервер с 128 ГБ ОЗУ и решил использовать версию 1.7.Я начал использовать те же настройки памяти, что и в версии 1.6 (у меня есть несколько экземпляров, которые выполняют разные задачи, от 500 МБ кучи до 15 ГБ, а теперь новый с 40 ГБ), и это совсем не сработало. .Похоже, что версия 1.7 использует больше кучи, чем версия 1.6, и в первые несколько дней у меня возникло множество проблем.К счастью, у меня было достаточно оперативной памяти для работы, и я увеличил ее для большинства своих процессов, но некоторые проблемы все равно оставались.Моим обычным способом было использовать очень маленький минимальный размер кучи — 16 м, даже при максимальной куче в несколько гигабайт, а затем включить инкрементный сборщик мусора.Это позволило свести паузы к минимуму.Однако сейчас это не работает, и мне пришлось увеличить минимальный размер примерно до того, который я ожидал использовать в среднем в куче, и это сработало очень хорошо.У меня все еще включен инкрементный сборщик мусора, но я попробую без него.Никаких пауз сейчас нет, и кажется, что все идет очень быстро.Итак, я думаю, что мораль этой истории такова: не ждите, что настройки вашей памяти будут идеально переводиться с 1,6 на 1,7.

G1 делает приложение намного более гибким:задержка приложения увеличится - приложение можно назвать «мягким в реальном времени».Это делается путем замены двух типов прогонов GC (маленьких второстепенных и одного большого на Tenured Gen) на маленькие одинакового размера.

Для более подробной информации посмотрите это:http://geekroom.de/java/java-expertise-g1-fur-java-7/

Я работаю с Java, для маленькой и большой кучи, и вопрос о GC и Full GC возникает каждый день, так как ограничения могут быть более строгими, чем у других:в определенной среде 0,1 секунды сборщика мусора или полного сбора мусора, просто убейте функциональность, и важно иметь мелкозернистую конфигурацию и возможности (CMS, iCMS, другие...Цель состоит в том, чтобы получить максимально возможное время отклика при обработке почти в реальном времени (здесь обработка в реальном времени часто составляет 25 мс), поэтому, в принципе, любые улучшения в эргономике и эвристике GC приветствуются!

Я использую G1GC в Java 8, а также в Groovy (также Java 8), выполняю различные виды рабочих нагрузок, и в целом G1GC работает следующим образом:

Использование памяти очень низкое, например.100 МБ вместо 500 МБ по сравнению с настройками Java по умолчанию.
Время отклика стабильное и очень низкое
Производительность между настройками по умолчанию и G1GC снижается на 20 % при использовании G1GC в худшем случае (без настройки, однопоточное приложение).Это не так уж и много, учитывая хорошее время отклика и низкое использование памяти.
При запуске из Tomcat, который является многопоточным, общая производительность на 30% выше, а использование памяти намного ниже, а время отклика намного меньше.

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

Не рекомендуется использовать java8 с G1GC для расчета с плавающей запятой с помощью JVM, подобного горячей точке.Это опасно для целостности и точности приложения.

https://bugs.openjdk.java.net/browse/JDK-8148175

JDK-8165766

JDK-8186112

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow