Как любой адекватный поставщик информационных услуг, мы понимаем, что время отклика системы является очень важным фактором для создания у пользователей положительных впечатлений. Помимо этого, высокая скорость работы позволяет более плотно использовать серверные мощности, а, следовательно, сократить расходы на дата центр.
Но, есть одно «но»: наша CRM — SalesMax — написана на java, а, следовательно, периодически возникают паузы, связанных с работой сборщика мусора. До последнего времени, это было тем неизбежным злом, с которым нужно было просто смириться.
И вот, Oracle анонсировали новый сборщик мусора — ZGC. По предварительным анонсам, он должен был решить проблему подвисаний java приложений — заявленные паузы не должны превышать 100 мс даже на многогигабайтных кучах. С нашими 6Гб максимального использования памяти, все, и подавно, должно быть хорошо.
Итак, приступим.
Добавляем в standalone.conf сервера приложений wildfly строчку
Запускаем систему, прогоняем нагрузочные тесты.
На первый взгляд, все работает как заявлено, паузы на сборку мусора действительно сократились.
Не долго думая, было принято решение попробовать новый сборщик мусора на одном из продуктовых серверов. Выбрали наименее загруженный, настроили, запустили, стали наблюдать.
Первое время все работало хорошо, в общем-то решили, что эксперимент оказался успешным.
И вот, вечер субботы. Мы спокойно играем в бильярд, время за полночь. Звонок от менеджера: у клиента CRM не работает.
Проверяем — клиент с того самого сервера. Телефон в руки, открываю Termius, пытаюсь подключиться к серверу по ssh — тишина… Еле-еле, спустя секунд 20, которые в тот момент показались вечностью, но зайти все же удалось. И что же мы видим? Несмотря на установленные в параметрах запуска ограничения -Xmx6144M, процесс java израсходовал всю доступную память. Спустя какое-то время, система и вовсе данный процесс убила.
Так что, использование ZGC пришлось отключить. Работа CRM системы сразу пришла в норму. Казалось бы — делать нечего, будем ждать, пока в Oracle все допилят.
Но, спустя некоторое время, на глаза попалась статья в которой автор делился положительным опытом использования другого сборщика мусора — Shenandoah, разработчик которого преследовал ровно те же самые цели, а именно: сокращение времени, которое в сборщике мусора занимает фаза «stop the world».
Мы решили: почему бы и нет?
Найдя страницу, с которой можно скачать предварительно скомпилированный JDK — https://builds.shipilev.net/, мы приступили к тестированию: добавляем в standalone.conf новые ключи:
На этот раз, тестирование показало, что все, в общем-то, ОК. И паузы на сборку мусора сократились, и, что самое приятное — непредсказуемый рост расхода памяти прекратился. В продакшене все работает просто идеально.
Какие можно сделать выводы? Я понимаю, что в Oracle тоже идет развитие, и те сложности, с которыми мы столкнулись в октябре 2019 года, возможно, уже исправлены, и ZGC вскоре можно будет дать второй шанс. Но на данный момент, лично мы остановили свой выбор на Shenandoah GC, и не пожалели.
Но, есть одно «но»: наша CRM — SalesMax — написана на java, а, следовательно, периодически возникают паузы, связанных с работой сборщика мусора. До последнего времени, это было тем неизбежным злом, с которым нужно было просто смириться.
И вот, Oracle анонсировали новый сборщик мусора — ZGC. По предварительным анонсам, он должен был решить проблему подвисаний java приложений — заявленные паузы не должны превышать 100 мс даже на многогигабайтных кучах. С нашими 6Гб максимального использования памяти, все, и подавно, должно быть хорошо.
Итак, приступим.
Добавляем в standalone.conf сервера приложений wildfly строчку
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
Запускаем систему, прогоняем нагрузочные тесты.
На первый взгляд, все работает как заявлено, паузы на сборку мусора действительно сократились.
Не долго думая, было принято решение попробовать новый сборщик мусора на одном из продуктовых серверов. Выбрали наименее загруженный, настроили, запустили, стали наблюдать.
Первое время все работало хорошо, в общем-то решили, что эксперимент оказался успешным.
И вот, вечер субботы. Мы спокойно играем в бильярд, время за полночь. Звонок от менеджера: у клиента CRM не работает.
Проверяем — клиент с того самого сервера. Телефон в руки, открываю Termius, пытаюсь подключиться к серверу по ssh — тишина… Еле-еле, спустя секунд 20, которые в тот момент показались вечностью, но зайти все же удалось. И что же мы видим? Несмотря на установленные в параметрах запуска ограничения -Xmx6144M, процесс java израсходовал всю доступную память. Спустя какое-то время, система и вовсе данный процесс убила.
Так что, использование ZGC пришлось отключить. Работа CRM системы сразу пришла в норму. Казалось бы — делать нечего, будем ждать, пока в Oracle все допилят.
Но, спустя некоторое время, на глаза попалась статья в которой автор делился положительным опытом использования другого сборщика мусора — Shenandoah, разработчик которого преследовал ровно те же самые цели, а именно: сокращение времени, которое в сборщике мусора занимает фаза «stop the world».
Мы решили: почему бы и нет?
Найдя страницу, с которой можно скачать предварительно скомпилированный JDK — https://builds.shipilev.net/, мы приступили к тестированию: добавляем в standalone.conf новые ключи:
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
На этот раз, тестирование показало, что все, в общем-то, ОК. И паузы на сборку мусора сократились, и, что самое приятное — непредсказуемый рост расхода памяти прекратился. В продакшене все работает просто идеально.
Какие можно сделать выводы? Я понимаю, что в Oracle тоже идет развитие, и те сложности, с которыми мы столкнулись в октябре 2019 года, возможно, уже исправлены, и ZGC вскоре можно будет дать второй шанс. Но на данный момент, лично мы остановили свой выбор на Shenandoah GC, и не пожалели.
