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

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

Упираются в процессор, а потом меняют только MTU и надеждами закрывают инцидент. Анализ показал, что узкие места чаще сидят в трех слоях: количество прерываний, размер очередей и стоимость копирования пакетов между ядром и приложением.

Рассмотрим архитектурный срез по данному узлу:
— на прием: проверьте балансировку IRQ и RPS, иначе один CPU обрабатывает весь поток;
— на передачу: оцените backlog и qdisc, там часто копятся задержки;
— в приложении: сократите число syscalls, используйте batch-обработку и zero-copy, если стек это поддерживает;
— на уровне TCP: смотрите окно приема, retransmits и долю мелких пакетов, они быстро съедают пропускную способность.

Данные подтверждают следующую корреляцию: чем выше pps при умеренном bitrate, тем раньше проявляется деградация. Это типичный случай для сервисов с большим числом коротких соединений, где лимит определяется не каналом, а стоимостью обработки каждого пакета.

Рекомендуется обратить внимание на метрику softirq, долю dropped и latency очереди на NIC. Если рост задержки начинается раньше насыщения линка, проблема почти всегда в конфигурации стека, а не в магистрали.