Лимиты ресурсов контейнеров (CPU/RAM)
Один контейнер без лимитов способен сожрать всю память VPS и уронить соседей. Ставим границы по CPU и RAM, чтобы сервисы не мешали друг другу.
Содержание
Зачем лимиты
['По умолчанию контейнер видит все ресурсы хоста. Утечка памяти в одном сервисе — и ядро запускает OOM-killer, который может убить не виновника, а случайного соседа. Лимиты изолируют сбои: проблемный контейнер упрётся в свой потолок и не потянет за собой остальные.', 'На VPS это особенно важно: ресурсы конечны, и справедливое распределение между контейнерами — вопрос стабильности. Тарифы MAATRIX на AMD EPYC дают предсказуемую производительность на ядро, так что заданные вами лимиты CPU транслируются в реальную, а не «плавающую» мощность.']Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.
Арендовать VPS для DockerЛимит памяти
['Ограничить контейнер по RAM — флаг--memory. Плюс полезно задать swap-лимит, чтобы контейнер не уполз в своп целиком:', 'docker run -d --name app \\\n --memory 512m \\\n --memory-swap 512m \\\n 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:\n app:\n image: myapp:1.0\n deploy:\n resources:\n limits:\n cpus: "1.0"\n memory: 512m\n reservations:\n memory: 256m', 'limits — жёсткий потолок, reservations — гарантированный минимум. Так вы описываете весь стек в одном файле и держите ресурсные границы под контролем версий.']
Обновить лимиты на лету
['Менять ограничения можно без пересоздания контейнера — командойdocker update:', 'docker update --memory 1g --cpus 2 app', 'Удобно при подборе оптимальных значений на проде: подняли нагрузку, посмотрели docker stats, скорректировали лимит. Учтите: уменьшить memory-лимит ниже текущего потребления не даст — сначала снизьте нагрузку.']
Частые ошибки
['- Совсем без лимитов на проде — один сбойный контейнер валит весь VPS. Ставьте потолки хотя бы по памяти.
- Лимит меньше реальных нужд — контейнер циклически перезапускается по OOM. Смотрите
docker inspectна ExitCode 137. - Забыли про memory-swap — контейнер уходит в своп, всё тормозит.
- Не оставляйте хост без запаса: часть RAM нужна системе. На MAATRIX с ежедневными бэкапами данные защищены, но грамотное распределение ресурсов — по-прежнему на вас.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.
Арендовать VPS для DockerЧастые вопросы
Что значит код выхода 137 у контейнера?
Это сигнал SIGKILL, чаще всего — срабатывание OOM-killer из-за превышения лимита памяти. Увеличьте --memory или найдите утечку в приложении.
Работают ли лимиты deploy.resources без Swarm?
В актуальных версиях Docker Compose (v2) limits из секции deploy.resources применяются и при обычном docker compose up. Reservations по памяти тоже учитываются.
Можно ли менять лимиты без перезапуска?
Да, командой docker update можно на лету поменять --memory и --cpus. Уменьшить память ниже текущего потребления не получится — сначала снизьте нагрузку.