Docker --pids-limit: ограничить процессы контейнера

Что важно понять до начала

Флаг относится к PID cgroup и ограничивает количество создаваемых задач. Значение должно учитывать worker-процессы, shell, вспомогательные процессы и потоки приложения. Реальный безопасный предел лучше получать из наблюдений под пиковой нагрузкой. При срабатывании лимита приложение может выдавать ошибки создания процессов, хотя контейнер продолжает работать.

Совет: Практический ориентир: Универсального числа нет. Возьмите измеренный пик конкретного сервиса и добавьте запас, затем подтвердите нагрузочным тестом.

Пошаговый порядок действий

1. 1. Снимите базовый профиль: посчитайте процессы/потоки при обычной и пиковой нагрузке.
2. 2. Добавьте запас к наблюдаемому максимуму, например 30–100% в зависимости от характера приложения.
3. 3. Запустите контейнер с `--pids-limit=<значение>`.
4. 4. Проведите нагрузочный тест и одновременно контролируйте ошибки fork/thread creation.
5. 5. Если лимит достигается штатно, увеличьте его; если рост аномальный, сначала найдите причину размножения процессов.

Важно: Критично для этой задачи: Не ставьте лимит «на глаз» близко к текущему числу процессов: при обновлении библиотеки или изменении concurrency приложение может начать падать только на пике.

Ошибки и пограничные случаи

Не ставьте лимит «на глаз» близко к текущему числу процессов: при обновлении библиотеки или изменении concurrency приложение может начать падать только на пике. Для JVM, Node worker threads, браузеров и систем с большим числом потоков считайте не только привычные процессы из краткого `ps`, а фактические задачи cgroup.

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

Проверка перед завершением

• Снимите базовый профиль: посчитайте процессы/потоки при обычной и пиковой нагрузке.
• Запустите контейнер с `--pids-limit=<значение>`.
• Если лимит достигается штатно, увеличьте его; если рост аномальный, сначала найдите причину размножения процессов.
• Проверено отдельно: Универсального числа нет. Возьмите измеренный пик конкретного сервиса и добавьте запас, затем подтвердите нагрузочным тестом.

Практический сценарий и контроль результата

Лимит имеет смысл проверять в том же профиле нагрузки, где сервис работает в продакшене. Снимите число задач в спокойном режиме и на пике, затем оставьте запас для кратковременных всплесков, обновлений библиотек и фоновых worker‑процессов. Если после включения --pids-limit появляются ошибки создания потоков при свободной памяти и CPU, это сильный признак слишком тесного PID‑лимита. Если число задач растёт без причины, увеличение лимита лишь отложит отказ — сначала ищите источник роста.

Дополнительные нюансы и проверка

Не переносите значение лимита между сервисами. Веб‑сервер с фиксированным числом workers и браузерный workload создают разное количество задач. Перед выпуском изменения повторите пик нагрузки и посмотрите, не упирается ли приложение в лимит только при редком всплеске. Если лимит регулярно достигается, зафиксируйте момент и причину роста: нормальный burst требует запаса, а бесконтрольное размножение процессов требует исправления приложения, а не бесконечного повышения pids-limit.

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

Флаг относится к PID cgroup и ограничивает количество создаваемых задач. Значение должно учитывать worker-процессы, shell, вспомогательные процессы и потоки приложения. Реальный безопасный предел лучше получать из наблюдений под пиковой нагрузкой. При срабатывании лимита приложение может выдавать ошибки создания процессов, хотя контейнер продолжает работать.

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

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

• docker container run
• Running containers