Оптимизация Docker-контейнеров: устранение узких мест производительности

Когда Docker-контейнер работает медленно, контейнер редко является единственной причиной. Проблема обычно находится на один уровень ниже: троттлинг CPU, нехватка памяти, медленная запись на диск, задержки DNS, шумные соседи на хосте или приложение, которое было неэффективным ещё до контейнеризации.

Самый быстрый способ потратить время впустую — начать менять флаги Docker, не зная, какой ресурс ограничен. Начните с доказательств, изолируйте одно узкое место, измените одну вещь и измерьте снова.

Начните с триажа, а не с настройки

docker stats даёт быстрый обзор в реальном времени:

docker stats
docker stats --no-stream

Используйте его, чтобы ответить на основные вопросы:

Высокая ли загрузка CPU и держится ли она?
Близка ли память к установленному лимиту?
Растёт ли блочный ввод-вывод во время медленных запросов?
Неожиданно ли высокое количество процессов?
Соответствует ли сетевой ввод-вывод рабочей нагрузке?

Затем проверьте состояние контейнера и логи:

docker logs --tail 100 <имя_или_id_контейнера>
docker inspect <имя_или_id_контейнера> --format 'OOM={{.State.OOMKilled}} Exit={{.State.ExitCode}} Restarting={{.State.Restarting}}'

Также посмотрите на хост. Контейнер может выглядеть безобидно, пока хост использует своп или диск перегружен:

top
free -m
vmstat 1
iostat -xz 1

iostat может потребовать пакет sysstat. Если вы используете Docker Desktop, помните, что между вашей хост-ОС и Linux-контейнерами находится виртуальная машина, что меняет поведение файловой и сетевой подсистем.

Узкие места CPU

Высокая загрузка CPU может означать, что приложение занято, недообеспечено ресурсами или троттлится. Это разные проблемы.

Проверьте настройки CPU:

docker inspect <контейнер> --format '{{json .HostConfig.NanoCpus}} {{json .HostConfig.CpuQuota}} {{json .HostConfig.CpuPeriod}}'

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

docker run -d --name api --cpus="2" my-api:latest

Если CPU остаётся высоким после повышения лимита, профилируйте приложение. Например, Node-сервис может застревать на сериализации JSON, Python-воркер может быть ограничен GIL, а Java-сервис может тратить время на сборку мусора. Docker сам по себе это не исправит.

Нехватка памяти и OOM-завершения

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

Проверьте, было ли OOM-завершение:

docker inspect <контейнер> --format '{{.State.OOMKilled}}'

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

Лимиты памяти должны оставлять запас. Контейнер, использующий 950 МБ из 1 ГБ при нормальном трафике, нездоров. Сборка мусора, временные буферы, TLS, сжатие и всплески запросов требуют места.

Решение проблем производительности ввода-вывода (I/O)

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

docker inspect <контейнер> --format '{{json .Mounts}}'
docker info --format 'StorageDriver={{.Driver}}'

На современных Linux-установках Docker overlay2 является распространённым драйвером хранения по умолчанию. Обычно это хороший выбор, но запись тяжёлых изменяемых данных в слой контейнера всё равно плохая практика.

Используйте именованные тома для постоянных данных приложения:

docker volume create app-data
docker run -d --name app -v app-data:/var/lib/app my-image

Используйте bind-монтирования, когда нужен конкретный путь на хосте, но тестируйте их. Bind-монтирования Docker Desktop на macOS и Windows могут быть намного медленнее, чем доступ к файловой системе нативном Linux, поскольку операции с файлами пересекают границу виртуализации.

Для временных высокоскоростных файлов может помочь /dev/shm, но он основан на памяти и ограничен:

docker run --shm-size=512m my-image

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

Оптимизация размера образа и производительности сборки

Размер образа в основном влияет на время сборки, загрузки, сканирования и развёртывания. Обычно он не ускоряет обработку запросов после запуска контейнера, но всё же важен с операционной точки зрения.

Используйте многоэтапные сборки, чтобы компиляторы, кэши пакетов и инструменты тестирования не попали в образ времени выполнения:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o app

FROM alpine:3.20
COPY --from=builder /app/app /app
CMD ["/app"]

Упорядочивайте инструкции Dockerfile для повторного использования кэша:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Изменение исходного кода не должно вызывать повторную загрузку зависимостей, если только файлы зависимостей не изменились.

Вопросы производительности сети

Замедления сети часто выглядят как замедления приложения. Проверьте изнутри контейнера:

docker exec -it <контейнер> sh
time getent hosts api.example.com
time wget -qO- https://api.example.com/health

Если разрешение DNS медленное или нестабильное, проверьте /etc/resolv.conf в контейнере и сравните с хостом. Вы можете указать DNS-серверы при запуске:

docker run -d --name web --dns 1.1.1.1 my-image

Делайте это как диагностический или политический выбор, а не как случайное исправление. В корпоративных сетях может потребоваться внутренний DNS.

Сеть Docker по умолчанию (bridge) добавляет обработку NAT и iptables. Для большинства веб-приложений накладные расходы приемлемы. Сеть хоста может снизить накладные расходы на Linux:

docker run --network host my-image

Это также убирает изоляцию сетевого пространства имён и меняет обработку портов. Используйте её, когда измерили реальную необходимость.

Полевой чек-лист

Когда контейнер работает медленно, пройдитесь по этому списку:

Воспроизведите замедление с помощью конкретного запроса, задачи или рабочей нагрузки.
Захватите вывод docker stats --no-stream, логи и вывод inspect контейнера.
Проверьте CPU, память, своп, дисковый ввод-вывод и сеть на хосте.
Определите ограниченный ресурс перед изменением лимитов.
Перенесите постоянные или тяжёлые записи в тома.
Сравните поведение bind-монтирований на Linux и Docker Desktop, если локальная разработка — единственное медленное место.
Профилируйте приложение, когда метрики контейнера не объясняют замедление.
Измените одну настройку и измерьте снова.

Полезный образ мыслей прост: Docker даёт изоляцию и упаковку, но не отменяет обычную работу с системами. CPU, память, диск и сеть по-прежнему определяют, насколько быстрым кажется сервис.