Перейти к содержимому
Калькуляторы

Распределение нагрузки по ядрам в 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).

 

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

 

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

Изменено пользователем pavel.odintsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так, еще совет 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 >

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, целевой - адрес машины. А смысл этой темы?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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

 

Изменено пользователем mirk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

http://forum.nag.ru/forum/index.php?showtopic=59217

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

[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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что за трафик?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Видимо, надо дрессировать хэш сетевой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Man ethtool: rx-flow-hash

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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)

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.