У нас есть сервер Debian с одной ссылкой на внутреннюю VLAN и одну на внешнюю — оба подключаются напрямую к одному коммутатору.
На обеих ссылках мы периодически наблюдаем необычно большое количество событий неправильного приема, а также высокую задержку.
Таблица интерфейса ядра
Iface MTU соответствует RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
ethA 1500 0 884347583 0 49965509 49965509 1697514631 0 0 0 БМРУ
ethB 1500 0 1611102819 0 77615811 77615811 819321274 0 0 0 БМРУ
Мы также видим, что процессы ksoftirqd для обоих интерфейсов в большинстве случаев работают на уровне 90+%, даже когда якобы все должно быть тихо.
44 корень 20 0 0 0 0 R 98.8 0.0 2557:46 ksoftirqd/3
51 корень 20 0 0 0 0 R 85,6 0,0 2722:33 ksoftirqd/5
Насколько я понимаю, это означает, что сервер максимально использует назначенный ЦП для обработки всех пакетов, поступающих на этот интерфейс. Но даже когда мы видим входящие ~ 50 Мбит / с (и те же серверы обрабатывают> 800 Мбит / с), эти процессы могут достигать максимума, а количество RX-DRP резко возрастает. irqbalance работает, и /proc/interrupts подтверждает, что эти процессоры не заняты обработкой чего-либо еще.
Есть ли явные потенциальные причины для этого?
Поможет ли назначение нескольких процессоров (через smp_affinity) для обработки прерываний для этих интерфейсов? Я не могу найти ни одного примера, когда кто-то назначает несколько процессоров одному сетевому интерфейсу, поэтому в лучшем случае это кажется нетрадиционным, а в худшем - достойным взлома системы.
Некоторое время это вызывало проблемы в производстве, поэтому я с радостью приму любой потенциальный обходной путь.
