Лимиты ресурсов контейнеров (CPU/RAM)

Один контейнер без лимитов способен сожрать всю память VPS и уронить соседей. Ставим границы по CPU и RAM, чтобы сервисы не мешали друг другу.

Зачем лимиты

По умолчанию контейнер видит все ресурсы хоста. Утечка памяти в одном сервисе — и ядро запускает OOM-killer, который может убить не виновника, а случайного соседа. Лимиты изолируют сбои: проблемный контейнер упрётся в свой потолок и не потянет за собой остальные.

На VPS это особенно важно: ресурсы конечны, и справедливое распределение между контейнерами — вопрос стабильности. Тарифы MAATRIX на AMD EPYC дают предсказуемую производительность на ядро, так что заданные вами лимиты CPU транслируются в реальную, а не «плавающую» мощность.

Лимит памяти

Ограничить контейнер по RAM — флаг --memory. Плюс полезно задать swap-лимит, чтобы контейнер не уполз в своп целиком:

docker run -d --name app \
  --memory 512m \
  --memory-swap 512m \
  myapp:1.0

Когда --memory и --memory-swap равны — своп для контейнера отключён, он работает строго в пределах RAM. Если приложение превысит лимит, оно получит OOM внутри своих границ, не задев хост.

Проверить фактическое потребление:

docker stats --no-stream app

Лимит CPU

Ограничение по процессору задаётся через --cpus — это доля ядер. Например, полтора ядра:

docker run -d --name app --cpus 1.5 myapp:1.0

Если нужно не жёсткое ограничение, а приоритет при конкуренции — используйте веса --cpu-shares (по умолчанию 1024):

docker run -d --name low-prio --cpu-shares 512 batch-job:1.0

Контейнер с 512 получит вдвое меньше процессорного времени, чем сосед с 1024 — но только когда CPU реально загружен под завязку. В простое ограничение не мешает.

Лимиты в docker-compose

В compose лимиты описываются декларативно. Для не-swarm запуска используйте секцию deploy.resources — современные версии Docker Compose её учитывают:

services:
  app:
    image: myapp:1.0
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512m
        reservations:
          memory: 256m

Обновить лимиты на лету

Менять ограничения можно без пересоздания контейнера — командой docker update:

docker update --memory 1g --cpus 2 app

Удобно при подборе оптимальных значений на проде: подняли нагрузку, посмотрели docker stats, скорректировали лимит. Учтите: уменьшить memory-лимит ниже текущего потребления не даст — сначала снизьте нагрузку.

Частые ошибки

• Совсем без лимитов на проде — один сбойный контейнер валит весь VPS. Ставьте потолки хотя бы по памяти.
• Лимит меньше реальных нужд — контейнер циклически перезапускается по OOM. Смотрите docker inspect на ExitCode 137.
• Забыли про memory-swap — контейнер уходит в своп, всё тормозит.
• Не оставляйте хост без запаса: часть RAM нужна системе. На MAATRIX с ежедневными бэкапами данные защищены, но грамотное распределение ресурсов — по-прежнему на вас.

Частые вопросы