Как любой адекватный поставщик информационных услуг, мы понимаем, что время отклика системы является очень важным фактором для создания у пользователей положительных впечатлений. Помимо этого, высокая скорость работы позволяет более плотно использовать серверные мощности, а, следовательно, сократить расходы на дата центр.
Но, есть одно «но»: наша 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, и не пожалели.
