pavel.odintsov Опубликовано 1 июня, 2015 (изменено) · Жалоба Всем хай! Очередная неведомая фигня :) Есть машина на 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). Почему такое может быть? Как добиться равномерной нагрузки на ядра? Обращаю внимание, что данный порт никто не слушает. Про локи на листене наслышан, как решать знаю, но пока до этого далеко. Изменено 2 июня, 2015 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anix Опубликовано 2 июня, 2015 · Жалоба Попробуйте ethtool -K IFACE ntuple on Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 июня, 2015 · Жалоба Попробуйте ethtool -K IFACE ntuple on Неа, так и размазывается некорректно =( Есть подозрения, что виноват стек tcp, так как на каждый пакет флуда он отвечает rst/ack пакетом, возможно, как раз это вызывает довольно неравномерную нагрузку ядер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 июня, 2015 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 2 июня, 2015 · Жалоба Так, еще совет 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 > Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anix Опубликовано 3 июня, 2015 · Жалоба На машину вливается силами MoonGen 2mpps/1300 мегабит мелкозернистого tcp флуда с выставленным syn флагом, порт с которого льется - статичен (1024), на который льется - тоже статичен (80), целевой адрес - также статичен, а вот source адрес равномерно растет и в каждом пакете свой. Contracking _точно_ отрублен. Целевой адрес - это адрес машины? Если нет можно попробовать хак со static arp, прописать статическую запись для какого либо адреса и добавить маршрут к целевому адресу через статически добавленный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 3 июня, 2015 · Жалоба Да, целевой - адрес машины. А смысл этой темы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mirk Опубликовано 4 июня, 2015 (изменено) · Жалоба а подскажите что делают данные команды echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-1/rps_cpus... Изменено 4 июня, 2015 пользователем mirk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 июня, 2015 · Жалоба https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-rps.html Тут неплохо расписано Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nu11 Опубликовано 5 июня, 2015 · Жалоба Скомпилируйте из исходников свежий irqbalance и установите. smp_affinity верните на место. Все будет хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 5 июня, 2015 · Жалоба irqbalance - кака. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 5 июня, 2015 · Жалоба birq делает тоже самое, но с головой=) birq был написан после многократных попыток автора перехачить irqbalance и выпилить его баги :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 7 июня, 2015 · Жалоба а подскажите что делают данные команды 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nu11 Опубликовано 7 июня, 2015 · Жалоба pppoetest, pavel.odintsov, мне помог в полностью аналогичной ситуации irqbalance. birq не пробовал, ТС пишет, что не помогло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 9 июня, 2015 · Жалоба Здравствуйте, у меня несколько похожая ситуация, только проблема в том, что очереди на самой сетевой заполняются неравномерно: [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 Подскажите пожалуйста, куда смотреть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 9 июня, 2015 · Жалоба А что за трафик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 9 июня, 2015 (изменено) · Жалоба Интерфейсы в бондинге с вланами, клиентский трафик натится на внешний IP, установленный на одном из вланов. Изменено 9 июня, 2015 пользователем SABRE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 9 июня, 2015 · Жалоба Видимо, надо дрессировать хэш сетевой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 9 июня, 2015 · Жалоба А есть ссылка на почитать? Или пример? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 9 июня, 2015 · Жалоба Man ethtool: rx-flow-hash Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 9 июня, 2015 (изменено) · Жалоба Я так понимаю 82576 это не умеет? ethtool -n eth0 4 RX rings available rxclass: Cannot get RX class rule count: Operation not supported RX classification rule retrieval failed Изменено 9 июня, 2015 пользователем SABRE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 9 июня, 2015 · Жалоба покажите ethtool -i eth0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 9 июня, 2015 (изменено) · Жалоба 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) Изменено 9 июня, 2015 пользователем SABRE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nu11 Опубликовано 9 июня, 2015 · Жалоба Отсутствие распределения по ядрам никак не связано с настройками сетевой карты. Конечно, полезно ее настроить, но проблему надо решать другим путем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 10 июня, 2015 · Жалоба SABRE а как у вас раскиданы очереди по ядрам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...