CPU Load Distribution распределение нагрузки на ядра процессора в ядре Linux подробно

Управление распределением нагрузки на ядра процессора - один из ключевых аспектов производительности серверных систем. Когда нагрузка распределяется неравномерно, одни ядра работают на пределе возможностей, а другие простаивают, что приводит к снижению общей производительности системы и увеличению задержек ответа. Ядро Linux предоставляет множество механизмов управления распределением нагрузки, включая балансировку, привязку процессов к ядрам (CPU affinity), управление прерываниями и настройку тактовых частот ядер.

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

Что такое распределение нагрузки на ядра процессора

Распределение нагрузки на ядра процессора - это процесс определения, на каком ядре будет выполняться каждый поток или процесс. Целью является равномерное распределение вычислительной нагрузки между всеми доступными ядрами для максимального использования ресурсов процессора и минимизации задержек. При этом равномерность не всегда является оптимальной целью: для задач с интенсивным использованием кэша выгоднее удерживать поток на одном ядре (cache locality), чем мигрировать его между ядрами ради балансировки.

Ядро Linux использует несколько механизмов для распределения нагрузки:

• Планировщик задач (scheduler) определяет, на каком ядре выполнить каждый поток, выбирая ядро с учётом домена планирования, нагрузки и родства к кэшу.
• Привязка к ядрам (CPU affinity) позволяет закрепить процесс или поток за конкретным набором ядер, исключив миграцию.
• Балансировка нагрузки (load balancing) автоматически перераспределяет задачи между ядрами для достижения равномерной загрузки.
• Управление прерываниями (IRQ affinity) определяет, на каком ядре обрабатываются прерывания от устройств.

Архитектура планировщика задач в Linux

Ядро Linux использует планировщик CFS (Completely Fair Scheduler) в качестве основного планировщика задач, а в новых версиях ядра - EEVDF. Планировщик стремится справедливо распределить время процессора между всеми процессами, основываясь на их приоритетах и времени выполнения. Каждое ядро имеет собственную очередь выполнения (runqueue), а планировщик на каждом ядре выбирает из неё наиболее нуждающуюся задачу.

Ключевые компоненты системы планирования:

• Очередь задач (run queue) - очередь задач, готовых к выполнению на каждом ядре; задача может мигрировать между очередями при балансировке.
• Домены балансировки (sched domains) - иерархия групп ядер (SMT-пары, физические ядра, NUMA-узлы), на уровнях которой периодически запускается балансировка.
• Планировщик с учётом NUMA (NUMA-aware scheduling) - учёт топологии NUMA при распределении задач: задача размещается ближе к её памяти, чтобы минимизировать задержки доступа к удалённым NUMA-узлам.
• Группы планирования (cgroup cpuset) - группы процессов, ограниченные набором ядер, что позволяет изолировать критичные нагрузки.

При миграции задачи между ядрами теряется содержимое кэшей L1/L2 (а частично и L3), что стоит от сотен микросекунд до миллисекунд производительности. Поэтому планировщик балансирует между равномерностью загрузки и сохранением локальности кэша, параметрами sched_migration_cost_ns и sched_balance_interval.

Топология процессора играет определяющую роль: ядра внутри одного физического ядра (SMT-соседи) делят исполнительные блоки и L2-кэш, поэтому размещение двух нагруженных потоков на SMT-соседях может дать меньше производительности, чем на разных физических ядрах. Команда lscpu -e показывает полную карту соответствия ядер, узлов NUMA и кэшей, с которой следует сверяться при любой ручной привязке. Для многоядерных серверов с двумя процессорами важно понимать, что память одного NUMA-узла недоступна другому напрямую: доступ к удалённой памяти в 1.5-2.5 раза медленнее локального, а кросс-узловой трафик проходит через межпроцессорную шину (UPI/Infinity Fabric), создавая конкуренцию и там.

Настройка привязки процессов к ядрам (CPU affinity)

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

Команда taskset позволяет запускать процесс с привязкой к конкретным ядрам:

taskset -c 0,1,2,3 ./myapp

Команда taskset с опцией -p позволяет изменить привязку уже запущенного процесса:

taskset -p -c 0-7 <PID>

Для программного управления привязкой используются системные вызовы sched_setaffinity и sched_getaffinity, а для контейнеров - cgroup v2 (cpuset.cpus). Типичный приём на сервере с NUMA - привязка процесса БД к ядрам того NUMA-узла, где расположена его память, что сокращает задержки доступа к памяти вдвое и более.

Балансировка нагрузки и управление прерываниями

Ядро Linux автоматически балансирует нагрузку между ядрами через механизм доменов балансировки. Сбалансированная нагрузка обеспечивает эффективное использование всех ядер и предотвращает перегрузку отдельных ядер. Основные параметры настраиваются через sysctl:

• kernel.sched_migration_cost_ns - порог стоимости миграции, выше которого задача считается "не заслуживающей" переноса.
• kernel.sched_nr_migrate - количество задач, переносимых за один цикл балансировки.
• kernel.sched_balance_interval - периодичность запуска балансировки.

Прерывания от устройств (сетевых карт, накопителей) по умолчанию обрабатываются на ядрах, определённых маской прерывания. Неправильное распределение прерываний перегружает одно ядро, пока остальные простаивают. Демон irqbalance автоматически распределяет прерывания между ядрами:

systemctl enable irqbalance
systemctl start irqbalance

Ручное управление привязкой прерываний выполняется через файлы в /proc/irq: запись маски в /proc/irq/N/smp_affinity направляет прерывание на выбранные ядра. Для сетевых карт с несколькими очередями (RSS) рекомендуется распределять очереди по ядрам, на которых также работают потоки приложения, чтобы данные кэшировались на одном ядре.

Взаимодействие с управлением частотой: governor (регулятор частоты) влияет на то, как быстро ядро выходит на полную частоту под нагрузкой. Режим performance удерживает максимальную частоту, устраняя задержки на разгон, но увеличивая потребление; режим schedutil балансирует частоту с загрузкой. Для серверов с критичной латентностью рекомендуется performance, для энергоэффективных кластеров - schedutil с быстрым откликом (параметр up_rate_limit_us). Наряду с этим энергосберегающие состояния (C-states) добавляют задержки выхода из сна: для ultra-low-latency систем C-states отключают через параметры загрузки ядра intel_idle.max_cstate=0 processor.max_cstate=0.

Мониторинг распределения нагрузки на ядра процессора

Для мониторинга распределения нагрузки на ядра процессора используются различные инструменты:

• mpstat (из пакета sysstat) - статистика по каждому ядру с разбивкой по режимам (user, system, irq, idle), выполняется как mpstat -P ALL 1.
• htop и top - наглядное отображение загрузки каждого ядра в реальном времени.
• perf stat и perf top - детальная статистика производительности, включая счётчики PMU (кэш-промахи, миграции).
• schedstat (/proc/schedstat) и sched_debug (/sys/kernel/debug/sched/debug) - внутренняя статистика планировщика.

Ключевые признаки проблем распределения: постоянная загрузка одного ядра выше 90 процентов при простоях остальных (перегрузка прерываниями или single-threaded узким местом), высокая доля миграций в perf, высокий контекст-свичинг при низкой полезной нагрузке. Регулярный анализ метрик нагрузки позволяет выявлять дисбаланс до того, как он повлияет на пользователей.

Изоляция ядер для критичных нагрузок

Когда требуется гарантированная производительность (трейдинг, телеком, аудио), критичные процессы изолируют от остальной системы. Ядра исключаются из общего планирования параметром загрузки ядра isolcpus=2-7 (или через cgroup v2 cpuset с флагом partition), после чего обычные процессы на них не попадают, и задача, привязанная к изолированному ядру, получает его монопольно.

Дополнительная изоляция достигается перемещением прерываний (записью маски в smp_affinity с исключением изолированных ядер), отключением тиков ядра на пустом ядре (nohz_full=2-7) и настройкой rcu_nocbs для переноса обратных вызовов RCU. Такая конфигурация сокращает джиттер исполнения с сотен микросекунд до единиц, что критично для задач с жёсткими требованиями к латентности. Цена изоляции - уменьшение пула ядер для общей нагрузки, поэтому изолируют только необходимый минимум.

Практические примеры настройки для разных серверов

Для сервера базы данных типовой подход выглядит так: NUMA-привязка процессов PostgreSQL к ядрам узла с его shared memory, распределение прерываний дисковых контроллеров на отдельные ядра, отключение irqbalance в пользу ручных масок для воспроизводимости. Прирост от такой настройки при высоких нагрузках достигает 15-30 процентов по транзакциям в секунду.

Для веб-сервера с сетевой нагрузкой критично сопоставление очередей NIC и worker-потоков: очереди привязываются к ядрам, на которых работают потоки обработки, что сохраняет данные в кэше L2 одного ядра. При 25-гигабитном линке и восьми очередях правильное сопоставление сокращает латентность и повышает пропускную способность на 10-20 процентов.

Для сервера приложений с переменной нагрузкой чаще оптимальна политика "не мешай планировщику": оставить балансировку ядру, ограничившись NUMA-привязкой и настройкой irqbalance. Ручная оптимизация оправдана только там, где измеренный дисбаланс действительно влияет на метрики сервиса.

Практический порядок настройки распределения нагрузки

1. проанализировать текущее распределение нагрузки с помощью mpstat и htop, выявив перегруженные и простаивающие ядра;
2. определить критические приложения, которым требуются выделенные ядра, и сетевые очереди, генерирующие основной объём прерываний;
3. настроить привязку процессов к ядрам через taskset, sched_setaffinity или cgroup cpuset, учитывая топологию NUMA;
4. настроить балансировку прерываний через irqbalance или ручные маски в /proc/irq, сопоставив очереди NIC с ядрами приложения;
5. провести тестирование с реальными нагрузками и скорректировать параметры миграции и привязки;
6. настроить мониторинг и алертинг на загрузку ядер и диспаритет загрузки.

Типичные ошибки: слишком жёсткая привязка, когда процесс ограничен ядрами, занятыми другими задачами, и не может использовать свободные ресурсы; изоляция ядер для критичных задач без учёта прерываний, которые всё равно попадают на изолированные ядра; игнорирование NUMA-топологии, когда процесс работает с памятью удалённого узла. Каждая из этих ошибок снижает производительность сильнее, чем отсутствие какой-либо настройки вовсе.

Заключение по распределению нагрузки на ядра

Распределение нагрузки на ядра процессора в ядре Linux - сочетание автоматических механизмов планировщика и ручных инструментов настройки. Автоматика (CFS/EEVDF, домены балансировки, irqbalance) обеспечивает разумный уровень по умолчанию, а ручная настройка (affinity, изоляция ядер, привязка прерываний) позволяет выжать оставшиеся проценты производительности для критичных нагрузок. Правильная настройка требует понимания топологии процессора и профиля нагрузки приложения, но окупается предсказуемой латентностью и полным использованием аппаратных ресурсов.