Оптимизация производительности контейнеров Docker с помощью ограничений CPU и памяти

Контейнеры Docker не ведут себя автоматически как маленькие виртуальные машины с фиксированными ресурсами. Если не указать иное, контейнер может конкурировать за ресурсы CPU и памяти хоста, как и любой другой процесс. Это удобно на ноутбуке, но рискованно на общем сервере.

Ограничения CPU и памяти — это не волшебные ускорители производительности. Слишком низкий лимит замедляет приложение или делает его нестабильным. Слишком высокий лимит не защищает хост. Цель — дать каждому контейнеру достаточно места для нормальной и пиковой работы, предотвращая при этом, чтобы один проблемный процесс не нарушил работу всего остального на машине.

Почему важны ограничения

Типичный сценарий отказа знаком: один контейнер запускает неуправляемый процесс, память растет, хост начинает использовать swap, и несвязанные сервисы замедляются. Или пакетная задача, интенсивно использующая CPU, загружает все ядра, и соседний контейнер с API начинает пропускать целевые показатели задержки.

Ограничения помогают решить три практические проблемы:

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

Не начинайте со случайных чисел. Запустите сервис под нагрузкой, наблюдайте за фактическим использованием и устанавливайте лимиты с запасом. Небольшой фоновый воркер и JVM-сервис требуют совершенно разного подхода.

Управление CPU

Docker предоставляет несколько средств управления CPU. Наиболее полезное в повседневной работе — --cpus.

Ограничьте контейнер примерно полутора ядрами CPU:

docker run -d --name api --cpus="1.5" nginx

Это проще для чтения, чем ручная установка квоты и периода CFS. Под капотом Docker использует механизмы планирования CPU Linux.

--cpu-shares отличается. Это относительный вес при конкуренции за CPU, а не жесткое ограничение:

docker run -d --name important-api --cpu-shares 2048 nginx
docker run -d --name batch-worker --cpu-shares 512 worker-image

Когда на хосте есть свободный CPU, оба контейнера могут использовать больше. Когда они конкурируют, первый контейнер имеет больший вес при планировании. Это полезно для приоритизации, но не мешает контейнеру использовать свободный CPU.

Если вам нужны точные настройки CFS, --cpu-period и --cpu-quota все еще доступны:

docker run -d --name limited-api \
  --cpu-period 100000 \
  --cpu-quota 50000 \
  nginx

Это дает контейнеру 50 000 микросекунд времени CPU в каждом периоде 100 000 микросекунд, примерно половину одного ядра. Для большинства команд --cpus="0.5" передает ту же идею более понятно.

Управление памятью

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

Основной параметр — --memory:

docker run -d --name web --memory 512m nginx

Если контейнер превышает лимит, ядро может убить процесс внутри контейнера. В выводе Docker вы часто увидите это как OOM kill:

docker inspect web --format '{{.State.OOMKilled}}'

Поведение swap легко понять неправильно. Когда установлен --memory, --memory-swap — это общий лимит памяти плюс swap, а не только swap.

Это разрешает 256 МБ ОЗУ и до 256 МБ swap, всего 512 МБ:

docker run -d --name worker --memory 256m --memory-swap 512m alpine

Установка --memory-swap равным --memory отключает дополнительный swap для этого контейнера в системах, где доступен учет swap:

docker run -d --name no-extra-swap --memory 256m --memory-swap 256m alpine

Установка --memory-swap -1 разрешает неограниченный swap в пределах доступного swap хоста. Это может сохранить процесс живым, но может сделать задержки ужасными.

Мониторинг до и после

Используйте docker stats, пока сервис находится под реалистичной нагрузкой:

docker stats
docker stats web worker

Следите за CPU %, MEM USAGE / LIMIT, BLOCK I/O и PIDS. Сервис, работающий на 100% своего лимита памяти, не является "эффективным"; он находится в одном скачке трафика от завершения. Сервис, интенсивно использующий CPU и постоянно ограничиваемый, может показывать приемлемое среднее использование CPU, в то время как пользователи видят медленные запросы.

Для быстрого однократного просмотра:

docker stats --no-stream

Для подсказок об OOM и перезапусках:

docker ps -a
docker inspect <container> --format 'OOM={{.State.OOMKilled}} Exit={{.State.ExitCode}}'
docker logs --tail 100 <container>

Для постоянного мониторинга экспортируйте метрики контейнера в Prometheus, Grafana, облачный сервис мониторинга или платформу, которую вы уже используете. docker stats — это триаж, а не долгосрочная система оповещения.

Разумный рабочий процесс настройки

Начните без жестких ограничений в тестовой среде и зафиксируйте использование в режиме простоя, нормальной и пиковой нагрузки. Затем установите память выше наблюдаемого пика с достаточным запасом для сборки мусора, роста кэша, рукопожатий TLS и коротких всплесков. Для CPU решите, нужен ли вам жесткий лимит или только относительный приоритет.

Пример для небольшого API:

docker run -d --name api \
  --cpus="2" \
  --memory 1g \
  --memory-swap 1g \
  -p 8080:80 \
  my-api:latest

Это означает, что API получает до двух ядер CPU, 1 ГБ ОЗУ и без дополнительного swap. Это не универсально правильно. Это четкая отправная точка для сервиса, который был протестирован в этом диапазоне.

Для Docker Compose локальный движок Docker поддерживает параметры ресурсов, такие как:

services:
  api:
    image: my-api:latest
    mem_limit: 1g
    cpus: 2.0

Настройки ресурсов в Compose и Swarm/Kubernetes не идентичны, поэтому проверьте цель развертывания, прежде чем предполагать, что поле ведет себя одинаково везде.

Распространенные ошибки

Самая распространенная ошибка — установка слишком низкого лимита памяти. Приложение запускается, проходит дымовой тест, а затем умирает при паттерне запросов, который выделяет больше памяти, чем было протестировано.

Использование ограничений CPU для сокрытия неэффективного кода — еще одна ошибка. Если сервис медленный из-за дорогих операций на запрос, более низкий лимит CPU делает симптомы более очевидными. Это не исправляет код.

Игнорирование языковых сред выполнения также вредит. JVM, Node.js, Go, Python и Ruby приложения по-разному реагируют на давление памяти. Некоторые среды выполнения требуют явных настроек кучи, чтобы их внутренние предположения о памяти соответствовали лимиту контейнера.

Наконец, не настраивайте только один контейнер. Хосту все еще нужны CPU и память для ядра, Docker, логирования, агентов мониторинга и любых sidecar-процессов. Оставьте место.

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