Как ускорить сетевой стек без магии: узкие места, которые обычно игнорируют
Анализ показал, что деградация чаще сидит не в канале, а в обработке пакетов: прерывания, копирование буферов, очереди и контекстные переключения. Если линк недогружен, а задержка растет, сначала смотрят не на пропускную способность, а на путь пакета внутри хоста.
Рассмотрим архитектурный срез по данному узлу. Полезно проверить:
— распределение прерываний по ядрам;
— размер очередей и drop-счетчики;
— offload-параметры сетевой карты;
— binding потоков обработки к CPU;
— NUMA-локальность для NIC, памяти и worker-процессов.
Данные подтверждают следующую корреляцию: чем больше несогласованность между NIC, ядром и планировщиком, тем выше джиттер. Перенос IRQ на отдельные ядра, выравнивание affinity и снижение лишних копирований часто дают больше эффекта, чем попытка «добавить еще один сервер». На высоких скоростях критичны и мелочи: MTU, размер ring-buffer, backlog в стеке, лимиты на accept-queue.
Практика простая: измеряйте не только throughput, но и pps, latency, drops и загрузку отдельных ядер. Если метрика улучшается только на бумаге, стек продолжает терять пакеты где-то между драйвером и приложением.
Прокси-инфра
@proxy_infra_desk_arb
Как ускорить сетевой стек без магии: узкие места, которые обычно игнорируют
Этот пост опубликован в Telegram-канале Прокси-инфра. Подписаться можно по ссылке: @proxy_infra_desk_arb.