Перейти к содержимому 
В Linux функция IRQ Balance управляет распределением аппаратных прерываний между ядрами процессора и, таким образом, определяет, будет ли сетевая нагрузка распределяться равномерно или же отдельные ядра будут тормозить работу системы. Я покажу тебе, как целенаправленно использовать irqbalance, когда переходить на ручную аффинность IRQ и какие настройки следует использовать на серверах с высокой сетевая нагрузка действительно имеют значение.
Центральные пункты
Прежде чем перейти к подробностям, я кратко изложу основные решения, которые надежно помогали мне в проектах с высокой нагрузкой на ввод-вывод. Я считаю целесообразным в качестве отправной точки использовать автоматическое распределение с помощью irqbalance, измеряю его эффективность и выборочно вношу корректировки. При детерминированных нагрузках я вручную привязываю отдельные IRQ к определённым ядрам и исключаю остальные процессоры из автоматического распределения. Я с самого начала учитываю близость NUMA, поскольку она снижает задержку и обеспечивает пропускную способность. Благодаря четкому мониторингу я быстрее выявляю узкие места и устраняю их без лишних Риски.
В этом списке указано, на что я обращаю особое внимание при настройке:
- Автоматический Сначала: включить irqbalance, измерить эффект
- аффинность целенаправленно: фиксация критических IRQ, снижение джиттера
- Запрещенные процессоры: Оставить свободные ядра для потоков приложений
- NUMA Обратите внимание: размещайте IRQ рядом с узлом памяти
- Мониторинг: Проверить /proc/interrupts и задержки
Краткое объяснение основ IRQ
Запрос прерывания (IRQ) — это сигнал, с помощью которого аппаратное обеспечение передает работу процессору, тем самым прерывая выполняемую задачу. Если на одно ядро поступает слишком много таких сигналов, его загрузка возрастает, а время отклика увеличивается, в то время как другие ядра остаются незадействованными; именно это я и хочу решить с помощью Распространение избежать. irqbalance динамически распределяет эти IRQ между несколькими ядрами и периодически оценивает состояние системы. Для этого я сначала смотрю /proc/interrupts и по столбцам определяю, сколько IRQ поступает на каждый процессор. Если в отдельных столбцах количество становится чрезмерно большим, я активно корректирую его, тем самым сокращая ненужные Горячие точки.
Автоматическое распределение с помощью irqbalance
В современных дистрибутивах я запускаю службу irqbalance, которая по умолчанию периодически корректирует распределение IRQ. Я включаю её вручную с помощью systemctl enable --now irqbalance и проверяю статус, прежде чем приступать к более глубокому вмешательству; таким образом я использую имеющиеся Автоматический. В зависимости от системы файлы конфигурации находятся в /etc/sysconfig/irqbalance или /etc/default/irqbalance, там я могу исключить процессоры или IRQ. Особенно полезна переменная IRQBALANCE_BANNED_CPUS в качестве 64-разрядной маски для резервирования определённых ядер под приложения. Те, кто хочет более подробно ознакомиться с практическими примерами, найдут здесь краткое введение в Производительность сети, на которые я часто ссылаюсь на семинарах и которые использую в проектах.
Надежная реализация ручной привязки IRQ
Если рабочие нагрузки очень чувствительны к джиттеру или если необходимо, чтобы определенные ядра оставались свободными исключительно для процессов пользовательского пространства, я вручную настраиваю аффинность IRQ. Для этого я записываю битовые маски в /proc/irq/НОМЕР IRQ/smp_affinity и определяю, на каких ядрах может выполняться прерывание; это позволяет планировать работу Провести. Сначала я определяю соответствующие номера IRQ с помощью grep на сайте /proc/interrupts. Для сетевых устройств я часто привязываю очереди RX/TX к ядрам, расположенным рядом с потоками приложений, оставляя другие ядра свободными. Хорошее объяснение этого подхода содержится в этой краткой Руководство по аффинности IRQ, который я регулярно использую в качестве отправной точки.
В приведенной ниже таблице представлены распространенные битовые маски и их значение. Я использую эти примеры, чтобы быстро и с минимальным количеством ошибок настраивать конфигурации, а затем проверять их действие с помощью /proc/interrupts на проверить.
| Цель | Пример маски (шестнадцатеричный формат) | ядра | Комментарий |
|---|---|---|---|
| Только CPU0 | 0x1 | 0 | Простой тест, небольшой рассеяние |
| Только CPU1 | 0x2 | 1 | Отделяет IRQ от CPU0, снижает Интерференция |
| CPU0–CPU1 | 0x3 | 0–1 | Распределенное между двумя ядрами, легкое Рельеф |
| CPU2–CPU3 | 0xC | 2-3 | Полезно, если значение 0–1 для потоков приложений бесплатно оставайтесь |
| CPU0–CPU3 | 0xF | 0–3 | Широкое распределение по 4 ядрам, смешивание Загрузить |
Измерение: правильное считывание /proc/interrupts
Я открываю файл /proc/interrupts и вижу по одному IRQ на строку, а в каждом столбце — счетчики для каждого процессора; это сразу же указывает на дисбаланс видимый. Если один столбец растёт значительно быстрее других, нагрузка концентрируется именно там. Тогда я проверяю, какой драйвер к этому причастен, и распределены ли уже RSS/RPS. Кроме того, я временно запускаю irqbalance в фоновом режиме с отладочной выводкой, чтобы понять его решения и избежать ошибочных оценок. После каждого изменения я снова проверяю счетчики и измеряю задержку под нагрузкой, чтобы подтвердить полученные результаты и исключить ненужные Риски может избежать.
Изоляция ЦП и маски запрещённых областей
Я установил IRQBALANCE_BANNED_CPUS, чтобы последовательно исключать определённые ядра из автоматического распределения; таким образом я освобождаю ресурсы для потоков приложений. В более новых конфигурациях я дополнительно использую IRQBALANCE_BANNED_IRQS, если отдельные устройства должны работать автономно на одном ядре; это снижает количество помех для чувствительных Рабочие нагрузки. В сценариях с низкой задержкой я целенаправленно отключаю irqbalance и статически фиксирую IRQ, чтобы перераспределение не мешало работе. Те, кто хочет более подробно разобраться в том, как CPU распределяет обработку прерываний, найдут полезную информацию по этой теме Обработка прерываний на серверах. Важно помнить: сначала нужно провести измерения, затем определить параметры и снова проверить их эффективность, чтобы избежать неожиданностей в Операция которых следует избегать.
Аспекты NUMA и близость
В системах NUMA я стараюсь по возможности направлять IRQ на ядра того узла NUMA, в памяти которого находятся соответствующие данные; это снижает задержку и повышает Пропускная способность. Я сочетаю это с аффинностью ЦП для приложения, чтобы потоки и прерывания выполнялись локально друг относительно друга. irqbalance хорошо работает в среде NUMA, но при необходимости я корректирую настройки с помощью масок запрета. Крайне важно не распределять нагрузку между узлами, если её и так можно удерживать локально. Соблюдая эту близость, вы обеспечите постоянное время отклика и сэкономите ценные Кэш-ресурсы.
Интенсивный курс по сетям: RSS, RPS/RFS и XPS
Прежде чем проводить точную настройку масок IRQ, я проверяю такие функции сетевой карты, как RSS, а также механизмы ядра, такие как RPS/RFS и XPS; они оказывают значительное влияние на распределение пакетов. RSS уже распределяет прерывания очередей между несколькими ядрами, в то время как RPS/RFS формируют обработку в ядре, а XPS — пути передачи; это позволяет избежать ненужных Горячие точки. Я согласовываю эти механизмы со своей стратегией IRQ, чтобы они не мешали друг другу. Если очереди, аффинности IRQ и аффинности приложений согласованы, сетевой ввод-вывод работает значительно плавнее. После этого я снова провожу измерения в условиях реальной нагрузки, прежде чем приступить к дальнейшим Шаги поставлю.
MSI‑X, Multi‑Queue и упорядоченная структура очереди
Многие сетевые адаптеры 10–100G используют MSI-X и предоставляют отдельные векторы прерываний для каждой очереди RX/TX. Сначала я проверяю с помощью ethtool -l eth0 (количество каналов) и /proc/interrupts, сколько очередей действительно активны и как они называются (например,. eth0‑TxRx‑0, eth0‑TxRx‑1). Цель состоит в том, чтобы привести количество очередей в соответствие с количеством используемых ядер на каждый узел NUMA и детерминированно зафиксировать их. С помощью ethtool -L eth0 combined N Я настраиваю количество очередей; после этого я упорядочиваю возникающие IRQ с помощью smp_affinity соответствующим ядрам. Я слежу за тем, чтобы пары RX/TX из одной и той же очереди размещались на одном ядре или, по крайней мере, на одном сокете, чтобы Локальность кэша вступает в силу. Важно: изменения количества очередей и аффинности я проверяю непосредственно в /proc/interrupts и проведу краткий тест нагрузки (pps/пропускная способность), прежде чем приступить к дальнейшей оптимизации.
Коалесценция прерываний и бюджет NAPI
Особенно при высоких скоростях передачи пакетов значения коалесценции влияют на эффективность моей стратегии IRQ. С ethtool -c eth0 я вижу, есть ли rx-мкс и rx-frames установлены. Увеличение коалесценции снижает количество IRQ в секунду и снижает нагрузку на ЦП, но при этом увеличивает задержку и джиттер. Я настраиваю осторожно: небольшими шагами, каждый раз измеряя показатели (задержка p95/p99 и нагрузка на ЦП). На стороне отправителя это влияет tx-usecs аналогично. Кроме того, я масштабирую поведение NAPI с помощью net.core.netdev_budget и net.core.netdev_budget_usecs, когда NET_RX начинает скапливаться в SoftIRQ. Если количество пропущенных пакетов растет в /proc/net/softnet_stat, в качестве теста я увеличиваю бюджет или более последовательно распределяю очереди RX; если системная задержка становится слишком большой, я уменьшаю эти настройки. GRO/LRO и TSO/GSO я учитываю в совокупности: чрезмерная агрегация снижает нагрузку на IRQ, но может вызывать пики задержки — я выравниваю их с учётом профиля приложения.
Прозрачное считывание SoftIRQ
Помимо аппаратных прерываний (HardIRQ), я определяю нагрузку на программные прерывания (SoftIRQ). С помощью cat /proc/softirqs Я наблюдаю NET_RX и NET_TX на каждый процессор; если отдельные столбцы занимают преобладающую долю, в них оказывается слишком много работы, которая попадает в потоки ksoftirqd. Один top -H покажи мне быстро, какие ksoftirqd/N Загрузка ядер. Я измеряю на более глубоком уровне с помощью perf top или коротких рекордная производительность Запускать, чтобы выявить «горячие точки» в драйвере или при обработке стека. Если запускаются потоки ksoftirqd (вместо непосредственной обработки в контексте IRQ), задержка часто значительно увеличивается; в этом случае я реагирую улучшением распределения очередей, увеличением бюджета NAPI или целенаправленной привязкой затронутых потоков ksoftirqd к определенным ядрам процессора с помощью taskset -pc. Важно: я документирую эти изменения, так как они оказывают едва заметное влияние, и в случае сомнений мне может понадобиться быстро восстановить предыдущую версию.
Правильное использование SMT/Hyper-Threading и топологии
Когда SMT включено, я делю одно физическое ядро с двумя логическими процессорами. Я проверяю отношения между «братьями» с помощью lscpu -e и /sys/devices/system/cpu/cpuX/topology/thread_siblings_list. Для траекторий, чувствительных к задержкам, я стараюсь не размещать поток приложения и соответствующий IRQ на одном физическом ядре (разные потоки SMT); они конкурируют за доступ к вычислительным единицам и кэшам. Я предпочитаю такие пары, в которых, например, поток приложения работает на CPU2, а соответствующая очередь RX — на CPU3 (другое физическое ядро, тот же узел NUMA). Если SMT нарушает стабильность, я вместо этого планирую использовать меньшее количество, но эксклюзивных физических ядер и избавляюсь от нестабильности Помехи.
Виртуализация: KVM, vhost и SR-IOV
В виртуализованных средах я рассматриваю хост и гостевую систему отдельно. На хосте я аккуратно распределяю физические IRQ сетевых карт по ядрам соответствующего узла NUMA. Если гостевая система использует virtio-net, возникают дополнительные IRQ для потоков vhost; я распознаю их в /proc/interrupts и привязываю рабочие процессы vhost к очередям физического сетевого адаптера. На уровне гостевой системы я также настраиваю RSS/XPS и аффинности IRQ, если драйвер virtio предоставляет несколько очередей. При использовании SR-IOV целесообразно назначать каждому гостю один или несколько виртуальных портов (VF) с собственными векторами MSI-X и фиксировать их в гостевой системе; такая изоляция улучшает показатели задержки и предсказуемости. Я придерживаюсь чёткой схемы: vCPU гостевой системы на выделенных pCPU, соответствующие IRQ — на близлежащие ядра, а потоки эмулятора и vhost не смешивать с вычислительно-интенсивными потоками приложений — так путь передачи данных остаётся планируемый.
Частота процессора, состояния C и настройка NOHZ
Задержки IRQ ухудшаются, когда ядра переходят в глубокие состояния C или работают в режиме агрессивной тактовой частоты. Для чувствительных рабочих нагрузок я устанавливаю регулятор CPU на выступление (cpupower frequency‑set -g performance) и сокращаю время пребывания в глубоких состояниях C с помощью опций загрузчика или драйверов, чтобы сократить время пробуждения. На серверах с высокой нагрузкой это часто дает лучший эффект, чем любая тонкая настройка аффинности. При очень жестких профилях задержки я добавляю nohz_full= и rcu_nocbs= для изолированных ядер, чтобы Tick-Timer и RCU-Call-Backs не создавали помех; процессоры обслуживания я намеренно определяю отдельно. Однако эти изменения я тестирую отдельно, поскольку они могут оказывать побочное влияние на планирование и энергопотребление. Главное — тщательно сравнивать показания до и после изменения, иначе я буду блуждать в потемках при Оптимизации в темноте.
Systemd, Cgroups и изоляция приложений
Помимо фиксации IRQ, я разделяю потоки приложений с помощью Cgroups и systemd-Affinity. С помощью CPUAffinity= В файлах Unit и контроллерах ЦП (cgroup v2) я назначаю службам фиксированные ядра. Таким образом я предотвращаю переключение потоков со стороны планировщика на те ЦП, которые я выделил для IRQ. В контейнерных средах я устанавливаю cpuset.cpus и проверьте cpuset.cpus.effective, чтобы обещания о выделении ресурсов действительно выполнялись. Важно: IRQBALANCE_BANNED_CPUS управляет только там, где irqbalance не распределяет; потоки ядра, такие как ksoftirqd, по-прежнему подчиняются планировщику. Таким образом, для жесткой изоляции мне требуется сочетание аффинности IRQ, аффинности процессора для служб и, при необходимости, изолированных ядер. Таким образом, путь передачи данных и приложение остаются четко разделенными, а Загрузить не смешивается бесконтрольно.
Типичные ошибки и меры по их устранению
Я никогда не отключаю irqbalance в общем, не зная картины нагрузки; иначе IRQ быстро скапливаются на нескольких ядрах. Столь же нежелательно открывать все ядра для всех IRQ, хотя чувствительные потоки используют эксклюзивный Ресурсы нужно. Еще одна ошибка: не тестировать изменения изолированно и не измерять их последствия; в результате остается неясным, что на самом деле помогает. Я также учитываю пары Hyper-Threading: лучше, чтобы поток приложения и соответствующий IRQ не использовали одно и то же физическое ядро. Я документирую каждый шаг и создаю точки отката, чтобы в случае проблем быстро вернуться к последнему хорошо Вернуться к настройкам.
Практический контрольный список для серверов
Я всегда начинаю с базовой конфигурации: включаю irqbalance, фиксирую нагрузку на систему, отслеживаю /proc/interrupts и измеряю задержки; только после этого приступаю к настройкам. На втором этапе я завершаю работу, выполнив IRQBALANCE_BANNED_CPUS выделяю те ядра, которые должны оставаться зарезервированными для потоков приложений; таким образом я предотвращаю ненужные пересечения IRQ. Затем я фиксирую критические IRQ с помощью smp_affinity ограничиваюсь несколькими тщательно выбранными ядрами и соблюдаю принцип близости NUMA. Затем проверяю показатели RSS/RPS/RFS и XPS, а также возможности переноса нагрузки сетевой карты, чтобы рационально распределить работу. В заключение провожу тестирование под производственной нагрузкой, сравниваю метрики и оставляю только те изменения, которые доказали свою эффективность работа.
Файлы конфигурации и команды systemd
Я активирую службу с помощью systemctl enable --now irqbalance и проверь с помощью systemctl status irqbalance срок действия; вот как я устанавливаю Сервис наверняка готов. В /etc/sysconfig/irqbalance или /etc/default/irqbalance я ставлю IRQBALANCE_BANNED_CPUS а также дополнительно IRQBALANCE_BANNED_IRQS. Изменения я вношу с помощью systemctl restart irqbalance и одновременно слежу за показателями в /proc/interrupts. Для тестирования я использую режим «Foreground» в irqbalance, чтобы отслеживать принятие решений в режиме реального времени. Только после того, как я пойму, как это работает, я внесу соответствующие изменения в Конфигурация.
Когда я отключаю irqbalance
В системах, работающих в режиме реального времени, или при использовании приложений, чрезвычайно чувствительных к задержкам, я останавливаю irqbalance и статически фиксирую IRQ, чтобы перераспределение не создавало помех. Я изолирую ядра для этих рабочих нагрузок и намеренно запускаю IRQ трафика на других ядрах; таким образом, потоки приложений остаются планируемый. Даже в случае строго разделённых сред Tenant этот подход оправдан, поскольку позволяет уменьшить взаимодействие между виртуальными машинами или контейнерами. Если встречаются драйверы, которые хуже работают с автоматической настройкой, я исключаю их IRQ из списка запрещенных. Как только модели нагрузки вновь становятся более изменчивыми, я снова активирую irqbalance и проверяю эффект с помощью свежих Измеренные значения.
Краткое резюме
Я начинаю с irqbalance, оцениваю результат и вношу выборочные корректировки, вместо того чтобы слепо вмешиваться повсеместно; таким образом я сохраняю общее представление о системе и Прозрачность. Для чувствительных рабочих нагрузок я фиксирую соответствующие IRQ, изолирую ядра для приложений и учитываю близость NUMA. С помощью масок запрета я контролирую, где может работать irqbalance, и предотвращаю нежелательные перемещения. Я регулярно проверяю /proc/interrupts, задержку и пропускную способность, чтобы изменения были подкреплены достоверными данными. Такой подход позволяет в полной мере использовать потенциал IRQ Balance и заметно снизить нагрузку на серверы при сетевой нагрузке реактивный.
