Как рассчитать лимит оперативной памяти для докер-контейнера (RAM limit), чтобы он не вызывал OOM-killer на хост-машине?
Правильный расчёт лимита оперативной памяти для Docker-контейнера — критически важная задача для обеспечения стабильности как самого контейнера, так и хост-системы. OOM-killer (Out-Of-Memory Killer) — это механизм ядра Linux, который принудительно завершает процессы при нехватке памяти. Если контейнер не имеет ограничений или они заданы неверно, OOM-killer может убить как процессы внутри контейнера, так и процессы на хосте.
**Шаг 1. Определите реальное потребление памяти приложения**
Запустите контейнер без лимитов и наблюдайте за потреблением памяти под реальной нагрузкой:
docker stats
Обратите внимание на поле `MEM USAGE`. Запускайте нагрузочные тесты и фиксируйте пиковые значения потребления (peak RSS + cache).
**Шаг 2. Учитывайте все компоненты памяти**
Потребление памяти контейнером складывается из:
— RSS (Resident Set Size) — реально используемая физическая память процессом;
— Page cache — кэш файловой системы;
— Shared memory — разделяемая память между процессами;
— Stack и heap — память приложения.
Для Java-приложений учитывайте heap + metaspace + thread stacks + off-heap буферы — суммарно это может быть в 1,5–2 раза больше значения `-Xmx`.
**Шаг 3. Применяйте коэффициент запаса**
Рекомендуемая формула:
RAM limit = Peak Memory Usage × 1.2 … 1.5
Коэффициент 1.2–1.5 даёт буфер для кратковременных пиков без риска OOM.
**Шаг 4. Оставьте резерв для хост-системы**
Никогда не выделяйте всю доступную память хоста под контейнеры. Рекомендуется:
— Оставить минимум 10–20% RAM хоста свободными для нужд ОС, демонов и буферов ядра;
— Суммарный лимит всех контейнеров не должен превышать 80% физической RAM хоста.
**Шаг 5. Настройте параметры Docker**
При запуске контейнера задайте лимиты:
bash
docker run —memory=512m —memory-swap=512m myapp
Установка `—memory-swap` равным `—memory` отключает использование swap, что предотвращает деградацию производительности. Если swap нужен — задайте его явно, например `—memory-swap=1g`.
**Шаг 6. Настройте поведение OOM внутри контейнера**
Флаг `—oom-kill-disable` отключает OOM-killer для контейнера, но использовать его нужно осторожно — при нехватке памяти ядро будет искать жертву среди других процессов хоста. Лучше задайте приоритет:
bash
docker run —oom-score-adj=-500 myapp
Значение от -1000 до 1000: чем ниже, тем меньше вероятность, что процесс будет убит.
**Шаг 7. Мониторинг и итерация**
Используйте Prometheus + cAdvisor или встроенные метрики Docker для постоянного мониторинга. Настройте алерты при достижении 80% от установленного лимита — это сигнал к пересмотру ограничений.
**Итоговые рекомендации:**
— Измеряйте реальное потребление под нагрузкой, не полагайтесь на теоретические оценки;
— Добавляйте 20–50% запаса к пиковым значениям;
— Резервируйте 15–20% RAM хоста для системных нужд;
— Всегда задавайте `—memory-swap` явно;
— Регулярно пересматривайте лимиты при изменении нагрузки.