Комментарии 22
Вот ответ на вопрос: почему java процессу нужно +1 GB памяти? (на самом деле может быть больше)
Андрей Паньгин — Память Java процесса по полочкам
Для некоторых классов приложений Xmx вообще слабо связан с реальным потреблением памяти, так как данные выносятся в off-heap. Странно что за 3 года эксплуатации явы в кубере они это не осознали )
На самом деле проблема выглядит если не надуманной, то уж явно преувеличенной. Гоняем яву в кубере (опеншифт) на проде уже несколько лет, полёт нормальный. А вот liveness/readyness пробы при старте stateful контейнеров это боль, да.
Вообще stateful штукам (БД, Кафка и т.п.) не место в кубере, особенно на распределённой ФС. Проблем много, выгода неочевидна.
Для некоторых классов приложений
Можете привести примеры таких (классов) приложений?
данные выносятся в off-heap
И где по вашему мнению эти данные хранятся и как определить сколько они заняли выделенных им ресурсов?
Вообще stateful штукам (БД, Кафка и т.п.) не место в кубере
А где им место?
Приложения где нужен быстрый доступ к памяти через Unsafe без лишней сборки мусора.
Почти все кэши, например Apache Ignite. В любом приложении, где надо хранить много данных в памяти, стоит посмотреть на такую возможность.
> И где по вашему мнению эти данные хранятся и как определить сколько они заняли выделенных им ресурсов?
Вне зависимости от «моего мнения» :-) они хранятся в оперативной памяти вне java хипа, т.е. настройка Xmx на их хранение не действует (и GC туда не ходит). Максимальный размер, который можно съесть в off heap, хранится в настройках приложения (каких именно — зависит от конкретного приложения).
> А где им место?
На отдельных серверах с «честной» файловой системой, вне кубера. Всё равно вы не сможете отмасштабировать тот же самый PostgreSQL просто увеличив кол-во подов.
Я понимаю, что Вы и так знаете то, что я опишу ниже, но здесь — самое место для моего комментария.
+1 Гб — это магическое число, взятое с потолка.
Мы вместо Xms/Xmx используем -XX:MaxRAM=2g
, тогда JVM не вылазит за границы, очерченные лимитами контейнера. В этом случае куча (heap) приложения займет примерно 1.2g (кажется, на хип отводится 60% от MaxRAM).
Получается примерно то же самое, что определить Xmx=1g, а в лимите прописать 2g (+1Gb как рекоммендует автор), но уже без магии.
Распределение памяти в этом случае задается через параметры: InitialRAMPercentage, MinRAMPercentage, MaxRAMPercentage
В любом случае это не панацея, а лишь другой способ определения размера heap внутри контейнера. В отдельных случаях выход за пределы выделенной памяти все еще возможен.
с помощью Kubespray. Он отлично себя зарекомендовал
очень несогласен, более глючную и тормознутую (ansible) тулзу для раскатки k8s еще поискать надо…
Обычно после такого комментария человек пишет хорошую альтернативу, а не просто набрасывает и уходит в тень)
Их десятки и наверно ближе к сотни… перечислять не вижу смыла, выбирайте по своим требованиям.
Например k3s..
3 года с Kubernetes в production: вот что мы поняли