Перейти к содержимому 
Я показываю, как процессор softirq вместе с NAPI, распределением IRQ и дизайном очередей ограничивает или высвобождает пропускную способность сети в хостинге. Благодаря четким точкам измерения, целенаправленной настройке и чистому сродству я уменьшаю Задержки и стабильно повышать пропускную способность производительных серверов.
Центральные пункты
Эти основные идеи обеспечивают эффективную передачу сетевых пакетов через процессор, ядро и сетевую карту и сокращают время отклика до минимума. постоянная низкий.
- Бюджет НАПИ тонкая настройка: Большее количество пакетов на один опрос снижает накладные расходы и сглаживает Загрузка процессора.
- Балансировка IRQ и сродство: избегайте "горячих точек", увеличивайте количество посещений кэша, Пики задержки нажать.
- Многопотоковая очередь, RSS/RPS/XPS: распараллеливание потоков, поддержание выравнивания NUMA, pps поднять.
- Разгрузка использовать осознанно: GRO/LRO, TSO, оценивайте коалесценцию, Джиттер в поле зрения.
- Изоляция и Busy Polling: предсказуемое время отклика на выделенные ресурсы Ядра.
Основы: Что происходит в ядре во время сетевого трафика
Сначала пакет попадает в аппаратное прерывание, после чего ядро берет на себя работу в SoftIRQs и циклы опроса NAPI. Я слежу за тем, чтобы быстрая фаза HardIRQ оставалась очень короткой, а фактическая логика перемещалась в нужный контекст, чтобы время процессора не прекращается. Потоки ksoftirqd вступают в работу только в том случае, если прямая обработка невозможна, что быстро приводит к образованию очередей при постоянной нагрузке. Именно здесь возникает время ожидания, что отражается в увеличении TTFB и колебаниях пропускной способности. Если вы хотите углубиться, вы можете найти практические знания по обработке IRQ в этой статье на Обработка прерываний и производительность процессора, которые я использую для категоризации.
NAPI, SoftIRQs и ksoftirqd: контроль задержек вместо управления ими
NAPI уменьшает штормы прерываний, принимая несколько пакетов за один прогон в рамках определенного бюджета и тем самым минимизируя время прерывания. Накладные снижает. Если бюджет недостаточен, посылки скапливаются, ksoftirqd работает в горячем режиме и Латентность ощутимо возрастает. В таких ситуациях я систематически проверяю /proc/softirqs и /proc/net/softnet_stat, чтобы увидеть падения, time_squeeze или переполненные очереди. Затем я постепенно увеличиваю net.core.netdev_budget или net.core.netdev_budget_usecs и параллельно отслеживаю загрузку процессора, распределение p95/p99 и потери пакетов. Хитрость заключается в том, чтобы сделать достаточно работы за один опрос, не перегружая интерактивное выполнение пользовательских потоков.
Балансировка IRQ и сродство: избегайте "горячих точек", увеличивайте количество обращений к кэшу
Одно ядро со всеми IRQ сетевой карты становится узким местом, поскольку ему приходится обслуживать прерывания, мягкие IRQ и потоки приложений; поэтому я распределяю IRQs целевой. Служба irqbalance помогает, но для высокой скорости передачи данных я явно сопоставляю очереди RX/TX через сродство с подходящими ядра. В системах NUMA я привязываю очереди к ядрам одного узла, чтобы избежать удаленных обращений к памяти. Потоки приложений работают на соседних, но отдельных ядрах, что улучшает локальность кэша и планируемость. Это руководство по стратегическому распределению дает хороший обзор Балансировка IRQ в центре обработки данных, который я использую в качестве эталона для тонкой настройки.
Многопотоковая очередь, RSS/RPS/XPS: правильное использование распараллеливания
Современные сетевые карты поставляются с несколькими очередями RX/TX, которыми я могу управлять через RSS потокам и таким образом достигаю реального параллелизма. Если карта предлагает слишком мало очередей, я использую RPS/XPS для корректировки программного обеспечения, чтобы разумно распределить пакеты между потоками. ядра для проталкивания. Чистое распределение хэшей важно для того, чтобы поток всегда оставался на одном и том же процессоре и не возникало дорогостоящих искажений кэша. В то же время я держу пути TX и RX близко друг к другу, чтобы избежать конкуренции блокировок и ненужных межузловых обращений. Это увеличивает пропускную способность в секунду без торможения одного ядра.
Сродство процессора к пользовательскому пространству: сквозное мышление
Я планирую путь данных от NIC-IRQ через очереди NAPI к рабочим потокам приложения таким образом, чтобы пакеты достигали места назначения без лишних зацепов и Время отклика остается постоянной. Чтобы добиться этого, я последовательно отделяю ядра для прерываний/softIRQ от ядер приложений и создаю четкие Affinity-правила. Веб-серверы, обратные прокси и базы данных получают фиксированные наборы процессоров, расположенные близко к ядрам IRQ, чтобы пути были короткими. Кроме того, я настраиваю CPU governor на производительность, чтобы изменения тактовой частоты не приводили к джиттеру в p99. Такое последовательное назначение делает поведение предсказуемым и помогает точно диагностировать узкие места.
Выгрузки, GRO/LRO, брандмауэр и eBPF: экономьте нагрузку, не летая вслепую
Выгрузка контрольных сумм, TSO и коалесценция время процессора, Однако они могут изменять размеры пакетов, поведение пакетов и джиттер, поэтому я специально измеряю их влияние. GRO/LRO объединяют кадры и снижают нагрузку на стек, но для требований реального времени я принимаю решение в зависимости от ситуации. Деактивация или ограниченного использования. Таблицы Conntrack и глубокие цепочки nftables/iptables стоят часов, поэтому я убираю лишние правила и упрощаю пути. При необходимости я прибегаю к eBPF (XDP, tc-BPF), чтобы принимать ранние решения на сетевой карте и избегать дорогостоящих путей. Хорошей отправной точкой для практики тонкой настройки является этот обзор Коалесценция прерываний, что я принимаю во внимание для чувствительных бюджетов задержки.
Опрос в режиме занятости и изоляция процессора: фиксация времени отклика
Для целей с большими задержками я использую опрос по занятости, чтобы сокеты пользовательского пространства получали пакеты еще раньше и Время ожидания сократить. Это увеличивает нагрузку, но обеспечивает мне очень плотное распределение p99 для API или торговых нагрузок на выделенных ресурсах. Ядра. Кроме того, я изолирую ядра с помощью isolcpus=, nohz_full= и rcu_nocbs=, чтобы таймеры, RCU и системные службы запускались только на центральных процессорах. Такое разделение предотвращает вмешательство в работу латентных ядер и делает поведение воспроизводимым. В результате мы получили четкую дорожную карту: выделенные ядра, ранний сбор пакетов, определенные бюджеты.
Мониторинг и поиск неисправностей: от симптома к причине
Я начинаю с pps, пропускной способности и загрузки ядра, затем проверяю падения и активность ksoftirqd-потоков с течением времени, чтобы надежно распознать закономерности. Такие инструменты, как sar, htop, ss, nload и ethtool, показывают мне, когда и где возникает перегрузка, а также то. Кии достигают своих пределов. Важны распределения, а не средние значения, чтобы не потерять вечерние пики, окна cron или кампании. Я соотношу пики TTFB с распределением IRQ, бюджетом NAPI и настройками разгрузки, чтобы произвести целевую корректировку. Корректировки сродства IRQ или нового бюджета NAPI часто бывает достаточно для заметного снижения тайм-аутов.
Параметры настройки с первого взгляда
Приведенный ниже обзор помогает мне разумно использовать изменения и четко распределять эффекты, прежде чем вносить постоянные изменения. развертывания план. Я итеративно тестирую каждую корректировку, измеряю распределение задержек и наблюдаю побочные эффекты на CPU и память. Я изменяю только один пункт в тестовом окне, чтобы причина и следствие оставались ясными. Затем я документирую результаты и устанавливаю пороговые значения для предупреждений. Таким образом я добиваюсь воспроизводимых улучшений без риска неожиданностей в продуктивном трафике.
| Параметр/функция | Эффект в пути передачи данных | Когда собирать/активировать | Риски/побочные эффекты |
|---|---|---|---|
| net.core.netdev_budget | Больше пакетов по опросу NAPI | Для падений в softnet_stat | Длинные опросы вытесняют пользовательские темы |
| net.core.netdev_budget_usecs | Ограничение временного окна для одного опроса | Для джиттера, вызванного большими всплесками | Слишком маленький: больше изменений в контексте |
| RSS/RPS/XPS | Распределите потоки между ядрами | Для горячих точек на ядре | Неправильные хэши: искажения кэша |
| Сродство к IRQ | Привяжите IRQ к ядру | С помощью NUMA-Missmatch | Неправильное распределение создает новые горячие точки |
| GRO/LRO/TSO | Сокращает количество пакетов | Для узкого места процессора | Джиттер, большие всплески |
| Занятый опрос | Ранний сбор посылок | Для сложных целей на p99 | Большее потребление процессора |
Кольца RX/TX и глубина кия: правильное измерение буферов
Даже при правильном распределении IRQ и подходящем бюджете слишком маленькие или слишком большие кольца сетевых карт могут снижать производительность. Поэтому я проверяю размеры колец RX/TX карты и адаптирую их к характеру серийной передачи и целевым значениям задержки. Слишком маленькие кольца приводят к просадкам в сетевой карте во время пиков трафика, что видно в статистике драйвера как rx_missed_errors или fifo_errors. Слишком большие кольца маскируют перегрузку, увеличивают задержку и создают длинные края в p95/p99. Я ищу золотую середину: достаточно буфера для поглощения коротких всплесков, но не так много, чтобы пакеты “старели” в очередях.
Кроме того, я рассматриваю хост-сторону tx_queue_len и используемый Qdisc. С помощью sch_fq или fq_codel я могу сгладить поведение всплесков и распределить большие пакеты TSO с помощью pacing. Это уменьшает микровсплески на порту коммутатора и делает кривую задержки более плавной - важно для смешанных рабочих нагрузок, в которых небольшие RPC выполняются наряду с большими загрузками. Я отслеживаю статистику ethtool и сопоставляю ее с softnet_stat, чтобы определить, где возникает перегрузка - в кольце сетевых карт, в бэклоге netdev или в Qdisc.
MTU, джамбо-кадры и сегментация
Die MTU это классический рычаг, который часто недооценивают. Джамбо-кадры уменьшают количество пакетов на Гбит/с и снижают нагрузку на центральный процессор - но только если путь действительно поддерживает джамбо-кадры из конца в конец. Поэтому я систематически проверяю удаленные станции, коммутаторы и туннели. Как только где-то происходит фрагментация до 1500, возникает риск возникновения проблем с MTU пути, повторных передач и ненужных ошибок. Джиттер. В центрах обработки данных с преобладающей связью между Востоком и Западом целесообразно использовать однородную стратегию 9k, в то время как 1500 часто является более стабильным выбором для рабочих нагрузок, ориентированных на Интернет.
Я всегда оцениваю MTU в сочетании с TSO/GSO/GROСлишком агрессивное пакетирование может привести к большим всплескам в TX, которые заполняют буферы восходящего потока и вызывают пики задержки. Цель - последовательный путь: разумная сегментация на передатчике, достаточные механизмы темпа и GRO, которые экономят работу на стороне приемника, не нарушая требований реального времени.
UDP, QUIC и потоковые рабочие нагрузки: рассмотрим особенности
Не весь трафик является TCP. UDP-тяжелые профили (DNS, VoIP, QUIC, телеметрия) ведут себя по-разному в RSS/RPS и GRO. Современные стеки поддерживают UDP-GRO/GSO, которые могут снизить нагрузку на CPU - я использую их выборочно и измеряю, увеличивается ли риск переназначения или джиттер. Для нагрузок QUIC/HTTP3 чистое распределение потоков имеет решающее значение: RPS может помочь, если сетевая карта предлагает слишком мало очередей RSS, но не должна “разбрасывать” горячие кэш-потоки. На стороне TX я установил XPS чтобы объединить пути передачи данных и снизить вероятность блокировки. На практике спокойное распределение по ядру окупается, особенно при работе с большим количеством UDP-потоков среднего размера, когда важно каждое попадание в кэш.
Виртуализация и контейнеры: чистая интеграция хоста, гостя и vhost
В виртуализированных средах работа переключается между хостом, потоками vhost и гостевыми IRQ. Я слежу за тем, чтобы vhost-net-потоки получают собственные ядра и не сталкиваются с рабочими приложениями. Их аффинити должны совпадать с физическими очередями RX/TX, иначе будет происходить ненужная кросс-процессорная миграция. В госте я проверяю очереди virtio-net, активирую multi-queue и настраиваю RSS/RPS по аналогии с голым металлом. Где на первый план выходят латентность и pps. SR-IOV Еще большее снижение накладных расходов - необходимым условием является согласованная топология NUMA: VF, vCPU и память находятся на одном узле.
В стеке контейнеров оверлейные сети, глубокие цепочки NAT и сложные топологии CNI приводят к дополнительным хопам. Для сервисов, критичных к задержкам, я предпочитаю hostNetwork или бережливые сети (macvlan/ipvlan), выравниваю пути NAT и сохраняю Conntrack как можно меньше. Важна последовательная стратегия использования процессора: ядра IRQ и NAPI хоста должны располагаться по соседству с ядрами, на которых работают vhost/container workers - только так можно сохранить путь данных коротким и предсказуемым.
Планирование, C-состояния и IRQ-потоки
Поскольку задержка - это не только время вычислений, но и Время пробуждения Я минимизирую глубокие C-состояния на латентных ядрах. Агрессивная экономия энергии может стоить миллисекунды до того, как SoftIRQ действительно будет запущен. Поэтому я полагаюсь на регуляторы производительности, ограничиваю глубокие C-состояния и поддерживаю постоянство турбо, чтобы сделать скачки частоты предсказуемыми. Не менее важно Потоковая передача данных IRQЕсли драйверы позволяют, я переношу работу в потоки IRQ и расставляю приоритеты так, чтобы RX запускался раньше последующей работы без полного вытеснения пользовательской части. Взаимодействие политик расписания, привязанностей и бюджетов - дело непростое; я тестирую шаг за шагом, веду журнал p99 и слежу за вмешательством в работу ksoftirqd, который в противном случае становится тайным узким местом.
Углубленное наблюдение: точки слежения, счетчики, гистограммы
Если метрики остаются неясными, я иду на один уровень глубже: я использую точки трассировки ядра вокруг netif_receive_skb, napi_poll и net_dev_queue, для просмотра длительности опроса, объема пакетов и времени ожидания в виде гистограмм. Такие распределения показывают, не слишком ли долго длится 1 % опрос или не исчерпываются ли отдельные очереди. Кроме того, ethtool-rx/tx-счетчики, ретрансляции TCP, просмотры занятых опросов и softnet_stat ясно показывают, где теряются пакеты. Я использую анализ падений, чтобы определить, падает ли сетевая карта (кольцо переполнено), разрушается ли бэклог netdev (time_squeeze) или замедляется Qdisc/брандмауэр. Только когда все эти части головоломки сходятся, я настраиваю кольца, бюджеты или разгрузку.
Оптимизация путей обеспечения безопасности и фильтрации
Сложные ACL, глубокие цепочки nftables/iptables и широкие таблицы conntrack увеличивают постоянную задержку на пакет. Я консолидирую правила, работаю с наборами/картами и перемещаю общие падения как можно дальше по пути - в идеале как можно раньше на сетевой карте (XDP/clsact), если задержка критична. Потоки без статики, телеметрия или известные “безопасные” порты могут быть использованы целенаправленно. без отслеживания чтобы устранить необходимость в дорогостоящих поисках. В то же время я поддерживаю таблицы состояний в свежем состоянии, корректирую размеры хэшей в зависимости от пиков нагрузки и агрессивно очищаю осиротевшие записи. Цель - чистый, прослеживаемый путь политики, который не заметен в профиле как постоянная нагрузка.
Типичные антипаттерны и как я их избегаю
- Все IRQ на одном ядре: приводит к перегрузкам и горячим ksoftirqd. Противоядие: целевые аффинити на каждую реплику, NUMA-когерентность.
- Слепая максимизация колец/бюджетов: скрывает перегрузку, увеличивает хвосты задержек. Противоядие: увеличивайте постепенно, измеряйте распределения.
- Неправильная конфигурация хеширования потока: Потоки скачут между ядрами, кэши сгорают. Противоядие: стабильные RSS-ключи, RPS/XPS только с четкой целью.
- Потоки приложений на тех же ядрах, что и SoftIRQ: Помехи и джиттер. Противоядие: жесткое разделение, распределение по соседству.
- Оверлеи/НАТ без бюджета: добавляется к каждому переходу. Устранение: оптимизируйте пути, размещайте сети для рабочих нагрузок с задержкой.
- Энергосбережение на латентных ядрах: Глубокие C-состояния замедляют реакцию. Противоядие: регулятор производительности, ограничение C-состояния.
- Выгрузки без измерений: TSO/GRO может усугубить всплески и джиттер. Устранение: активируйте специфическую рабочую нагрузку, контролируйте p99.
Практический хостинг: шаги, которые работают
Я начинаю с чистого этапа измерений, устанавливаю базовые показатели и делаю все изменения небольшими и в короткие сроки, чтобы я мог Причины могут быть разделены. Затем я активирую irqbalance, проверяю автоматическое распределение и, если необходимо, устанавливаю сродства вручную, пока не будет Горячие точки больше не видны. Затем я настраиваю Multi-Queue, RSS и - при необходимости - RPS/XPS, синхронизированные с NUMA. Я привязываю рабочие приложения к ядрам по соседству с их IRQ-ядрами, но без прямого столкновения. Наконец, я очищаю пути брандмауэра, проверяю таблицы conntrack и принимаю осознанные решения о разгрузке, основываясь на целевых показателях задержки.
Пример плейбука для задержек в p99
Сначала я измеряю p95/p99 с помощью репрезентативной нагрузки и безопасных журналов из /proc/softirqs и /proc/net/softnet_stat, чтобы Капли и time_squeeze хорошо видны. Затем я увеличиваю netdev_budget или netdev_budget_usecs шаг за шагом и удерживаю p99 после каждого изменения, чтобы я мог видеть реальные Тенденции узнайте. Параллельно я привязываю IRQ к ядрам узла NUMA и перемещаю рабочие приложения к подходящим соседям. Если p99 продолжает скакать, я тестирую варианты GRO/LRO и профили коалесцирования прерываний, каждый из которых имеет короткий путь измерения. Только когда дистрибутив остается стабильным, я передаю конфигурацию ролям Ansible или дропшипам systemd.
Краткая версия для администраторов
Я добиваюсь наибольшего эффекта, если SoftIRQs, Бюджет NAPI, сродство IRQ и потоки приложений как последовательный путь данных. Я распределяю сетевую работу по ядрам, поддерживаю NUMA-когерентные очереди и разумно соединяю рабочих, чтобы Маршруты не затягивайте. Я намеренно устанавливаю разгрузку и измеряю джиттер, а не слепо оптимизирую пропускную способность. Для жестких целей по задержкам я полагаюсь на опрос занятых и изоляцию процессоров, а CPU-домохозяйки перехватывают помехи. Если вы будете выполнять эти шаги дисциплинированно, вы получите постоянную пропускную способность, более узкое распределение задержек и среду хостинга, которая предсказуемо реагирует на пики нагрузки.
