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

Распределение нагрузки по ядрам в Debian Jessie Лезем вглубь! Интересный и развернутый спич

Всем хай!

 

Очередная неведомая фигня :)

 

Есть машина на Debian Jessie (3/16), с процом i7 3820 (4 физических ядра, каждое по 2 логических) с сетевой Intel 82599 дрова самые последние с сайта Intel 4.0.3, режим модуля:

options ixgbe RSS=8,8 IntMode=2,2 MQ=1,1 VMDQ=0,0 allow_unsupported_sfp=1,1

 

Задача машины - просто принять этот трафик к обработке, ни роутинга, ни правил iptables, ничего нету.

 

На машину вливается силами MoonGen 2mpps/1300 мегабит мелкозернистого tcp флуда с выставленным syn флагом, порт с которого льется - статичен (1024), на который льется - тоже статичен (80), целевой адрес - также статичен, а вот source адрес равномерно растет и в каждом пакете свой. Contracking _точно_ отрублен.

 

Прерывания каждой из 8ми очередей насмерть прибиты к логически ядрам скриптом: https://gist.github.com/pavel-odintsov/59f887e945f2858a320f в процессе тестов также пробовал birq для балансировки прерываний, не помогло.

 

Выдача top:

%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 56.3 id,  0.0 wa,  0.0 hi, 43.0 si,  0.4 st
 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                              
  34 root      20   0       0      0      0 S  81.8  0.0  10:28.16 ksoftirqd/5                                                                          
  19 root      20   0       0      0      0 S  13.6  0.0  11:19.03 ksoftirqd/2                                                                          
   3 root      20   0       0      0      0 R   4.0  0.0  10:32.16 ksoftirqd/0                                                                          
  13 root      20   0       0      0      0 S   0.7  0.0  10:22.27 ksoftirqd/1                                                                          
  24 root      20   0       0      0      0 S   0.7  0.0   9:26.76 ksoftirqd/3                                                                          
  39 root      20   0       0      0      0 S   0.7  0.0  10:47.72 ksoftirqd/6                                                                          
  40 root      20   0       0      0      0 S   0.7  0.0   0:10.02 kworker/6:0                                                                          
1320 root      20   0   25704   2976   2504 R   0.7  0.0   0:00.10 top                                                                                  
  29 root      20   0       0      0      0 S   0.3  0.0  10:13.63 ksoftirqd/4                                                                          
  35 root      20   0       0      0      0 S   0.3  0.0   0:02.11 kworker/5:0                                                                          
  44 root      20   0       0      0      0 S   0.3  0.0  10:44.67 ksoftirqd/7   

 

Выдача mpstat:

mpstat -P ALL 1
Linux 3.16.0-4-amd64 (debian) 	06/01/2015 	_x86_64_	(8 CPU)

05:55:40 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:55:41 PM  all    0.00    0.00    0.00    0.00    0.00   43.45    0.37    0.00    0.00   56.18
05:55:41 PM    0    0.00    0.00    0.00    0.00    0.00    4.55    0.00    0.00    0.00   95.45
05:55:41 PM    1    0.00    0.00    0.00    0.00    0.00   26.67    0.00    0.00    0.00   73.33
05:55:41 PM    2    0.00    0.00    4.17    0.00    0.00   16.67    0.00    0.00    0.00   79.17
05:55:41 PM    3    0.00    0.00    0.00    0.00    0.00   69.23    1.92    0.00    0.00   28.85
05:55:41 PM    4    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:41 PM    5    0.00    0.00    0.00    0.00    0.00   90.14    0.00    0.00    0.00    9.86
05:55:41 PM    6    0.00    0.00    0.00    0.00    0.00    8.00    4.00    0.00    0.00   88.00
05:55:41 PM    7    0.00    0.00    0.00    0.00    0.00    4.00    4.00    0.00    0.00   92.00

05:55:41 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:55:42 PM  all    0.00    0.00    0.00    0.00    0.00   42.19    0.39    0.00    0.00   57.42
05:55:42 PM    0    0.00    0.00    0.00    0.00    0.00    4.55    0.00    0.00    0.00   95.45
05:55:42 PM    1    0.00    0.00    0.00    0.00    0.00   25.00    0.00    0.00    0.00   75.00
05:55:42 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:42 PM    3    0.00    0.00    0.00    0.00    0.00   87.50    0.00    0.00    0.00   12.50
05:55:42 PM    4    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:42 PM    5    0.00    0.00    0.00    0.00    0.00   71.43    0.00    0.00    0.00   28.57
05:55:42 PM    6    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:42 PM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

05:55:42 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:55:43 PM  all    0.00    0.00    0.00    0.00    0.00   43.94    0.38    0.00    0.00   55.68
05:55:43 PM    0    0.00    0.00    0.00    0.00    0.00    4.55    0.00    0.00    0.00   95.45
05:55:43 PM    1    0.00    0.00    0.00    0.00    0.00   35.29    2.94    0.00    0.00   61.76
05:55:43 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:43 PM    3    0.00    0.00    0.00    0.00    0.00   18.52    0.00    0.00    0.00   81.48
05:55:43 PM    4    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:55:43 PM    5    0.00    0.00    0.00    0.00    0.00   99.00    0.00    0.00    0.00    1.00
05:55:43 PM    6    0.00    0.00    0.00    0.00    0.00    4.55    0.00    0.00    0.00   95.45
05:55:43 PM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

 

Выдача htop:

1  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||91.6%]     5  [                                                               0.0%]
 2  [|||||||||||||||||||||                                         28.6%]     6  [||                                                             2.1%]
 3  [||||||||||||||||||||||||||||||||||||||||||                    62.2%]     7  [|||||||||||||||||||||||                                       33.3%]
 4  [                                                               0.0%]     8  [                                                               0.0%]
 Swp[                                                   

 

Были подозрения, что виноват RSS хэш на сетевой, но они были напрасны - трафик разливается по 8 очередям идеально равномерно:

ethtool -S eth5|egrep '.x_queue_[01234567]_(bytes|packets)'

tx_queue_0_packets: 13575162
    tx_queue_0_bytes: 733041048
    tx_queue_1_packets: 13574584
    tx_queue_1_bytes: 733018164
    tx_queue_2_packets: 13573119
    tx_queue_2_bytes: 732945066
    tx_queue_3_packets: 13574776
    tx_queue_3_bytes: 733029192
    tx_queue_4_packets: 13573828
    tx_queue_4_bytes: 732984024
    tx_queue_5_packets: 13574399
    tx_queue_5_bytes: 733002126
    tx_queue_6_packets: 13573080
    tx_queue_6_bytes: 732942972
    tx_queue_7_packets: 13573647
    tx_queue_7_bytes: 732974466
    rx_queue_0_packets: 13574614
    rx_queue_0_bytes: 814477674
    rx_queue_1_packets: 13575147
    rx_queue_1_bytes: 814508820
    rx_queue_2_packets: 13575145
    rx_queue_2_bytes: 814508700
    rx_queue_3_packets: 13575142
    rx_queue_3_bytes: 814508520
    rx_queue_4_packets: 13575143
    rx_queue_4_bytes: 814508580
    rx_queue_5_packets: 13575150
    rx_queue_5_bytes: 814509000
    rx_queue_6_packets: 13575147
    rx_queue_6_bytes: 814508820
    rx_queue_7_packets: 13575153
    rx_queue_7_bytes: 814509180

 

Как можно заметить - ядра прогружаются АБСОЛЮТНО неравномерно, что приводит к тому, что часть ядра в полку, а часть простаивает (причем, "часть" - не половина, когда 3, когда 5).

 

Почему такое может быть? Как добиться равномерной нагрузки на ядра?

 

Обращаю внимание, что данный порт никто не слушает. Про локи на листене наслышан, как решать знаю, но пока до этого далеко.

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Попробуйте ethtool -K IFACE ntuple on

Share this post


Link to post
Share on other sites

Попробуйте ethtool -K IFACE ntuple on

 

Неа, так и размазывается некорректно =(

 

Есть подозрения, что виноват стек tcp, так как на каждый пакет флуда он отвечает rst/ack пакетом, возможно, как раз это вызывает довольно неравномерную нагрузку ядер.

Share this post


Link to post
Share on other sites

perf top выглядит вот так:

Samples: 4M of event 'cpu-clock', Event count (approx.): 93331850482
  3.51%  [ip_tables]       [k] ipt_do_table
  2.78%  [kernel]          [k] _raw_spin_lock_bh
  2.56%  [kernel]          [k] _raw_spin_lock
  2.06%  [kernel]          [k] nf_iterate
  1.89%  [kernel]          [k] fib_table_lookup
  1.80%  [kernel]          [k] _raw_spin_unlock_irqrestore
  1.66%  [kernel]          [k] __inet_lookup_established
  1.49%  [kernel]          [k] tcp_v4_send_reset
  1.45%  [kernel]          [k] __ip_route_output_key
  1.40%  [kernel]          [k] pvclock_clocksource_read
  1.39%  [kernel]          [k] fib_get_table
  1.23%  [kernel]          [k] __ip_append_data.isra.44
  1.22%  [kernel]          [k] __alloc_skb
  1.16%  [kernel]          [k] check_leaf.isra.6
  1.10%  [kernel]          [k] fib_rules_lookup
  1.09%  [kernel]          [k] kfree
  1.09%  [kernel]          [k] kmem_cache_free
  1.06%  [kernel]          [k] ip_finish_output
  1.05%  [kernel]          [k] __local_bh_enable_ip
  0.97%  [kernel]          [k] ip_rcv
  0.94%  [kernel]          [k] __kmalloc
  0.91%  [kernel]          [k] kmem_cache_alloc
  0.90%  [kernel]          [k] __netif_receive_skb_core
  0.89%  [kernel]          [k] skb_release_head_state
  0.88%  [kernel]          [k] sock_wmalloc
  0.85%  [kernel]          [k] kmem_cache_alloc_node
  0.85%  [kernel]          [k] tcp_v4_rcv

Share this post


Link to post
Share on other sites

Так, еще совет on nuclear cat:

 

 

echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-1/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-2/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-3/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-4/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-5/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-6/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-7/rps_cpusпопробуйтолько echo ff >

 

Share this post


Link to post
Share on other sites
На машину вливается силами MoonGen 2mpps/1300 мегабит мелкозернистого tcp флуда с выставленным syn флагом, порт с которого льется - статичен (1024), на который льется - тоже статичен (80), целевой адрес - также статичен, а вот source адрес равномерно растет и в каждом пакете свой. Contracking _точно_ отрублен.

Целевой адрес - это адрес машины? Если нет можно попробовать хак со static arp, прописать статическую запись для какого либо адреса и добавить маршрут к целевому адресу через статически добавленный.

Share this post


Link to post
Share on other sites

а подскажите что делают данные команды

 

 

echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-1/rps_cpus...

 

Edited by mirk

Share this post


Link to post
Share on other sites

Скомпилируйте из исходников свежий irqbalance и установите. smp_affinity верните на место. Все будет хорошо.

Share this post


Link to post
Share on other sites

birq делает тоже самое, но с головой=) birq был написан после многократных попыток автора перехачить irqbalance и выпилить его баги :)

Share this post


Link to post
Share on other sites

pppoetest, pavel.odintsov, мне помог в полностью аналогичной ситуации irqbalance. birq не пробовал, ТС пишет, что не помогло.

Share this post


Link to post
Share on other sites

Здравствуйте, у меня несколько похожая ситуация, только проблема в том, что очереди на самой сетевой заполняются неравномерно:

[root@gate1 ~]# ethtool -S eth0 | grep .x_queue_._packets
    tx_queue_0_packets: 3935638
    tx_queue_1_packets: 16494548
    tx_queue_2_packets: 6202492
    tx_queue_3_packets: 4716926
    rx_queue_0_packets: 15137120
    rx_queue_1_packets: 15710723
    rx_queue_2_packets: 12747105
    rx_queue_3_packets: 18412661
[root@gate1 ~]# ethtool -S eth1 | grep .x_queue_._packets
    tx_queue_0_packets: 4846485
    tx_queue_1_packets: 19860240
    tx_queue_2_packets: 3191876
    tx_queue_3_packets: 8580041
    rx_queue_0_packets: 2776597
    rx_queue_1_packets: 1980039
    rx_queue_2_packets: 2801323
    rx_queue_3_packets: 1903913

Подскажите пожалуйста, куда смотреть?

Share this post


Link to post
Share on other sites

Интерфейсы в бондинге с вланами, клиентский трафик натится на внешний IP, установленный на одном из вланов.

Edited by SABRE

Share this post


Link to post
Share on other sites

А есть ссылка на почитать? Или пример?

Share this post


Link to post
Share on other sites

Я так понимаю 82576 это не умеет?

ethtool -n eth0
4 RX rings available
rxclass: Cannot get RX class rule count: Operation not supported
RX classification rule retrieval failed

Edited by SABRE

Share this post


Link to post
Share on other sites

driver: igb
version: 5.2.18
firmware-version: 1.0.1
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

lspci

03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

Edited by SABRE

Share this post


Link to post
Share on other sites

Отсутствие распределения по ядрам никак не связано с настройками сетевой карты. Конечно, полезно ее настроить, но проблему надо решать другим путем.

Share this post


Link to post
Share on other sites

SABRE а как у вас раскиданы очереди по ядрам?

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