Сетевые настройки и производительность серверной ОС: диагностика и настройка под высокой нагрузкой

Краткий ответ: как повысить производительность сети на сервере

Производительность сети на сервере повышают после замера исходного состояния и поиска конкретного узкого места. Сначала зафиксируйте пропускную способность, p50/p95/p99 задержки, retransmits, drops, ошибки интерфейса, загрузку CPU и долю softirq. Затем повторите измерение под нагрузкой, близкой к рабочей.

Путь пакета нужно разложить на отдельные этапы: приложение, очередь сокета, TCP или UDP, сетевой стек Linux, NAPI и softirq, драйвер, DMA, очереди NIC, физический линк, коммутатор, гипервизор и удалённый узел. Такая модель называется latency pipeline. Она помогает понять, где появляется задержка, вместо попытки объяснить весь симптом одним показателем.

Буферы сглаживают короткие всплески, MTU уменьшает или увеличивает накладные расходы на передачу, TSO, GRO, GSO и checksum offload снижают нагрузку на CPU, а IRQ, RSS, RPS и XPS распределяют обработку по ядрам. Каждая настройка полезна для конкретного профиля нагрузки. Увеличение очереди может убрать drops при кратком всплеске и одновременно повысить p99 из-за роста времени ожидания. Проблема может находиться в NIC, прошивке, BIOS/UEFI, виртуальном свитче, vCPU или на удалённой стороне, поэтому Linux нельзя считать единственным уровнем проверки.

Рабочее правило: одна гипотеза, одно контролируемое изменение, одинаковый тест до и после, зафиксированный результат и готовый rollback.

С чего начать настройку сети на сервере: профиль нагрузки и базовые метрики

Параметры сетевого стека зависят от характера трафика. Сервер с тысячами коротких TCP-соединений испытывает другие ограничения, чем узел хранения, который передаёт несколько потоков по 10 Гбит/с. Запишите тип протокола, средний размер сообщения, число соединений в секунду, длительность потоков, целевую задержку и требования к пропускной способности.

Какие симптомы указывают на сетевое узкое место

• Растёт число TCP retransmits при стабильном трафике и отсутствии проблем на диске или CPU приложения.
• Увеличиваются drops и ошибки интерфейса, счётчики rx_no_buffer, missed или аналогичные значения драйвера.
• В /proc/net/softnet_stat растут dropped или time squeeze, а одно ядро занято обработкой ksoftirqd.
• Скорость iperf3 нестабильна: один запуск близок к пропускной способности линка, следующий заметно ниже при той же схеме соединения.
• p99 задержки растёт вместе с PPS, хотя средняя загрузка канала остаётся ниже его предела.
• При всплеске новых соединений увеличиваются ListenOverflows или ListenDrops, а приложение не успевает вызывать accept.
• У приложения растёт время ответа при свободном диске и достаточном CPU, а на сетевом пути появляются потери или очередь.

Полный канал сам по себе не доказывает проблему операционной системы. Причиной может быть ограничение порта коммутатора, удалённый сервер, QoS, перегруженный гипервизор или нормальная работа сервиса с большими пакетами. Для связи симптомов с конкретными метриками пригодится практическая диагностика сетевой производительности.

Минимальный набор команд для исходного замера

Снимите baseline на рабочем узле до изменения конфигурации. Счётчики нужно смотреть дважды с интервалом, чтобы сравнивать прирост, а не накопленное значение после загрузки системы.

ip -s link show dev eth0
ethtool -S eth0
ethtool -k eth0
ss -s
nstat -az
sar -n DEV,EDEV 1 5
mpstat -P ALL 1 5
cat /proc/net/softnet_stat
grep -iE eth|ens|enp /proc/interrupts
top -H

ip -s link показывает общие RX/TX packets, bytes, errors и dropped. ethtool -S даёт расширенные счётчики NIC, их имена зависят от драйвера. ethtool -k фиксирует состояние offload-функций. ss -s показывает состояние TCP и UDP, а nstat помогает найти retransmits, ошибки установления соединений и переполнения очередей.

sar и mpstat нужны для временного ряда. Сопоставляйте секунды роста drops с загрузкой softirq на отдельных CPU. Поля /proc/net/softnet_stat зависят от версии ядра, поэтому используйте прирост значений и описание формата для конкретной системы. Набор доступных команд меняется вместе с дистрибутивом, драйвером и версией ядра.

Как сетевой стек Linux обрабатывает пакет и где возникает задержка

Входящий пакет проходит несколько очередей и контекстов выполнения. На каждом этапе могут появиться потери, ожидание или дополнительная нагрузка на CPU.

1. NIC принимает кадр и помещает его в RX ring через DMA.
2. Аппаратное прерывание сообщает о новых данных, после чего драйвер передаёт обработку механизму NAPI.
3. NAPI обрабатывает пачку пакетов в контексте NET_RX softirq, снижая количество отдельных прерываний.
4. Ядро выполняет классификацию, маршрутизацию, фильтрацию, обработку TCP или UDP и помещает данные в socket buffer.
5. Процесс приложения читает сокет, формирует ответ и передаёт его в стек исходящего трафика.
6. Qdisc, TX ring и NIC отправляют кадр в физическую или виртуальную сеть.

Разделение latency pipeline помогает различать задержку на сервере, в канале и на удалённой стороне. Такой подход применим к CPU-bound приложениям: менять нужно тот участок, который ограничивает результат измерения.

Сетевая карта, очереди RX/TX и DMA

RX ring и TX ring хранят дескрипторы буферов, которыми управляют драйвер и NIC. Hardware queues разделяют поток пакетов между каналами обработки. Число очередей и текущие размеры можно проверить так:

ethtool -g eth0
ethtool -l eth0
ethtool -x eth0

Больший RX ring выдерживает короткий всплеск, когда CPU временно не успевает за NIC. При постоянной перегрузке он лишь откладывает момент потери и увеличивает задержку. Маленькое число очередей может привести к загрузке одного CPU, а слишком большое число создаёт лишние прерывания и расходует ресурсы.

Лимит определяется всей цепочкой: скоростью NIC, шириной и поколением PCIe, NUMA-доступом к памяти, драйвером и мощностью CPU. Например, 10-гигабитный линк с минимальными Ethernet-кадрами требует обработки примерно 14,88 миллиона пакетов в секунду. Такая нагрузка заметно отличается от передачи крупных кадров по тому же каналу.

NAPI, softirq и обработка пакетов ядром

NAPI объединяет interrupt-driven обработку с polling. После первого прерывания ядро некоторое время забирает пакеты пачками, чтобы снизить overhead на каждый кадр. При высоком PPS это помогает, пока CPU успевает выполнять poll-бюджет.

Рост NET_RX softirq, занятые ksoftirqd и увеличение dropped или time squeeze в /proc/net/softnet_stat указывают на перегрузку программного этапа. При этом канал может использоваться на 30-40 процентов. Изменение MTU, RSS или RPS нужно проверять только после подтверждения такого дисбаланса.

TCP, UDP и очередь сокета приложения

TCP поддерживает порядок данных, контроль перегрузки, retransmission и адаптивное окно. UDP не выполняет повторную передачу и быстро теряет пакеты, если приложение, socket buffer или ядро не успевают их принять.

Размер окна TCP связан с bandwidth-delay product. При канале 10 Гбит/с и RTT 20 мс произведение равно примерно 25 МБ. Если максимальный receive buffer заметно меньше этого объёма, один поток может не заполнить канал даже при исправном линке. Фактическое окно зависит от RTT, congestion control, удалённой системы и поведения приложения.

Медленное чтение сокета Nginx, API-сервисом, storage-службой или агентом мониторинга создаёт очередь выше сетевого драйвера. Поэтому сетевой drop нужно сопоставлять с socket memory, состоянием процесса, числом worker-процессов и файловыми дескрипторами.

Буферы сети в серверной ОС: что настраивать и когда

Сетевые буферы находятся на разных уровнях: внутри NIC, в очередях ядра, в TCP/UDP-сокетах и в очередях приложения. Изменение одного уровня не исправляет переполнение другого.

Буферы TCP и UDP: rmem, wmem и автотюнинг

Проверьте текущие лимиты и работу TCP autotuning:

sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
sysctl net.ipv4.tcp_moderate_rcvbuf
ss -m

net.core.rmem_max и net.core.wmem_max задают максимальные размеры receive buffer и send buffer на уровне сокетов. net.ipv4.tcp_rmem и net.ipv4.tcp_wmem содержат три значения: минимум, начальное значение и максимум. В Linux TCP обычно увеличивает receive buffer по мере роста окна, если включён autotuning.

Лимит sysctl не равен фактически занятой памяти. Команда ss -m показывает memory для отдельных соединений, а число активных сокетов определяет суммарный расход RAM. Большие значения полезны для длинных потоков с большим RTT, однако для тысяч соединений они могут создать заметное давление на память.

Пример расчёта: при 1 Гбит/с и RTT 50 мс bandwidth-delay product равен примерно 6,25 МБ. Максимальный TCP receive buffer ниже этой величины может ограничить один поток. Сначала проверьте окно и throughput, затем меняйте лимит с учётом количества соединений и доступной RAM.

Для UDP проверьте, успевает ли процесс читать данные и не растёт ли receive queue. Увеличение UDP-буфера сглаживает короткий всплеск, но при постоянном избытке PPS очередь продолжит расти, пока память не закончится или пакеты не начнут отбрасываться.

Очередь входящих соединений и backlog для прокси и серверов приложений

При установлении TCP-соединения работают две связанные очереди. SYN queue хранит соединения в процессе рукопожатия, а accept queue ждёт, пока приложение вызовет accept. За верхние границы отвечают net.ipv4.tcp_max_syn_backlog и net.core.somaxconn, но итоговый backlog задаёт ещё и само приложение.

sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog
ss -lnt
nstat -az

В выводе ss -lnt для слушающего сокета Recv-Q показывает текущую очередь, а Send-Q обычно отражает её максимальный размер. Счётчики ListenOverflows и ListenDrops нужно сравнивать во времени. Высокий backlog не поможет, если приложение ограничено worker-процессами, CPU, TLS, файловыми дескрипторами или медленным upstream.

Для прокси проверьте отдельные очереди на входящем и исходящем соединении. Nginx может быстро принять клиентский запрос и ждать upstream, поэтому рост задержки на клиенте не всегда связан с входным интерфейсом.

Очереди пакетов netdev и признаки их переполнения

net.core.netdev_max_backlog задаёт размер очереди входящих пакетов ядра, когда драйвер передаёт их быстрее, чем стек успевает обработать. Это отдельный уровень, расположенный после RX ring и перед обработкой протокола.

sysctl net.core.netdev_max_backlog
cat /proc/net/softnet_stat
tc -s qdisc show dev eth0
ip -s link show dev eth0
ethtool -S eth0

Сопоставляйте прирост dropped в softnet, drops интерфейса, счётчики драйвера и статистику qdisc. Если переполняется RX ring, увеличение netdev backlog не устранит источник. Если проблема возникает в qdisc на выходе, настройка receive queue не изменит ситуацию.

Большая очередь полезна при коротких всплесках и вредна при постоянной перегрузке. Пакет, который ждёт в очереди 100 мс, формально не потерян, однако сервис уже нарушает строгий p99 SLO. Поэтому оценивайте throughput вместе с tail latency.

MTU и Jumbo Frames: как проверить путь без фрагментации

MTU задаёт максимальный размер IP-пакета или кадра на конкретном интерфейсе, в зависимости от уровня, на котором выполняется проверка. Значение должно согласовываться на всём пути: сервер, bond, bridge, VLAN, физический свитч, виртуальный свитч, туннель и удалённый узел.

Когда MTU 9000 оправдан, а когда лучше оставить 1500

MTU 9000 оправдан для крупных потоков, когда каждый участок пути подтверждён измерением. Для обычного пользовательского и API-трафика MTU 1500 часто проще поддерживать. VLAN добавляет служебные поля, а VXLAN, Geneve и WireGuard уменьшают доступный MTU внутреннего пакета на величину своих заголовков. Точное значение зависит от типа инкапсуляции и внешних адресов.

Как проверить MTU на физическом сервере, в VLAN и виртуальной сети

Начните с фактических значений интерфейсов:

ip link show dev eth0
ip -d link show dev vlan100
ip link show master br0
tracepath -n server-ip

Для IPv4 при MTU 1500 проверяйте payload 1472 байта, потому что к нему добавляются 20 байт IP-заголовка и 8 байт ICMP. Для MTU 9000 используйте payload 8972:

ping -4 -M do -s 1472 -c 3 server-ip
ping -4 -M do -s 8972 -c 3 server-ip
ping -6 -M do -s 1452 -c 3 server-ip

В IPv6 маршрутизатор не фрагментирует пакет, поэтому проверка Path MTU особенно зависит от ICMPv6 Packet Too Big. Команда tracepath может показать обнаруженное PMTU, но результат нужно сопоставить с интерфейсами и настройками туннеля.

Изменяйте MTU после проверки всего сегмента. Команда ip link set dev eth0 mtu 9000 меняет состояние интерфейса сразу и может оборвать соединения. Сначала проверьте тестовый узел, затем bond, bridge, VLAN, виртуальный свитч и удалённую сторону. Один успешный ping не подтверждает качество большого потока.

Offload-функции сетевой карты: TSO, GRO, GSO и checksum offload

Offload переносит часть работы на NIC или объединяет обработку пакетов в ядре. В физической инфраструктуре эти функции часто снижают нагрузку на CPU. Отключать их без воспроизводимого симптома не следует.

Какие offload-функции влияют на CPU, PPS и захват трафика

При включённых TSO, GSO или GRO tcpdump на хосте может показывать крупный сегмент, который NIC позднее разделит, или контрольную сумму, ещё не рассчитанную аппаратным блоком. Такой вывод не доказывает повреждение пакета в сети.

Для маршрутизатора, моста, DPDK-приложения, виртуального коммутатора или проблемного драйвера поведение offload может отличаться. Проверяйте функции командой:

ethtool -k eth0

Как тестировать изменение offload без риска для рабочего сервиса

1. Сохраните исходное состояние: ethtool -k eth0.
2. Выберите один параметр, например GRO, и зафиксируйте причину проверки.
3. Измените его на тестовом узле или в согласованное окно: ethtool -K eth0 gro off.
4. Повторите тот же тест iperf3, нагрузку приложения или захват трафика.
5. Сравните throughput, p99, CPU softirq, drops, retransmits и ошибки NIC.
6. Верните исходное значение, если измеримого улучшения нет или появилась регрессия.

TSO, GRO, GSO и checksum offload проверяйте по одному. Результат зависит от размера пакета, числа потоков, драйвера и того, работает ли узел как конечный сервер, маршрутизатор или виртуальный сетевой элемент. Виртуальный интерфейс может показывать функции, которые фактически зависят от возможностей физического хоста.

Прерывания, RSS, RPS и XPS: распределение сетевой нагрузки по CPU

Сетевой процессинг становится CPU-узким местом, когда один или несколько CPU получают большую часть IRQ и NET_RX softirq. Свободные ядра рядом с перегруженным CPU в такой ситуации не дают автоматического прироста скорости.

Как обнаружить дисбаланс прерываний и NET_RX softirq

grep -iE eth|ens|enp /proc/interrupts
mpstat -P ALL 1 5
cat /proc/net/softnet_stat
ethtool -l eth0
ethtool -x eth0

Счётчики в /proc/interrupts должны распределяться по ожидаемому числу очередей. Если одна очередь получает почти весь поток, проверьте RSS и affinity IRQ. В mpstat ищите CPU с высокой долей %soft, а в top или htop наблюдайте ksoftirqd.

В /proc/net/softnet_stat сравнивайте dropped и time squeeze между замерами. Рост time squeeze означает, что обработка не укладывается в доступный контекст NAPI. Это повод проверить PPS, размер пакетов, число очередей, RSS и конкуренцию за CPU.

RSS, RPS и XPS: выбор механизма для физического сервера и VPS

RSS распределяет входящие потоки по аппаратным очередям NIC на основе хеша. Это основной механизм для физического сервера, если карта предоставляет нужное число очередей.

RPS переносит выбор CPU в программный уровень. Он помогает, когда аппаратных очередей мало, но добавляет межъядерную передачу и нагрузку на кэш. Включать RPS на всех CPU без замера не следует.

XPS выбирает CPU и очередь для исходящих пакетов. Его настройка может улучшить локальность обработки при большом числе потоков, однако неправильная маска создаёт дисбаланс.

На VPS число virtio-net queues, доступные IRQ и CPU affinity задаёт гипервизор. Гостевая ОС не сможет создать аппаратные очереди, которых ей не выдали. В контейнере сетевой путь дополнительно проходит через veth, bridge, OVS или CNI-плагин, поэтому счётчики физического интерфейса и pod могут показывать разные уровни потерь.

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

На многосокетном сервере NIC подключена к конкретному PCIe и NUMA-узлу. Если IRQ, память и процесс приложения находятся на разных узлах, растёт стоимость обращения к удалённой памяти и ухудшается локальность кэша.

cat /sys/class/net/eth0/device/numa_node
lscpu -e=CPU,NODE
numactl --hardware

Сопоставьте NUMA-узел NIC, CPU для IRQ и CPU, где работают worker-процессы приложения. Проверяйте это только после фиксации дисбаланса. Ручная привязка IRQ, RSS и процессов переносится между серверами лишь после сверки топологии. irqbalance может конфликтовать с ручными масками, поэтому выбранную схему нужно документировать и проверять после перезагрузки.

Как отличить проблему ОС от ограничений сетевого оборудования и виртуализации

Одинаковый симптом, например низкая скорость, появляется при разных причинах. Linux может корректно обрабатывать пакеты, пока порт коммутатора ограничен 1 Гбит/с, гипервизор забирает CPU или удалённый узел не успевает отправлять данные.

Признаки проблемы на уровне NIC, драйвера, PCIe и коммутатора

ethtool eth0
ethtool -i eth0
ethtool -S eth0
lspci -vv
journalctl -k

• CRC, alignment и symbol errors: ищите кабель, оптику, порт или несовместимый transceiver.
• Carrier changes: проверяйте физический линк, питание и согласование скорости.
• Missed, no buffer и reset: сопоставляйте состояние драйвера, RX ring, firmware и загрузку CPU.
• Неверная скорость или дуплекс: сравнивайте вывод сервера с настройкой порта коммутатора.
• PCIe errors или малое число lanes: проверяйте слот, поколение PCIe и сообщения ядра.
• Ошибки только на одном направлении: снимайте статистику на обеих сторонах линка, включая порт коммутатора.

Счётчики ethtool -S зависят от производителя, поэтому ориентируйтесь на их прирост во время теста. Если CRC увеличивается на коммутаторе и сервере, настройка sysctl не устранит физическую причину. Если ошибки отсутствуют, а CPU steal высок, проверяйте виртуальную среду.

Особенности виртуальных машин, VPS и контейнерных сетей

В виртуальной машине путь пакета проходит через virtio-net, vCPU и виртуальный свитч. При перегрузке физического хоста гостевая ОС получает меньше процессорного времени. В mpstat это проявляется ростом %steal. Причиной могут быть oversubscription, лимит vCPU, ограничение виртуального порта, bridge, OVS или фильтрация на хосте.

SR-IOV может передать виртуальной машине отдельную virtual function и сократить путь через виртуальный свитч. Это требует поддержки NIC, BIOS/UEFI, гипервизора и политики провайдера. Настройка гостевых IRQ не исправит ограничение канала или перегруженный физический хост.

В Kubernetes overlay-сети добавляют заголовки VXLAN или Geneve. Ошибка в расчёте внутреннего MTU приводит к фрагментации, drops или соединениям, которые зависают только при передаче крупных сообщений. Проверяйте pod-to-pod путь, физический интерфейс узла и настройки CNI отдельно.

Для отдельного тестового стенда можно использовать облачную инфраструктуру Timeweb Cloud, сравнивая одинаковый профиль нагрузки на VDS. Такой тест показывает поведение выбранной конфигурации, но не заменяет проверку рабочего гипервизора и удалённой сети.

Когда проверять BIOS/UEFI и настройки платформы

BIOS/UEFI проверяйте после прикладного, сетевого и виртуального уровней, если симптомы указывают на платформу. Ищите актуальную прошивку NIC, корректное состояние PCIe, настройки энергосбережения CPU и ограничения слота. У серверов с высокой PPS задержка может меняться при агрессивном управлении частотой CPU, но изменение режима питания нужно подтверждать повторным тестом.

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

Пошаговый порядок настройки сети на сервере под высокой нагрузкой

Настройка должна начинаться с SLO и заканчиваться сравнением метрик. Максимальная цифра в iperf3 не считается успехом, если p99 сервиса вырос, появились retransmits или сервер потерял запас CPU.

Пример плана проверки для Nginx, API-сервера и системы хранения

Nginx и API. Зафиксируйте requests per second, новые и активные соединения, p50/p95/p99, accept queue, retransmits, TLS CPU и время ответа upstream. Проверьте ss -lnt, nstat -az, количество worker-процессов и файловые дескрипторы. При всплеске новых соединений сначала ищите переполнение SYN или accept queue. При высокой задержке существующих keepalive-соединений ищите upstream, CPU и socket buffers.

Система хранения. Измерьте пропускную способность крупного последовательного потока, задержку операций, drops, ошибки линка, распределение IRQ и загрузку CPU. Затем проверьте MTU на каждом участке, включая VLAN, bond, bridge и overlay. Большой MTU имеет смысл только при согласованной конфигурации всего пути и устойчивом результате теста.

Kubernetes east-west. Сравните задержку между pod на одном узле и на разных узлах. Рост разницы указывает на overlay, физическую сеть, CNI, conntrack или удалённый CPU. Проверяйте MTU внутреннего интерфейса и реальный PPS, потому что средняя пропускная способность может выглядеть нормально при плохом p99.

Для общего алгоритма поиска узких мест в Linux пригодится руководство по мониторингу CPU, памяти, диска и сети.

Как оформить изменения sysctl, ethtool и IRQ affinity

Храните настройки в системе управления конфигурацией вместе с версией ядра, драйвера, firmware и описанием профиля нагрузки. Для sysctl можно использовать отдельный файл, например /etc/sysctl.d/90-network-profile.conf. Числа ниже показывают формат записи после замеров, они не подходят как универсальная конфигурация.

# пример профиля после измерений, значения буферов указаны в байтах
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 131072 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 4096

Каждая строка должна иметь причину: высокий BDP, переполнение accept queue, drops в softnet или конкретный профиль соединений. Применяйте файл командой sysctl --system, затем проверьте фактические значения и повторите нагрузочный тест.

Для временного теста NIC используют команды вроде ethtool -K eth0 gro off и ethtool -G eth0 rx 4096 tx 4096, если драйвер поддерживает такие параметры. Привязку IRQ проверяйте через /proc/irq/IRQ/smp_affinity_list. Ручные маски нужно задавать через управляемую конфигурацию, чтобы они сохранялись после перезагрузки и замены NIC.

Rollback должен возвращать прежние значения sysctl, offload, размеров ring и affinity. Сохраняйте baseline перед каждой серией тестов. После обновления ядра, драйвера, гипервизора, CNI или смены типа нагрузки повторяйте проверку, даже если конфигурационные файлы не менялись.

Практические примеры настройки Linux под разные серверные профили собраны в руководстве по настройке Linux-серверов для DevOps.

Чек-лист: что проверить при низкой сетевой производительности Linux-сервера

1. Опишите профиль нагрузки: TCP или UDP, размер сообщений, PPS, число соединений, длительность потоков и целевой SLO.
2. Снимите baseline: throughput, p50/p95/p99, retransmits, drops, errors, CPU, softirq и CPU steal.
3. Проверьте скорость и дуплекс линка, CRC, carrier changes, firmware, драйвер и статистику порта коммутатора.
4. Сравните результат iperf3 между конкретными узлами в прямом и обратном направлении.
5. Проверьте RX/TX ring, число hardware queues, RSS и распределение IRQ по CPU.
6. Сопоставьте drops NIC, интерфейса, softnet, qdisc и socket queue, чтобы определить уровень переполнения.
7. Проверьте TCP и UDP buffers, autotuning, somaxconn, tcp_max_syn_backlog и backlog приложения.
8. Проверьте MTU всего пути, включая VLAN, bond, bridge, VXLAN, Geneve, WireGuard и виртуальный свитч.
9. Сравните работу с включёнными offload и после изменения одной функции, сохраняя исходную конфигурацию.
10. Исключите vCPU limit, CPU steal, oversubscription, NUMA-дисбаланс, ограничения SR-IOV, NIC, PCIe и BIOS/UEFI.

Не переносите значения sysctl, размеры ring или CPU affinity из чужого окружения без baseline и плана отката. Рабочий результат подтверждается повторяемым тестом и стабильными метриками сервиса, а не одним высоким показателем пропускной способности.