<b>Почему сетевой стек тормозит раньше канала: чек-лист для поиска узкого места</b>

<b>Почему сетевой стек тормозит раньше канала: чек-лист для поиска узкого места</b>

Производительность сети часто упирается не в пропускную способность, а в стек обработки пакетов: очередь прерываний, планировщик, буферы сокетов, копирования между ядром и пользователем. Анализ показал, что при одинаковом линке два узла могут давать разную задержку из-за настроек RSS, RPS и размера очередей.

Рассмотрим архитектурный срез по данному узлу. Проверять стоит по порядку:
— загрузку CPU по softirq и ksoftirqd;
— дропы на уровне NIC, qdisc и сокета;
— рост retransmit и out-of-order;
— размер receive/send buffer и лимиты sysctl;
— распределение IRQ по ядрам и наличие affinity.

Если потоков много, а ядро одно, стек начинает конкурировать сам с собой. Тогда помогает не «ускорение» в целом, а развязка горячих точек: вынос IRQ на отдельные ядра, включение многопоточности обработки, настройка batch-пакетов и отказ от лишних копирований там, где это допустимо.

Рекомендуется обратить внимание на метрику p99 задержки, а не только на среднее значение. Среднее маскирует очереди, которые появляются при всплесках трафика и потом долго не рассасываются. Данные подтверждают следующую корреляцию: чем выше локальная конкуренция за CPU, тем хуже ведет себя стек даже при запасе по сети.

Если смотреть на стек как на конвейер, а не на «черный ящик», узкое место обычно находится быстро. Сначала снимаем метрики, потом меняем один параметр за раз и проверяем, исчез ли дроп или хвост задержки.