Перейти к содержимому 
Высокая загрузка сети определяется эффективной обработкой IRQ сервера сигналы: Если вы грамотно распределите прерывания между ядрами процессора, вы уменьшите задержки и предотвратите падения. В этом руководстве я покажу вам, как сочетать балансировку IRQ, RSS/RPS и привязку к процессору, чтобы сделать высоконагруженный хостинг устойчивым. Производительность для работы.
Центральные пункты
- Распределение IRQ предотвращает появление "горячих точек" на отдельных ядрах процессора.
- Многопотоковая очередь плюс RSS/RPS распараллеливает обработку пакетов.
- Внимание NUMA сокращает время доступа и задержки между узлами.
- Управление процессором и распиновка потоков сглаживают время отклика.
- Мониторинг Проверяет скорость передачи данных, задержки, падения и загрузку ядра.
Краткое объяснение IRQ: почему они управляют нагрузкой на сеть
Для каждого входящего пакета сетевая карта сообщает через IRQ, что работа еще не завершена, иначе ядру пришлось бы активно опрашивать. Если задание остается на одном ядре, его загрузка увеличивается, в то время как другие ядра неиспользованный остаются. Именно в это время растут задержки, буферы кольца RX заполняются, и драйверы начинают отбрасывать пакеты. Я распределяю прерывания между подходящими ядрами, чтобы обработка пакетов была равномерной и предсказуемой. Это устраняет узкие места, сглаживает время отклика и сводит потери пакетов к минимуму.
Балансировка IRQ и сродство процессора в Linux
Служба irqbalance динамически распределяет прерывания, анализирует нагрузку и автоматически смещает сродства с течением времени. Для экстремальных профилей нагрузки я определяю аффинити вручную с помощью /proc/irq//smp_affinity и связывать сигналы конкретно с ядрами одного и того же NUMA-узлы. Это сочетание автоматической и тонкой настройки помогает мне чисто обрабатывать как базовые, так и пиковые нагрузки. Подробное введение в Обработка прерываний и оптимизация работы процессора Я использую их, чтобы помочь себе в планировании. Это по-прежнему важно: Я последовательно связываю топологию оборудования, распределение IRQ и потоки приложений друг с другом.
Практическое использование многоочередных сетевых карт, RSS и RPS
Современные сетевые карты предоставляют несколько очередей RX/TX, каждая очередь запускает свой собственный IRQs, а Receive Side Scaling (RSS) распределяет потоки по ядрам. Если аппаратных очередей недостаточно, я добавляю в ядро функции Receive Packet Steering (RPS) и Transmit Packet Steering (XPS) для дополнительного распределения потоков. Параллелизм. С ethtool -L ethX combined N Я настраиваю номер очереди на номер ядра соответствующего узла NUMA. Проверяю с помощью ethtool -S и nstat, независимо от того, происходят ли падения, опросы о занятости или пики высокой скорости передачи данных. Для более тонкого сглаживания нагрузки я также использую Коалесценция прерываний при планировании, чтобы сетевая карта не генерировала слишком много отдельных IRQ.
В следующей таблице показаны центральные компоненты и типичные команды, которые я использую для слаженной настройки:
| Строительный блок | Цель | Пример | Подсказка |
|---|---|---|---|
| irqbalance | Автоматическое распределение | systemctl enable --now irqbalance | Отправная точка для смешанных рабочих нагрузок |
| Affinity | Исправление булавочных уколов | echo mask > /proc/irq/XX/smp_affinity | Наблюдайте за назначением NUMA |
| Кии | Больше параллелизма | ethtool -L ethX combined N | Соответствие ядрам узла |
| RSS/RPS | Распределение потока | sysfs: rps_cpus/rps_flow_cnt | Полезно для небольшого числа очередей сетевых карт. |
| XPS | Упорядоченные ядра тракта TX | sysfs: xps_cpus | Избегайте переполнения кэша |
Разумное использование автоматической балансировки IRQ
Для серверов смешанного хостинга часто достаточно активировать irqbalance, потому что демон постоянно распознает изменения нагрузки. Я проверяю состояние через systemctl status irqbalance и взгляните на /proc/interrupts, чтобы увидеть распределение по очередям и ядрам. Если задержки увеличиваются пиками, я определяю тестовые ядра, которые в основном обрабатывают прерывания, и сравниваю измеренные значения до и после изменения. Я сохраняю конфигурацию простой, чтобы впоследствии можно было быстро провести аудит и откат. Только когда паттерны становятся ясными, я углубляюсь в создание булавок.
Ручное управление процессором для максимального контроля
При очень высокой скорости передачи данных я подключаю очереди RX к отдельным ядрам одного и того же процессора. NUMA-узлов и намеренно отделяю от них потоки приложений. Я изолирую отдельные ядра для прерываний, запускаю рабочие процессы на соседних ядрах и уделяю строгое внимание локальности кэша. Таким образом, я сокращаю количество межузловых обращений и минимизирую дорогостоящие контекстные переключения на горячем пути. Для воспроизводимости результатов я четко документирую маски IRQ, назначение очередей и принадлежность сервисов к потокам. Такая ясность позволяет сохранить время выполнения пакетов постоянная и уменьшает количество выбросов.
Четкая координация оптимизации процессора и приложений
Я установил Управление процессором часто устанавливается на „производительность“, поскольку изменение тактовой частоты увеличивает скачки латентности. Я привязываю критические процессы, такие как Nginx, HAProxy или базы данных, к ядрам, расположенным близко к ядрам IRQ, или намеренно разделяю их, если этого требует профиль кэша. По-прежнему важно ограничивать изменения контекста и поддерживать ядро в актуальном состоянии, чтобы оптимизация в чистом стеке вступила в силу. Я измеряю эффект от каждого изменения, а не делаю предположения и адаптирую его шаг за шагом. В результате получилась установка, которая работает под нагрузкой предсказуемо реагирует.
Правильная настройка мониторинга и измерений
Без измеренных значений настройка остается игрой в угадайку, поэтому я начну с сар, mpstat, vmstat, nstat, сс и ethtool -S. Для структурированных нагрузочных тестов я использую iperf3 и смотрю на пропускную способность, скорость передачи данных, задержку, ретрансляцию и загрузку ядра. Я фиксирую долгосрочные тенденции с помощью стандартных систем мониторинга, чтобы выявить такие закономерности, как вечерние пики, окна резервного копирования или кампании. Если вы хотите понять путь передачи данных в целом, вам будет полезно взглянуть на Конвейер обработки пакетов от IRQ сетевой карты к пользовательскому пространству. Только комбинация этих сигналов показывает, достигли ли балансировка IRQ и сродство желаемого эффекта. Эффект приносить.
Понимание NAPI, Softirqs и ksoftirqd
Чтобы справиться с пиками задержки при высокой нагрузке, я принимаю во внимание NAPI-механика и взаимодействие жестких IRQ и мягких IRQ. После первого аппаратного IRQ NAPI извлекает несколько пакетов из очереди RX в режиме опроса, чтобы избежать IRQ-штормов. Если мягкие IRQ не обрабатываются оперативно, они перемещаются в ksoftirqd/N Потоки, выполняющиеся только с обычным приоритетом, - классическая причина увеличения хвостовых задержек. Я наблюдаю /proc/softirqs и /proc/net/softnet_stat; высокий „время_замедления“ значение или падение указывают на то, что бюджет слишком ограничен. С помощью sysctl -w net.core.netdev_budget_usecs=8000 и sysctl -w net.core.netdev_budget=600 В качестве теста я увеличиваю время обработки одного опроса сетевой карты и бюджет пакетов. Важно: я увеличиваю значения постепенно, измеряю и проверяю, не возникает ли джиттер процессора или помехи для потоков приложений.
Тонкая настройка хэша RSS и таблицы перенаправления
RSS распределяет потоки по очередям через таблицу перенаправления (RETA). Я проверяю хэш-ключ и таблицу с помощью ethtool -n ethX rx-flow-hash tcp4 и при необходимости установите симметричное распределение. С ethtool -X ethX equal N или специально для каждой записи (ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...), я сопоставляю задания с предпочтительными ядрами узла NUMA. Цель состоит в том, чтобы Липкость потокаПоток остается на одном ядре, поэтому локальность кэша и сохранение блокировок в стеке остаются минимальными. Для сред с большим количеством коротких UDP-потоков я увеличиваю rps_flow_cnt на очередь RX, чтобы программный дистрибутив имел достаточно ведер и не создавал "горячих точек". Я помню, что симметричные хэши помогают в топологиях ECMP, но в контексте сервера баланс ядра - это то, что имеет наибольшее значение.
Разумно выбирайте разгрузку, GRO/LRO и размеры колец
Аппаратная разгрузка снижает нагрузку на процессор, но может изменить профиль задержки. Я проверяю с ethtool -k ethX, если TSO/GSO/UDP_SEG на TX и GRO/LRO активны на RX. GRO объединяет пакеты в ядре и почти всегда полезен для пропускной способности; LRO может быть проблематичным в настройках маршрутизации или фильтрации, и там его лучше не включать. Для API, критичных к задержкам, я тестирую меньшее объединение GRO (или временно отключаю), если задержки p99 доминируют. Я также регулирую размеры колец с помощью ethtool -G ethX rx 1024 tx 1024: Большие кольца перехватывают всплески, но увеличивают задержку при перегрузках; слишком маленькие кольца приводят к rx_missed_errors. Я полагаюсь на измеренные значения из ethtool -S (например. rx_no_buffer_count, rx_dropped) и согласуйте это с BQL (ограничения очереди байтов, автоматические на стороне ядра), чтобы очереди TX не были переполнены.
Виртуализация: IRQ в виртуальных машинах и гипервизоре
В виртуальных установках я контролирую распределение физических сетевых карт на хосте и устанавливаю Балансировка IRQ ясно. ВМ получают достаточно vCPU, но я избегаю слепой перекоммисии, чтобы задержки при планировании не увеличивали латентность. Современные паравиртуализированные драйверы, такие как virtio-net или vmxnet3, предоставляют мне лучшие пути для высокой скорости передачи данных. Внутри виртуальной машины я снова проверяю сродство и количество очередей, чтобы гость не стал узким местом. Очень важно иметь согласованное представление о хосте и госте, чтобы весь путь передачи данных правда.
Углубление виртуализации: SR-IOV, vhost и OVS
Для очень высокой скорости передачи данных я использую гипервизор SR-IOVЯ привязываю виртуальные функции (VFs) физической сетевой карты непосредственно к виртуальным машинам и подключаю их к ядрам соответствующих узлов NUMA. Это позволяет обойти часть стека хоста и снизить задержки. Там, где SR-IOV не подходит, я обращаю внимание на vhost-net и фиксировать потоки vhost, такие как рабочие приложения и ядра IRQ, чтобы не происходило перекрестных скачков NUMA. При настройке оверлея или коммутации я оцениваю дополнительные затраты на Linux bridge или OVS; для экстремальных профилей я использую OVS-DPDK, только если операционные усилия оправдывают измеряемое преимущество. То же самое относится и сюда: я измеряю pps, задержки и распределение CPU до принятия решений, а не после.
Опрос занятых и настройка пользовательского пространства
Для услуг, критичных к задержкам Занятый опрос уменьшить джиттер. В качестве теста я активировал следующее sysctl -w net.core.busy_read=50 и net.core.busy_poll=50 (микросекунды) и установите параметр сокета SO_BUSY_POLL выборочно для затронутых сокетов. Затем пользовательское пространство опрашивается незадолго до блокировки и ловит пакеты до того, как они перейдут в более глубокие очереди. Это требует затрат процессорного времени, но часто обеспечивает более стабильные задержки p99. Я держу низкие значения, слежу за загрузкой ядра и сочетаю опрос только с четким распределением потоков и фиксированным управлением процессором, иначе эффекты отменяют друг друга.
Посылочный фильтр, Conntrack и eBPF - стоимость с первого взгляда
Брандмауэры и NAT являются частью пути передачи данных. Поэтому я проверяю nftables/iptables-правила и убираю мертвые правила или глубокие цепочки. В загруженных установках я регулирую размер таблицы Conntrack (nf_conntrack_max, hash bucket number) или деактивировать Conntrack специально для потоков без статических данных. Если используются программы eBPF (XDP, tc-BPF), я измеряю их затраты времени на выполнение в расчете на один хук и устанавливаю приоритет „раннего сброса/перенаправления“, чтобы освободить дорогие пути. Важно четко определить ответственность: оптимизация происходит либо в разгрузке сетевой карты, либо в программе eBPF, либо в классическом стеке - дублирование только увеличивает задержку.
Изоляция центрального процессора и ядра домашнего хозяйства
Для абсолютно детерминированной задержки я храню фоновую работу над Процессоры для домашнего хозяйства off. Параметры ядра, такие как nohz_full=, rcu_nocbs= и irqaffinity= помогают держать выделенные ядра в значительной степени свободными от обработки тиков, обратных вызовов RCU и внешних IRQ. Я выделяю один набор ядер для рабочих приложений, другой - для IRQ и softirqs; системные службы и таймеры работают на отдельных ядрах. Это обеспечивает чистоту профилей кэша и снижает эффект преэмпшена. Гиперпоточность может увеличивать джиттер в отдельных случаях; я проверяю, сглаживает ли ее отключение для каждой пары ядер задержки p99, прежде чем принимать глобальное решение.
Руководство по диагностике и типичные антипаттерны
Когда возникают падения или пики задержки, я применяю структурированный подход: 1) /proc/interrupts проверьте, нет ли неравномерного распределения. 2) ethtool -S при падении RX/TX, ошибках FIFO, rx_no_buffer_count проверьте. 3) /proc/net/softnet_stat до „время_замедления" или "капли“. 4) mpstat -P ALL и топ для активности ksoftirqd. 5) Метрики приложения (количество активных соединений, ретрансляций с сс -ти). Антипаттерны, которых я избегаю: огромные кольца RX (скрытая перегрузка), дикое включение/выключение разгрузки без измерений, смешивание фиксированных аффинити с агрессивным irqbalance, или RPS и RSS одновременно без четкой целевой архитектуры. Каждое изменение получает сравнение измерений до/после и короткий протокол.
Примеры концепций для веб-хостинга и API
Классический хостинг-сервер
Для многих небольших сайтов я активирую irqbalance, Я устанавливаю несколько очередей и выбираю регулятор производительности. Я измеряю задержки L7 во время пиков и обращаю внимание на пики pps, которые в основном происходят с TLS и HTTP/2. Если аппаратных очередей недостаточно, я добавляю RPS для дополнительного распределения на программном уровне. Эта настройка позволяет поддерживать время отклика постоянная, даже если общая загрузка мощностей кажется умеренной. Регулярные проверки /proc/interrupts покажите мне, наклоняются ли отдельные ядра.
Высоконагруженный обратный прокси или API-шлюз
Для фронтендов с большим количеством соединений я фиксирую очереди RX на определенных ядрах и размещаю прокси-рабочих на соседних ядрах. Я принимаю осознанное решение о том, остается ли активным irqbalance или фиксированная распиновка дает более четкие результаты. Если очередей недостаточно, я выбираю RPS/XPS и калибрую Коалесцирующий, чтобы избежать шторма IRQ. Это позволяет мне добиться низкой задержки при очень высокой скорости передачи данных в секунду и держать хвостовые задержки под контролем. Документирование каждого изменения облегчает последующий аудит и сохраняет поведение предсказуемо.
Выбор поставщика и критерии выбора оборудования
Я обращаю внимание на сетевые карты с Многопотоковая очередь, надежная задержка в магистрали и актуальные версии ядра платформы. Сбалансированная топология процессоров и четкое разделение NUMA не позволяют сетевым прерываниям проникать в удаленные зоны памяти. Для проектов с высокими показателями pps выбор инфраструктуры оправдывает каждый час настройки, поскольку аппаратное обеспечение обеспечивает резервы. В практических сравнениях я хорошо работал с провайдерами, которые раскрывают профили производительности и предоставляют IRQ-дружественные настройки по умолчанию, например, с провайдерами типа webhoster.de. Такие установки позволяют мне эффективно использовать балансировку IRQ, RSS и сродство и минимизировать время отклика. тесно держать.
Пошаговая процедура для самостоятельной настройки
Шаг 1: Я определяю текущее состояние с помощью iperf3, сар, mpstat, nstat и ethtool -S, чтобы у меня были четкие начальные значения. Шаг 2: Если irqbalance не запущен, я активирую службу, жду под нагрузкой и сравниваю задержку, pps и падения. Шаг 3: Я настраиваю номер очереди и конфигурацию RSS в соответствии с ядрами соответствующего узла NUMA. Шаг 4: Я установил CPU governor в режим „производительность“ и назначил центральные службы на соответствующие ядра. Шаг 5: Только после этого я настраиваю ручное сродство и распиновку NUMA, если измеренные значения все еще показывают узкие места. Шаг 6: Я проверяю тенденции в течение нескольких дней, чтобы надежно классифицировать пики событий, резервных копий или маркетинговых пиков.
Краткое резюме
Эффективный Балансировка IRQ распределяет сетевую работу между подходящими ядрами, уменьшает задержки и предотвращает падения при высокой скорости передачи данных. В сочетании с многопоточными сетевыми картами, RSS/RPS, подходящим процессором-губернатором и чистым сродством потоков я надежно использую сетевой стек. Измеренные значения ethtool -S, nstat, сар и iperf3 ведите меня шаг за шагом к моей цели вместо того, чтобы плутать в темноте. Если вы продумаете топологию NUMA, распиновку IRQ и размещение приложений вместе, вы сможете свести время отклика к минимуму. низкий - даже во время пиковых нагрузок. Это означает, что высоконагруженный хостинг остается заметно отзывчивым, не сжигая лишние резервы процессора.
