Опыт использования ZGC и Shenandoah GC в продакшене

[NikStrig]

В Java 13 починили. m.habr.com/ru/company/jugru/blog/467789

[maximwirt]

Спасибо, будем иметь в виду. Пока у нас Java 11.

[apangin]

Что починили? Если вы про JEP 351, то эта фича вообще о другом.

[UbuRus]

В каком широко используемом docker image есть Shenandoah в составе OpenJDK 11? Докеры имени Ш. это конечно хорошо, но хочется чего-то протестированного

[vektory79]

Shenandoah попадает во все репы RHEL и их производных. В частности в CentOS (откуда мы и используем, правда пока только в тестировании) и Fedora.

Так же этот GC попал в OpenJDK 12 на постоянной основе.

P.S. И раз уж зашла о том речь, то в последнем апдейте Java в Shenandoah поправили важную регрессию, после исправления которой общее быстродействие стало почти на уровне G1 GC (До этого отличие было в десятки процентов): https://bugs.openjdk.java.net/browse/JDK-8232575
P.P.S. В Java 8 с Шенандой не работает отладка. Виснет наглухо. Но есть обходные пути (которые, увы, неприменимы для нас): https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010960.html

[UbuRus]

Shenandoah попадает во все репы RHEL и их производных. В частности в CentOS (откуда мы и используем, правда пока только в тестировании) и Fedora.

Отлично, а готовый image на подобии https://hub.docker.com/_/amazoncorretto есть, чтобы не собирать руками, а взять оттестированный?

Так же этот GC попал в OpenJDK 12 на постоянной основе.

Это да, лучше бы в 11 попал, кто в прод 12-16 тянуть будет

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

Печальненько, видимо придется дальше тюнить G1 на low latency, пока не забекпортят в 11, или ждать 17

[vektory79]

Печальненько, видимо придется дальше тюнить G1 на low latency, пока не забекпортят в 11, или ждать 17

Это-то как раз уже везде забекпортили. Включая 8.

А с готовыми образами — не подскажу...

[UbuRus]

Это-то как раз уже везде забекпортили. Включая 8.

Не вижу этого в тикете, в 11.0.6 ждать?

[vektory79]

Видимо забыли отметить… Информация о портировании поступила от разработчика Шенанды и судя по нашим тестам это так и есть.

Фикс прилетел в 14, 11, 8.

Как раз таки в 11.0.5 попало.

[time2rfc]

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

[apangin]

Казалось бы — делать нечего, будем ждать, пока в Oracle все допилят

Долго ждать бы пришлось… Как Oracle узнает, что у вас есть проблема с ZGC? Вы им репортили? И почему вы решили, что это бага в ZGC, а не в настройках/версии ОС?

ZGC использует технику colored pointers и multi-mapping. Это значит, что один и тот же диапазон физической памяти отображается в несколько виртуальных диапазонов, из-за чего Linux криво считает RSS процесса. Так что очень вероятно, что это не «процесс java израсходовал всю доступную память», а вы его не так «приготовили».

Статья называется «опыт использования», а по факту вижу: включили -> с первого раза не заработало -> выключили. И в чём тут опыт? Был бы интересен хоть какой-то минимальный анализ, что же пошло не так.

[maximwirt]

По факту, некорректное поведение подтолкнуло к проведению исследований и поиску возможных утечек памяти. В общем-то можно сказать спасибо данной ситуации, кое-что в CRM было переделано, чтобы память расходовалась более экономно — 2 недели занимались только этим. Но ситуацию с проблемами при использовании ZGC это не решило. По поводу настроек ОС — у нас убунту и JDK изначально ставился через apt из официального репозитория, и ранее сложностей с утечками памяти не наблюдалось. В сухом остатке — подключение ZGC = outofmemory и последующее вмешательство oom killer-а, отключение = все ОК.

[Andrey0Lomakin]

maximwirt Мне кажеться Вы всё таки пропустили важный момент в комментарии. ZGC использует мультимаппинг. Там по моему 3 цвета замапленных на RSS если я не ошибаюсь. Т.е. Ваши 6Gb heap система видит как 18Gb heap и начинает использовать SWAP и в конце срабатывает OOM killer. Возможно Вм и правда надо отменить своппироание и убрать OOM killer. Хотя я и сам считаю что как раз мудтимаппинг и есть главная проблема ZGC, но она заложена в его архитектуре.

[vtarasoff]

Абсолютно согласен. Вообще никаких цифр… «у нас упало приложение на OOM, значит виноват G1, мы его отключили». и второе, где в статье сравнение с Shenandoah?

[vtarasoff]

Ой, простите, ZGC, конечно

[maximwirt]

Посмотрите пожалуйста — тут есть ссылка «попалась статья» — в ней есть графики, если уж на то пошло. Поймите меня правильно, но когда приложение начинает падать в продакшене, то последнее, что приходит на ум начать делать — сидеть и заниматься снятием метрик. Могу только дополнить, что при наличии 32Гб памяти на сервере и параметре запуска приложения Xmx6144 — ZGC уводил компьютер в своп. С ShenandoahGC или ParallelGC — даже 16Гб оказывается достаточно для стабильной работы на протяжении нескольких недель, при равной нагрузке.

[Vladimirsencov]

Разблокировать экспериментальную фичу на проде. А что так можно было?