Высокий native_queued_spin_lock_slowpath

[Morty]

Экспериментирую с трафиком на стареньком Dell сервере.
Характеристики: 4 камня X7560 8 x 2.27, 2 x intel x520, centos 7 (kernel 3.10.0)
На сервере настроено только несколько vlan`ов и несколько маршрутов.
 

eth0 - первый порт первой сетевой (внешка)
eth3 - первый порт второй сетевой (локалка)
 

Схема: внешка <---> eth0 <---> server <---> eth3 <---> client1 (vlan10), client2 (vlan20), client3 (vlan30)
 

Ограничиваю на eth0 и eth3 количество очередей до количества ядер процессоров (до 8)
Привязываю очереди eth0 к numa 1.
Привязываю очереди eth3 к numa 2.
 

Тест 1:
На client1 качаю файл с внешки со скоростью ~ 2 гбит/сек
Нагрузка на процессор 0%
native_queued_spin_lock_slowpath растёт до 60%
Одновременно запускаю пинг между client2 и client3 = ~ 1-2 мс
 

Привязываю очереди eth0 и eth3 к numa 1
 

Тест 2:
На client1 качаю файл с внешки со скоростью ~ 2 гбит/сек
Нагрузка на процессор 0%
native_queued_spin_lock_slowpath около 5%
Пинг между client2 и client3 = 0.3 мс

Почему, когда привязываю очереди разных физическиих сетевых к разным numa, сильно растёт native_queued_spin_lock_slowpath и увеличивается пинг?
Читал на хабре статью "Тюнинг сетевого стека Linux для ленивых", где пишут: "Отдельные NUMA-ноды не будут полезны, если трафик приходит в порты одной сетевой карты". В моём случае трафик приходит в порты разных сетевых. Но при этом наоборот наблюдается ухудшение.
 

numactl --hardware:

available: 4 nodes (0-3)
node 0 cpus: 0 4 8 12 16 20 24 28
node 0 size: 7816 MB
node 0 free: 4543 MB
node 1 cpus: 1 5 9 13 17 21 25 29
node 1 size: 8046 MB
node 1 free: 7554 MB
node 2 cpus: 2 6 10 14 18 22 26 30
node 2 size: 8062 MB
node 2 free: 7757 MB
node 3 cpus: 3 7 11 15 19 23 27 31
node 3 size: 8062 MB
node 3 free: 7890 MB
node distances:
node   0   1   2   3
  0:  10  20  20  20
  1:  20  10  20  20
  2:  20  20  10  20
  3:  20  20  20  10

ethtool -g:

RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096

 

ethtool -l:

RX:             0
TX:             0
Other:          1
Combined:       8

ethtool -c:

Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 0
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 256

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

 

Edited August 31, 2021 by zervu1boris

[NiTr0]

там 4 NUMA, и 2 IO кластера (каждый IO hub, у которого pci-e слоты, подключен к 2 камням напрямую). потому надо разбраться что куда воткнуто. ну и по идее если прерывания сетевухи раскидать по обеим камням одного  IO кластера, хуже быть не должно.

 

в идеале конечно замирорить бы память всех нума нод (все равно ее там дофига для роутинга будет), чтобы роутинг таблицы и т.п. дублировались - но я не встречал реализации подобного финта.

[Morty]

Про IO кластеры ничего не знаю, почитаю литературу, попробую разобраться.

Пока что проблема решилась выставлением профиля tuned-adm profile_info network-latency.
native_queued_spin_lock_slowpath теперь показывает 0%, пинг упал до 0.3 мс.
При этом нагрузка на CPU выросла до 10-15%.
До этого стоял профиль balanced.

Раньше ничего про tuned не знал. И пока не понимаю что он оптимизирует...

Edited September 2, 2021 by z1boris

[NiTr0]

22 часа назад, z1boris сказал:

Про IO кластеры ничего не знаю, почитаю литературу, попробую разобраться.

там 4 камня, каждая пара камней подключена к своему чипсету (подобно s1366), который уже делает pci-e линии.