Spring Boot в k8s: Xmx=лимиту пода, а под всё равно OOMKilled

[Austkin]

Spring Boot сервис в k8s, лимит пода 1Gi, поставила -Xmx1g — и под регулярно OOMKilled. Хип же 1 гиг, лимит 1 гиг, чего ему не хватает-то?

[nerd_max]

Потому что у JVM кроме хипа есть metaspace, thread stacks, code cache, direct buffers, GC-структуры. Xmx=limit не оставляет места под non-heap, и kubelet прибивает под за превышение лимита.

[cudauser]

А сколько закладывать на этот non-heap?

[sleepypanic]

Эмпирически 25-30% сверху от хипа. На лимит 1Gi ставь -Xmx640m..700m, остальное отдай джавовскому оверхеду. Точнее — мерить Native Memory Tracking под своей нагрузкой.

[svelte88]

Лучше вообще не хардкодить Xmx, а -XX:MaxRAMPercentage=75.0 при UseContainerSupport (включён по дефолту с Java 10). JVM сам возьмёт 75% от лимита пода, и при смене лимита не надо лезть править флаги.

[torchlover]

Поставила MaxRAMPercentage=70, гоняю сутки под нагрузкой — ни одного OOMKilled. Спасибо! В половине доков почему-то всё через жёсткий Xmx показывают.

[asyncmonk]

Только не забудьте: container support бэкпортнут в Java 8 лишь с 8u191. На старых 8u131 JVM видит память всей НОДЫ, а не лимит пода, и спокойно сожрёт всё что есть.

[timur12]

JVM — это не только heap. -Xmx1g ограничивает только старый+молодой gen, но у JVM ещё куча всего живёт вне хипа: Metaspace (стандартно до 256–512 МБ под Spring Boot с кучей аннотаций), thread stacks (~1 МБ на поток, при 200 потоках это уже 200 МБ), direct ByteBuffers (Netty, NIO), JIT-компилированный код. Итого реальное потребление процесса может быть +600–800 МБ поверх -Xmx. Формула для лимита пода: Xmx + ~300-400MB overhead. Ставь лимит минимум 1.5–1.7 ГБ при Xmx1g, либо переходи на -XX:MaxRAMPercentage=75 и пусть JVM сама считает под контейнерный лимит.

[svelte88]

Ещё момент про Metaspace: если у тебя много классов (Spring, Hibernate генерят прокси), то при дефолтном -XX:MaxMetaspaceSize unlimited Metaspace тихо растёт и в итоге OOM от ядра прилетает не в heap, а в native. Ставь явно -XX:MaxMetaspaceSize=256m или 512m. Тогда хотя бы OOMError будет выброшен самой JVM с нормальным stack trace, а не молчаливый SIGKILL от k8s.

[duel]

Для диагностики в k8s удобно смотреть не на jvm heap, а на RSS процесса: kubectl exec <pod> -- cat /proc/1/status | grep VmRSS. Если RSS кратно больше Xmx — это подтверждение нативного оверхеда. Ещё полезно включить -Xlog:gc*:stdout и смотреть, не ли GC-паузы прямо перед OOMKill — иногда под OOMKill попадает не по памяти а по liveness probe таймауту во время Full GC.