Сообщить об ошибкеКороткий ответ
Нет единственно верной схемы лимитов: нужно сочетать --cpus/--memory с мониторингом фактического throttling и OOM-событий, а переход на cgroups v2 (единая иерархия контроллеров, cpu.max вместо раздельных quota/period, встроенная поддержка PSI-метрик) меняет точность и гранулярность контроля по сравнению с cgroups v1.
Как это работает подробнее
cgroups v1 исторически имел раздельные, не всегда согласованные между собой иерархии для разных контроллеров (cpu, memory, blkio), что иногда приводило к неожиданным взаимодействиям при сложных схемах лимитирования; cgroups v2 унифицирует иерархию и добавляет PSI (Pressure Stall Information) — метрики, показывающие, какую долю времени процессы реально простаивают из-за нехватки CPU/памяти/IO, что даёт более точный сигнал о реальном дефиците ресурсов, чем просто процент использования.
Пример кода
$ cat /sys/fs/cgroup/system.slice/docker-<id>.scope/cpu.pressure
some avg10=12.50 avg60=8.30 avg300=4.10 total=98765432
full avg10=2.10 avg60=1.50 avg300=0.80 total=12345678Что использовать на практике
- Практика. калибровка лимитов должна основываться на профилировании фактических пиковых паттернов нагрузки приложения (а не фиксированных "дефолтных" значений), с последующим мониторингом throttling (
nr_throttled) и PSI-метрик в проде, и итеративной донастройкой; переход на cgroups v2 (где поддерживается дистрибутивом и версией Docker) даёт более точные инструменты диагностики noisy neighbor, но требует проверки совместимости со всем используемым стеком мониторинга и оркестрации.
Подводные камни
- Риск. копируют лимиты ресурсов "по шаблону" из документации или соседнего проекта без профилирования конкретного приложения, получая либо постоянный throttling легитимно "взрывной" нагрузки, либо, наоборот, недостаточную защиту соседних контейнеров; смешивают интерпретацию метрик cgroups v1 и v2 при миграции, что приводит к неверным выводам о степени ограничения ресурсов.