Jump to content
Калькуляторы

Высокий native_queued_spin_lock_slowpath

Экспериментирую с трафиком на стареньком 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 by zervu1boris

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by z1boris

Share this post


Link to post
Share on other sites
22 часа назад, z1boris сказал:

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this