Docker memory reservation и memory limit: в чём разница

Как выбрать без лишнего форматирования

1. Замерьте обычное и пиковое потребление контейнера во время реальной нагрузки.
2. Задайте hard --memory выше нормального пика с обоснованным запасом.
3. Если нужен мягкий ориентир при давлении на RAM, добавьте --memory-reservation ниже hard limit.
4. Запустите стрессовый сценарий и наблюдайте docker stats, latency и ошибки приложения.
5. После теста скорректируйте лимиты и зафиксируйте их в Compose или инфраструктурном коде.

Совет: Замерьте обычное и пиковое потребление контейнера во время реальной нагрузки.

--memory-reservation docker: ключевой принцип

Жёсткий --memory ограничивает объём памяти, доступный контейнеру, и при превышении может привести к OOM. --memory-reservation — мягкое ограничение, которое учитывается при конкуренции за память на хосте. Docker прямо указывает, что при совместном использовании reservation должна быть ниже значения --memory.

Совет: Жёсткий --memory ограничивает объём памяти, доступный контейнеру, и при превышении может привести к OOM.

--memory limit docker: ограничения и ошибки

Мягкая reservation не является гарантированно зарезервированным объёмом RAM и не означает, что контейнер всегда получит указанное количество. Слишком тесный hard limit вызывает аварии приложений при кратких пиках, даже если среднее потребление заметно ниже. Настройку нужно проверять под реальной нагрузкой через docker stats и логи OOM, а не выбирать проценты наугад. В связанных материалах и настройках встречаются также термины: Docker OOM memory, container memory constraints.

Предупреждение: Настройку нужно проверять под реальной нагрузкой через docker stats и логи OOM, а не выбирать проценты наугад.

Сравнение по ключевым критериям

Критерий | Практический ориентир Главное различие | Жёсткий --memory ограничивает объём памяти, доступный контейнеру, и при превышении может привести к OOM. Совместимость | Docker прямо указывает, что при совместном использовании reservation должна быть ниже значения --memory. Риск ошибки | Слишком тесный hard limit вызывает аварии приложений при кратких пиках, даже если среднее потребление заметно ниже.

Контроль перед завершением

• --memory-reservation ниже --memory.
• Hard limit выбран по нагрузочному тесту.
• Swap-настройки учтены отдельно.

Практический нюанс

Soft limit начинает играть роль при memory contention; при свободной памяти контейнер может находиться выше reservation. Поэтому график usage около 300 МБ при reservation 200 МБ сам по себе не доказывает ошибку конфигурации.

Что проверить в реальном сценарии

Проверяйте reservation под давлением памяти, а hard limit — на пиковом workload. Контейнер может временно потреблять больше reservation при свободной RAM, но не должен переходить установленный `--memory`; это две разные контрольные точки.

Как убедиться, что задача решена

Проверяйте лимиты под нагрузкой, а не по одной строке конфигурации. Контейнер с --memory 500m и --memory-reservation 200m может использовать больше 200 МБ при свободной памяти, но не должен выходить за жёсткие 500 МБ. Reservation — не гарантия постоянного потребления. Если нужна предсказуемая верхняя граница, ориентируйтесь на --memory и отдельно учитывайте swap-настройки хоста.

Важно: Значения сохранены в конфигурации

Что учитывать

Мягкая reservation не является гарантированно зарезервированным объёмом RAM и не означает, что контейнер всегда получит указанное количество. Слишком тесный hard limit вызывает аварии приложений при кратких пиках, даже если среднее потребление заметно ниже. Настройку нужно проверять под реальной нагрузкой через docker stats и логи OOM, а не выбирать проценты наугад. В связанных материалах и настройках встречаются также термины: Docker OOM memory, container memory constraints.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Resource constraints). Пример и формулировки — редакция N1RO на 2026-09-23.

• Resource constraints