Перейти к содержимому 
cgroup в Linux Контроллер ЦП регулирует, сколько вычислительного времени получают службы, контейнеры и процессы, и позволяет целенаправленно планировать производительность. Я подробно объясню, как взаимодействуют весовые коэффициенты, квоты и практические подходы, чтобы вы могли надежно распределять время процессора и избегать узких мест.
Центральные пункты
- взвешивание против Ограничение понять: справедливое распределение или жесткий верхний предел
- cgroup v2 предпочтительно: чёткая семантика, последовательная иерархия
- вес процессора и cpu.max: два рычага регулировки
- systemd Преимущества: настройка правил для каждой службы
- Мониторинг и Прозрачность: чтение данных из cpu.stat и PSI
Понимание cgroups: группы процессов и цели
Я описываю процессы в Группы объединяю их и управляю через них ресурсами, такими как ЦП, память и ввод-вывод, в четко разграниченных иерархиях. Вместо того чтобы «жонглировать» отдельными PID, я отношу к одной группе управления целые сервисы, контейнеры или пулы рабочих процессов и устанавливаю четкие правила. Таким образом я предотвращаю ситуацию, когда разрастающаяся задача замедляет работу машины, в то время как важные компоненты должны оперативно реагировать. Особенно в контексте хостинга такой подход окупается, поскольку на одном и том же оборудовании работают многие клиенты и службы. Хорошее представление о практической организации дает эта статья по теме cgroups и хостинг, который позволяет наглядно продемонстрировать распределение нагрузок.
Как работает контроллер ЦП
Контроллер ЦП разделяет время вычислений использует два механизма: относительное взвешивание и абсолютное ограничение пропускной способности. Взвешивание означает, что группы получают доли процессорного времени в соотношении друг к другу, как только возникает конкуренция; при этом группы с более высокими значениями чаще получают временные интервалы. Ограничение по квоте фиксирует потребление в рамках фиксированного временного интервала, даже если конкуренции нет. Я выбираю взвешивание, когда на первом плане стоят справедливость и динамическая загрузка, и устанавливаю квоты, когда жесткий верхний предел должен оставаться неизменным. В документации ядра четко объясняется это различие и показывается, как оба механизма вместе образуют целостную модель управления [1].
cgroup v1 и v2: различия и файлы
С cgroup v2 Я управляю правилами ЦП более унифицированно и наглядно по сравнению со старой версией v1. В v1 я использовал разные файлы для каждого контроллера; в v2 я сосредоточился на параметре cpu.weight для относительного приоритета и cpu.max для жесткого ограничения пропускной способности. Такое чёткое разделение сокращает время настройки, позволяет избежать недоразумений и упрощает проведение аудитов. В сценариях хостинга с большим количеством контейнеров иерархия версии v2 обеспечивает понятные правила на всех уровнях. Оценку практического применения даёт статья о cgroup v2 в хостинге, в котором рассматривается вопрос о согласованном управлении при совместном использовании аппаратного обеспечения.
| Тема | cgroup v1 | cgroup v2 | Типичные параметры |
|---|---|---|---|
| Взвешивание по ЦП | cpu.shares | вес процессора | вес процессора (по умолчанию часто 100) |
| Квоты/ограничения для ЦП | cpu.cfs_quota_us + cpu.cfs_period_us | cpu.max | cpu.max (например, 20 000 100 000) |
| Иерархия | Отдельные контроллеры | Единая иерархическая структура | Общие правила для каждого уровня |
| Реальное время | Отдельный контроллер rt | Ограничения для RT | См. примечания к ядру [1] |
Для администраторов важно, чтобы Последовательность сокращаю количество ошибок в наборе правил и ускоряю вступление изменений в силу. Я документирую параметры на узлах групп, чтобы каждый мог понять их текущее влияние. При миграции с версии v1 я тщательно проверяю эквиваленты, особенно соотношения «Shares» к «Weight» и «CFS-Quota» к «cpu.max». Только после того, как тестовые нагрузки реагируют в соответствии с ожиданиями, я переношу производственные сервисы в новую иерархию. Такой дисциплинированный подход к переходу позволяет впоследствии сэкономить много циклов технической поддержки.
Иерархия, поддеревья и делегирование
В cgroup v2 я управляю контроллерами на каждый уровень и делегируйте их по мере необходимости. Через cgroup.subtree_control Я включаю контроллер ЦП для дочерних узлов; systemd, как правило, делает это автоматически, когда я задаю свойства ЦП. Важно: в версии v2 я в идеале держу процессы в Группы листьев а не промежуточным узлам. Таким образом, правила остаются более однозначными, а распределение нагрузки четко соответствует иерархической структуре. В сложных конфигурациях я присваиваю слайсы целым сервисам (например,. tenant-a.slice), в том числе сервисы и пулы рабочих процессов. Такое четкое разделение упрощает делегирование полномочий командам, которые работают в „своих“ поддеревьях, не нарушая при этом глобальных политик.
Важные параметры: cpu.weight и cpu.max
Я использую вес процессора, чтобы установить относительный приоритет служб: если службе A присвоен более высокий вес, чем службе B, то при высокой нагрузке A будет чаще получать время процессора. Стандартное значение в v2 часто составляет 100; более высокие значения отдают предпочтение соответствующей группе, но я остаюсь в разумных пределах, чтобы соотношение оставалось контролируемым. Для жесткого ограничения я записываю в cpu.max квота и период, например 20000 100000 примерно 20 процентов слота vCPU. С помощью max В первую очередь я снимаю ограничение, но оставляю период без изменений, что упрощает диагностику. Red Hat доступно описывает типичные настройки и демонстрирует их влияние на работу системы [2].
Дополнительные настройки: cpu.weight.nice и UClamp
Для команд, которые используют классический хорошо-семантику, версия v2 предлагает cpu.weight.nice практическая связь: я могу объединять группы в сфере -20..19 оценивать, что внутренне соотносится со шкалой весов. Таким образом, относительные ожидания („немного отдавать предпочтение“, „слегка сдерживать“) остаются последовательными, без необходимости каждый раз устанавливать конкретные веса. Кроме того, при необходимости я Зажимное устройство через cpu.uclamp.min и cpu.uclamp.max, чтобы задать минимальный или максимальный предел эффективной загрузки ЦП на уровне планировщика. Таким образом я, например, гарантирую, что сервис, чувствительный к задержкам, не опустится ниже необходимой базовой загрузки даже при небольшом количестве потоков, или что пакетные задания не получат слишком сильного ускорения. Эта точная настройка дополняет весовые коэффициенты и квоты, но не заменяет их: я всегда проверяю, насколько UClamp совместим с моей политикой управления и энергопотреблением, прежде чем внедрять его в широком масштабе.
Планирование рабочих нагрузок: справедливость против жестких ограничений
Я сознательно принимаю решение о том. Справедливость или приоритет отдается строгим верхним пределам. Для веб-сервисов, для которых важна низкая задержка, я слегка увеличиваю вес, чтобы они выполнялись в приоритетном порядке при конкуренции, не нанося при этом чрезмерного ущерба другим группам. Для вычислительно-емких пакетных заданий я дополнительно устанавливаю квоту, чтобы они никогда не занимали слишком много времени, даже если система в остальном простаивает. Базам данных я присваиваю умеренный вес и наблюдаю за тем, как влияют контрольные точки, перестроение базы данных или крупные запросы; при необходимости вношу временные корректировки. Эти правила я сочетаю с оповещениями, чтобы своевременно реагировать, прежде чем задержки станут критическими.
Поведение коэффициентов на многоядерных процессорах и выбор периода
Часто возникают трудности с интерпретацией Производительность на многоядерных системах. Коэффициент относится к Общее время вычислений по группе за каждый период, а не по отдельным ядрам. CPUQuota=200% или cpu.max = 200000 100000 позволяют выделять примерно две секунды процессорного времени на период длительностью 100 мс — распределяя их между всеми потоками/ядрами. Это может означать, что многие потоки будут кратковременно работать параллельно, пока квота группы в текущем периоде не будет „использована“ и не начнёт применяться ограничение. Я избегаю недоразумений, всегда рассматривая квоты в терминах „слотов ЦП“ и адаптируя их к степени параллелизма службы.
Стандартный период часто составляет 100 мс. Более короткие периоды (z. B. (50 мс) позволяют быстрее активировать ограничение, но могут вызывать микроджиттер; более длительные периоды сглаживают колебания, но реагируют с большей задержкой. В systemd я настраиваю это с помощью CPUQuotaPeriodSec= и проверяю, что лучше достигаются: пиковые значения задержки или целевые показатели пропускной способности. Для интерактивных сервисов я измеряю сквозную задержку, а для пакетной обработки ориентируюсь на общую пропускную способность и справедливость по отношению к соседям.
Практика: настройка с использованием systemd и cgroup v2
В systemd я задаю правила для каждой службы, потому что Служебные файлы обеспечить воспроизводимую конфигурацию. С помощью systemctl set-property Я постоянно вношу изменения, а с помощью файлов «drop-in» аккуратно управляю версиями настроек. Пример: systemctl set-property --runtime nginx.service CPUWeight=150 NGINX легко устанавливает приоритеты; systemctl set-property --runtime batch.service CPUQuota=20% ограничивает пакетные задания. Я постоянно вношу в /etc/systemd/system/service.d/limits.conf установите соответствующие параметры и перезагрузите модули. Для удобства при начале работы рекомендуется ознакомиться с этим руководством по Управление ресурсами systemd, в котором кратко изложены наиболее распространённые варианты.
# Примеры для systemd v245+ с cgroup v2
# Относительная приоритезация
systemctl set-property --runtime nginx.service CPUWeight=150
# Жесткий верхний предел
systemctl set-property --runtime batch.service CPUQuota=20%
# Комбинация в файле drop-in
mkdir -p /etc/systemd/system/php-fpm.service.d
cat < /etc/systemd/system/php-fpm.service.d/cpu.conf
[Service]
CPUWeight=120
CPUQuota=50%
EOF
systemctl daemon-reload
systemctl restart php-fpm.service
Слайсы для арендаторов и команд
Для определения границ клиентов или команд я использую Слайсы в качестве организационной структуры. Один «слайс» объединяет несколько сервисов и областей, которые регулируются единообразно. Таким образом, я распределяю бюджеты по клиентам, не занимаясь настройкой каждой единицы по отдельности, и контролируемо делегирую внесение изменений.
# — сегмент арендатора со стандартными правилами
mkdir -p /etc/systemd/system/tenant-a.slice.d
cat < /etc/systemd/system/tenant-a.slice.d/cpu.conf
[Slice]
CPUWeight=120
CPUQuota=150%
# Дополнительно: период для более точного ограничения
CPUQuotaPeriodSec=100ms
EOF
systemctl daemon-reload
systemctl restart tenant-a.slice
Все услуги на сайте tenant-a.slice наследуют эти настройки. При кратковременных пиках я временно увеличиваю вес, но оставляю коэффициент неизменным, чтобы не вытеснить соседние системы.
Мониторинг и устранение неполадок
Я проверяю эффективность и побочные эффекты с помощью Прозрачность в метриках. Файлы cpu.stat и cpu.pressure (PSI) для каждой cgroup я получаю данные о долях, времени ожидания и заторах, которые указывают на ограничение пропускной способности или перегрузку. С помощью топ, htop и systemd-cgtop Я отслеживаю тенденции распределения в режиме реального времени и сопоставляю их со своими правилами. Если задержки растут, но ЦП находится в режиме простоя, проблема, скорее всего, связана с вводом-выводом или блокировками, а не с ограничениями ЦП; в таком случае я не спешу корректировать веса. После внесения изменений я документирую измеренные значения в течение как минимум одного цикла нагрузки, чтобы избежать ложных корреляций.
Руководство по мониторингу: что я конкретно читаю
cpu.stat: usage_usec, user_usec, system_usec отображать расход; nr_periods, nr_throttled, throttled_usec разоблачают жесткое ограничение. Растет nr_throttled/nr_periods если разница превышает несколько процентов, это означает, что диапазон слишком узкий или период слишком короткий.cpu.pressure: Я наблюдаю некоторые средние значения 10/60/300 для заторов, влияющих на задержку. Постоянно повышенное значение, несмотря на наличие свободных процессоров, указывает на конфликты блокировок, конфликты аффинности или удаленные запросы NUMA.systemd-cgtopиps: Я проверяю, могут ли потоки действительно работать параллельно или же они ожидают доступ к эксклюзивным ресурсам.
Для проведения воспроизводимых тестов я использую stress-ng, sysbench или использую собственные генераторы нагрузки и делаю снимки метрик до и после. Только когда показатели стабильно соответствуют ожиданиям, я внедряю изменения.
В режиме реального времени и особенности
На сайте Реальное время-При работе с рабочими нагрузками я следую рекомендациям, приведенным в документации по ядру, поскольку версия v2 управляет контроллером ЦП для RT лишь в ограниченном объеме. Определенные потоки RT должны находиться в корневой cgroup, и настройка требует осторожного подхода. Кроме того, я проверяю, насколько RT-планирование совместимо с квотами, чтобы ни один дедлайн не был нарушен непреднамеренно. Для типичных веб-сервисов и баз данных я использую стандартные политики, поскольку такая конфигурация позволяет более надёжно планировать повседневную работу. Если мне требуется RT, я чётко разделяю системы или резервирую ядра, чтобы избежать непредвиденных взаимодействий [1].
Точное управление на многоядерных системах
Контроллер ЦП разделяет Временное окно, а не тактовую частоту, поэтому при необходимости я комбинирую его с cpuset и аффинностью. Для снижения задержек я ограничиваю переключение между сокетами, привязываю потоки к ядрам в пределах NUMA и оптимизирую распределение IRQ. Пакетные службы я запускаю в более гибком режиме, чтобы они могли использовать остаточную мощность, не блокируя ядра для критически важных интерфейсов. Я проверяю политики Turbo или Powersave, поскольку изменения частоты могут значительно повлиять на поведение системы под нагрузкой. Только совокупность квот, весов, аффинности ЦП и стратегии энергопотребления обеспечивает стабильные результаты.
SMT, NUMA и аффинность на практике
На системах с SMT/гиперпотоки Я обращаю внимание на то, что два логических потока на одном физическом ядре не обеспечивают два полных слота ЦП. Коэффициент „100 %“ охватывает один логический слот, но не обязательно полную производительность физического ядра. Поэтому я измеряю задержку и пропускную способность как с использованием SMT, так и без него. В системах NUMA я ограничиваю критически важные службы с помощью AllowedCPUs= (cpuset) или CPUAffinity= используйте локальные ядра и соответствующим образом настройте привязку к памяти, чтобы удаленный доступ не срывал все тщательно разработанные планы.
Передовой опыт в области хостинга и контейнеров
Я начинаю с умеренного По умолчанию: Веб-сервисам присваиваю чуть более высокий вес, базы данных — близко к стандартному значению, пакетная обработка — с квотой. Для арендаторов устанавливаю верхние пределы на каждого клиента и разрешаю пиковые нагрузки за счет весовых коэффициентов, если нет других потребностей. Я документирую профили по сценариям использования, например „критичные по задержке“, „смешанные“ и „вычислительно-интенсивные“, и устанавливаю для каждого профиля чёткие диапазоны значений weight и cpu.max. Изменения я сначала тестирую в тестовой среде с использованием синтетической нагрузки, которая реалистично отражает пиковые нагрузки. Журналы и метрики я держу в пределах, близких к ограничениям cgroup, чтобы диагностика не уходила в туман.
Оркестрация контейнеров: доли, запросы и ограничения
В контейнерных средах я создаю карту Запросы на относительную взвешенность и Лимиты жесткие квоты. Это позволяет использовать пиковые нагрузки, пока у узлов есть свободные ресурсы, и обеспечивает справедливое распределение в условиях конкуренции в соответствии с весом. Критически важные поды или сервисы получают немного больший вес, при этом ограничения не ущемляют других. Я слежу за тем, чтобы сумма лимитов на каждый узел реалистично соответствовала имеющимся ресурсам ЦП; в противном случае, несмотря на четкие правила, произойдет системное ограничение пропускной способности, которое затронет всех арендаторов.
Примеры конфигураций и расчетные примеры
Я всегда рассчитываю коэффициенты в Акции на каждый слот vCPU: cpu.max = ПЕРИОД КВОТЫ соответствует КВОТА/ПЕРИОД слота. Пример: 20000 100000 составляют 0,2 от одного процессора; при использовании четырех процессоров это максимально 0,8 общего слота, но распределение не гарантируется. Что касается процентных значений в systemd, я пишу: CPUQuota=20%, что, в зависимости от версии, согласуется с параметром cpu.max. При установке жестких ограничений необходимо сопоставить поведение при пиковых нагрузках с задержкой: слишком короткий период может вызывать микрозадержки, а слишком длинный — обеспечивает более плавную работу, но реагирует с большей инерцией. Поэтому я тестирую периоды в диапазоне 50–100 мс и выбираю вариант, соответствующий классу задержки сервиса [2].
Переход с версии v1 на v2 без неожиданностей
При переходе я переношу cpu.shares на сайте вес процессора и cpu.cfs_quota_us/period_us на сайте cpu.max. Прагматичное отображение для «Shares» выглядит следующим образом: 1024 → ~100, 2048 → ~200, 512 → ~50. Точные корректировки я вношу после нагрузочных испытаний, так как шкалы различаются. Кроме того, я планирую разработать правила версии 2 для детей кумулятивный действуют: ограничивающая квота на родительском узле ограничивает все подгруппы в совокупности. Поэтому я часто отменяю родительские квоты (max) и тонко регулирую настройки в слоях, чтобы избежать побочных эффектов.
Распространенные ошибки и меры по их устранению
- 100 % перепутано с „все ядра“: 100 % соответствуют одному логическому слоту процессора, а не всей машине. Решение: рассчитать квоту исходя из необходимого количества слотов (например, 400 % для четырёх слотов).
- Слишком короткий цикл: Незначительные задержки при работе с интерактивными сервисами. Решение: увеличить периодичность или использовать весовые коэффициенты вместо квот.
- Взвешивание, измеренное без учета конкуренции: Эффект от снижения веса проявляется только в условиях конкуренции. Решение: проводить испытания с реальной параллельной нагрузкой.
- Забыть о квотах для родителей: Ограниченный родительский элемент снижает производительность всех дочерних элементов. Решение:
cpu.max=maxна родительском элементе, ограничения на листьях. - NUMA/сокет игнорируется: Задержка, несмотря на свободный процессор. Решение: проверить аффинность/наборы процессоров и локальность памяти.
Резюме
С Контроллер ЦП Я целенаправленно распределяю вычислительное время, устанавливаю справедливые приоритеты и выставляю жесткие ограничения там, где это необходимо. cgroup v2 предоставляет для этого четкие параметры cpu.weight и cpu.max, которые я планирую и измеряю в зависимости от рабочей нагрузки. С помощью systemd я устанавливаю правила для каждой службы, проверяю их эффективность с помощью cpu.stat и PSI и корректирую настройки без догадок. Для арендаторов, контейнеров и смешанных серверных сред такое управление остается ключом к обеспечению надёжности и предсказуемости. Тот, кто документирует правила, постепенно внедряет их и проверяет с помощью нагрузочных тестов, предотвращает узкие места и сохраняет контроль над временем процессора.
