Как стать автором
Обновить

Комментарии 6

Лучший GC для кубернетес-приложений?

Выбор сборщика в большей степени зависит от специфики самого приложения (от требований к нему и от того, как оно работает с памятью), нежели от того, в какой инфраструктуре вы его запускаете. Нужно только учитывать ограничения на доступные JVM ресурсы, которые накладывает инфраструктура, а в остальном смотрите на само приложение, однозначного ответа здесь нет.

Нужно только помнить про особенности работы ZGC, который из-за использования цветных указателей (см. предыдущую статью) может репортить трехкратное значение используемой памяти, что может ставить в тупик какие-нибудь системы контейнеризации или системы их мониторинга. Да и просто людей может смущать.

Ну, просто если оркестратор имеет свой контроль за памятью, то зачем дублировать эту логику на уровне, фактически, приложения (пода)?

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

Да, разумеется. Но не делает ли оркестратор всю систему менеджмента памяти на уровне приложения некоторым образом устаревшей? Ну, вторичной по крайней мере.

Логика примерно такая. Если приложение/сервис может жить под оркестратором, значит наши бизнес-требования могут мириться с периодическими рестартами отдельных подов. За счет ли резервирования с балансировкой, или еще почему. А раз так, то зачем нам заниматься настройкой управления памяти дважды? Выставить в Epslion GC значение побольше, и забыть про него, положившись на оркестрацию.

Разменяв, таким образом, потери производительности от GC на потери от перезапуска пода.

Технически, конечно, это будет работать. Но обычно даже когда разрабатывают сервисы, которые могут мириться с периодическими рестартами отдельных подов, не рассчитвают на то, что рестарты будут настолько частыми. Если вы изначально не разрабатываете приложение с таким расчетом, чтобы оно очень мало мусорило (а это очень сложно), то падать по OOM с Epsilon'ом оно будет очень часто.

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории