replicant Posted March 12, 2014 · Report post ЧАСТЬ 1: Имеется Intel 82599EB и два способа отключения LRO. 1. modprobe ixgbe LRO=0 2. ethtool -K eth0 lro off Какой способ правильный и идет ли речь об одном и том же параметре LRO или это все же разные опции? --------- ЧАСТЬ 2: При использовании сервера в качестве L3 routing машины надо ли отключать опции ethtool -K gro, gso, tso, lro или пофиг (раньше отключал)? --------- ЧАСТЬ 3: При переходе с двух 4-х портовых 82576 на одну 82599 резко возросла нагрузка на CPU вплоть до 100% загрузки на ровном месте. Ничего не менялось, кроме вытаскивания одной железки и втыкания другой в ту же самую машину, ну и соответственно сборки другого драйвера. Собрал 3.19.1, хотя ядерный был 3.6.7. С чего бы вдруг случилось такое поведение машины? Может 3.19.1 глючной попался? Никто не сталкивался с подобным? Share this post Link to post Share on other sites
pavel.odintsov Posted March 13, 2014 (edited) · Report post Имхо, пофиг, но вот что обязательно нужно выключить, так это: ethtool -K ethX tso off У нас на 3.2 ядре оно пакеты било ужасающе. Все остальное не так влияет (по крайне мере мы не заметили). Для ixgbe стандартно отключено распределение по всем 8 ми очередям для обработки трафика, включите в ixgbe.conf это, сделать можно примерно так: options ixgbe InterruptType=2,2,2,2,2,2 MQ=1,1,1,1,1,1 DCA=2,2,2,2,2,2 RSS=0,0,0,0,0,0 VMDQ=0,0,0,0,0,0 max_vfs=0,0,0,0,0,0 L2LBen=0,0,0,0,0,0 InterruptThrottleRate=1,1,1,1,1,1 FCoE=0,0,0,0,0,0 LRO=0,0,0,0,0,0 allow_unsupported_sfp=0,0,0,0,0,0 Edited March 13, 2014 by pavel.odintsov Share this post Link to post Share on other sites
replicant Posted March 13, 2014 (edited) · Report post У меня 4 ядра Xeon E3 1240v2 -3.4 GHz без HT, поэтому мне не надо 8 очередей. У меня по две комбинированные очереди на порт 10Г. Соответственно загружаю драйвер с опциями /sbin/modprobe ixgbe IntMode=2,2 RSS=2,2 DCA=2,2 LRO=0,0 Далее просто прибиваю очереди к ядрами типа так echo 1 > /proc/irq/42/smp_affinity echo 2 > /proc/irq/43/smp_affinity echo 4 > /proc/irq/45/smp_affinity echo 8 > /proc/irq/46/smp_affinity Что значит отсутствует распределение по очередям? В cat /proc/interrupts четко видны очереди по две на каждый порт 10Г прибитые к ядрам. 42: 35332028 2 2 1 PCI-MSI-edge eth0-TxRx-0 43: 3 30171958 0 3 PCI-MSI-edge eth0-TxRx-1 45: 2 0 39410653 2 PCI-MSI-edge eth1-TxRx-0 46: 1 3 0 37290726 PCI-MSI-edge eth1-TxRx-1 Edited March 13, 2014 by replicant Share this post Link to post Share on other sites
pavel.odintsov Posted March 13, 2014 · Report post А perf top что показывает? Share this post Link to post Share on other sites
replicant Posted March 13, 2014 (edited) · Report post А perf top что показывает? Когда поставили ixgbe, то стало так PerfTop: 23194 irqs/sec kernel:99.8% [100000 cycles], (all, 4 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 133504.00 - 38.4% : gre_pkt_to_tuple 130579.00 - 37.5% : memcmp 11445.00 - 3.3% : intel_idle 7069.00 - 2.0% : ixgbe_poll [ixgbe] 7041.00 - 2.0% : ipt_do_table 2335.00 - 0.7% : nf_iterate 2334.00 - 0.7% : _raw_spin_lock 2330.00 - 0.7% : ip_route_input_common 2170.00 - 0.6% : __slab_free 2157.00 - 0.6% : ixgbe_xmit_frame_ring [ixgbe] 1687.00 - 0.5% : ____nf_conntrack_find 1637.00 - 0.5% : dev_queue_xmit 1605.00 - 0.5% : irq_entries_start 1450.00 - 0.4% : eth_type_trans 1050.00 - 0.3% : vlan_do_receive ================= пока стояли igb картинка была такой, т.е. никакого to_tuple не было в помине ... PerfTop: 8142 irqs/sec kernel:99.2% [100000 cycles], (all, 4 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 12096.00 - 10.1% : igb_poll [igb] 10523.00 - 8.8% : intel_idle 6675.00 - 5.6% : ipt_do_table 5089.00 - 4.2% : __memcpy 4265.00 - 3.6% : _raw_spin_lock 4022.00 - 3.3% : irq_entries_start 2741.00 - 2.3% : __slab_free 2190.00 - 1.8% : nf_iterate 1939.00 - 1.6% : dev_queue_xmit 1784.00 - 1.5% : __napi_complete 1773.00 - 1.5% : igb_xmit_frame_ring [igb] 1653.00 - 1.4% : rcu_enter_nohz 1629.00 - 1.4% : ____nf_conntrack_find 1567.00 - 1.3% : __slab_alloc.constprop.69 1546.00 - 1.3% : ksize Edited March 13, 2014 by replicant Share this post Link to post Share on other sites
replicant Posted March 13, 2014 (edited) · Report post Такое чувство, что сервак что-то пытается сделать с пролетающими через него pptp туннелями, но зачем? Откуда ноги у gre_pkt_to_tuple ? Edited March 13, 2014 by replicant Share this post Link to post Share on other sites
replicant Posted March 13, 2014 (edited) · Report post Все разобрался. Слона-то и не заметил. Причиной был подгрузившийся модуль NF_CONNTRACK_PPTP. После выгрузки все нормализовалось. Нагрузка на CPU железяки при пролетающих через нее суммарно 1.5 Гбит/с трафика теперь около 2.5-3.5%. Так и должно быть. Соответственно все остальные риторические вопросы тоже отпали сами собой. Edited March 13, 2014 by replicant Share this post Link to post Share on other sites
vitalyb Posted March 13, 2014 · Report post intel_idle тоже надо убить, смотрите соседнюю ветку. Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой". Share this post Link to post Share on other sites
replicant Posted March 13, 2014 · Report post Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой". С этим согласен, но пока искал причину, то пришлось уменьшить до RSS=2,2, вместо 4,4. Share this post Link to post Share on other sites
replicant Posted March 13, 2014 (edited) · Report post intel_idle тоже надо убить, смотрите соседнюю ветку. Т.е. я правильно понял что надо выкосить из ядра вот это CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_INTEL_IDLE=y А также в lilo (у меня он загрузчиком стоит) прописать эти две строки? intel_idle.max_cstate=0 processor.max_cstate=1 -------------------------------- В принципе powertop показывает что частота гуляет в пределах от 2.8 до 3.4 ГГц, поэтому не критично, хотя и неприятно с этим idle получается. Edited March 13, 2014 by replicant Share this post Link to post Share on other sites
vitalyb Posted March 13, 2014 · Report post Достаточно убрать CONFIG_INTEL_IDLE или выставить параметр ядра. Переключение частоты тоже надо выключить. Каждое изменение стостояние активный-глубокий сон или переключение частоты сопровождается задержкой, когда данные с сетевухи не обрабатываются и иногда сопутствующими накладными расходами, могут быть дропы на ровном месте и на низкой нагрузке. Share this post Link to post Share on other sites
kayot Posted March 13, 2014 (edited) · Report post Переключение частоты тоже надо выключить. Каждое изменение стостояние активный-глубокий сон или переключение частоты сопровождается задержкой, когда данные с сетевухи не обрабатываются и иногда сопутствующими накладными расходами, могут быть дропы на ровном месте и на низкой нагрузке. Cstate 1 это не изменение частоты, а банальный halt в бездействии. Который практически бесплатен и дает огромную экономию энергии в сравнении с постоянным лупом(вспоминайте времена win95, когда этого халта не было в системе и охлаждали CPU программы типа waterfall). IMHO все-таки параметры intel_idle.max_cstate=0 processor.max_cstate=1(отключение intel idle, максимальный уровень сбережения - halt) оптимальны. Не зря их intel/hp/etc рекомендуют в сетевых гайдах. Edited March 13, 2014 by kayot Share this post Link to post Share on other sites
vitalyb Posted March 13, 2014 · Report post Cstate 1 это не изменение частоты, а банальный halt в бездействии Изменение частоты касалось фразы "частота гуляет в пределах от 2.8 до 3.4 ГГц" топикстартера. И C1 тоже не глубокий сон, о котором писал :) Share this post Link to post Share on other sites
kayot Posted March 13, 2014 · Report post vitalyb Согласен. Просто в последнее время вижу все больше рекомендаций косить все энергосбережение полностью, это не есть хорошо. Share this post Link to post Share on other sites
replicant Posted March 13, 2014 · Report post Указание параметров ядра решает и вопросы с частотой. powertop говорит Package | Core | CPU 0 | | C0 active inf% C2 (pc2) 0.0% | | C3 (pc3) 0.0% | C3 (cc3) 0.0% | C6 (pc6) 0.0% | C6 (cc6) 0.0% | C7 (pc7) 0.0% | C7 (cc7) 0.0% | | Core | CPU 1 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | | Core | CPU 2 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | | Core | CPU 3 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | Т.е. состояния С2,C3,C6,C7 не используются. А дальше показывает, что Package | Core | CPU 0 | | Actual 0 Idle 100.0% | Idle 100.0% | Idle 100.0% | Core | CPU 1 | | Actual 0 | Idle 100.0% | Idle 100.0% | Core | CPU 2 | | Actual 0 | Idle 100.0% | Idle 100.0% | Core | CPU 3 | | Actual 0 | Idle 100.0% | Idle 100.0% частота 100% и больше нет смысла выводить показатель Actual в GHz. В perf top появился irq_entries_start, которого раньше не было. Ну и при RSS=4,4 нагрузка на si стала чуть больше. samples pcnt kernel function _______ _____ _______________ 7203.00 - 11.9% : irq_entries_start 6276.00 - 10.4% : ixgbe_poll [ixgbe] 4758.00 - 7.9% : ipt_do_table 2332.00 - 3.9% : add_interrupt_randomness 2040.00 - 3.4% : _raw_spin_lock 1530.00 - 2.5% : nf_iterate 1385.00 - 2.3% : ixgbe_xmit_frame_ring [ixgbe] 1054.00 - 1.7% : dev_queue_xmit 1025.00 - 1.7% : ip_route_input_common 922.00 - 1.5% : rcu_enter_nohz 879.00 - 1.5% : ____nf_conntrack_find 862.00 - 1.4% : eth_type_trans 851.00 - 1.4% : local_bh_enable 766.00 - 1.3% : __napi_complete 666.00 - 1.1% : tick_nohz_stop_sched_tick Share this post Link to post Share on other sites
walertos Posted December 17, 2016 · Report post У меня дебиан ядро 3.16 в sysctl не одно параметра связанного с idle или cstate нет. Ядро собрано без этого. Но при задействовании двух 6ти ядерных камней Intel® Xeon® CPU X5670 при низкой нагрузке появляются дропы, всё перепробовал не могу решить проблему. Share this post Link to post Share on other sites
roysbike Posted December 17, 2016 · Report post У меня было такое . Когда в одном vlan был loop (раз 1 час включался порт клиента и вырублася ), то на карты 82599 взлетел CPU до 100%. Серверы с 82576 такого не почувствовали. Может у вас чистый L3 и vlan не дохядт пачками. Share this post Link to post Share on other sites
walertos Posted December 18, 2016 · Report post Хоть бы кто-то написал что не один из этих параметров не видно в sysctl и, что нужно полюбому передавать через GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1 intel_idle.max_cstate=0" Посмотрим даст оно что-то или нет. Share this post Link to post Share on other sites
Morbid Posted December 18, 2016 · Report post Отпишитесь плиз по результатам Share this post Link to post Share on other sites
walertos Posted December 18, 2016 (edited) · Report post Сервер: Материнка: Tean Проц: Intel® Xeon® CPU X5670 *2 Сетевые : двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1 двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3 Нагрузка: eth0 Link encap:Ethernet HWaddr 00:e0:ed:2d:24:df UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5376385179 errors:0 dropped:0 overruns:0 frame:0 TX packets:3828422980 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:6252906728086 (5.6 TiB) TX bytes:1534230664189 (1.3 TiB) eth1 Link encap:Ethernet HWaddr 00:e0:ed:2d:24:de UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4972876866 errors:0 dropped:1 overruns:0 frame:0 TX packets:7218214228 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:2075368983221 (1.8 TiB) TX bytes:8545645631048 (7.7 TiB) eth2 Link encap:Ethernet HWaddr 00:1b:21:a1:05:92 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:923259881 errors:0 dropped:0 overruns:0 frame:0 TX packets:493192217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1063932576905 (990.8 GiB) TX bytes:171104097462 (159.3 GiB) eth3 Link encap:Ethernet HWaddr 00:1b:21:a1:05:92 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:922905096 errors:0 dropped:17 overruns:0 frame:0 TX packets:558827639 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1060293498441 (987.4 GiB) TX bytes:251065695390 (233.8 GiB) # uptime 17:11:00 up 14:41, 2 users, load average: 0,14, 0,24, 0,30 Пока полёт отличный Edited December 18, 2016 by walertos Share this post Link to post Share on other sites
QWE Posted December 24, 2016 (edited) · Report post Сервер: Материнка: Tean Проц: Intel® Xeon® CPU X5670 *2 Сетевые : двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1 двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3 Нагрузка: # uptime 17:11:00 up 14:41, 2 users, load average: 0,14, 0,24, 0,30 Пока полёт отличный А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть? Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ? Какое ядро? дистр? Edited December 24, 2016 by QWE Share this post Link to post Share on other sites
walertos Posted January 29, 2017 · Report post Сервер: Материнка: Tean Проц: Intel® Xeon® CPU X5670 *2 Сетевые : двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1 двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3 Нагрузка: # uptime 17:11:00 up 14:41, 2 users, load average: 0,14, 0,24, 0,30 Пока полёт отличный А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть? Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ? Какое ядро? дистр? Это пограничник + NAS , куча правил iptables с ipset, так же CONNTRACK выключен при помощи raw NOTRACK, включен только для определённых ipset для редиректа абонентов на страницы заглушки, ещё на нём multicast в unicast перегоняется при помощи astra до 500M. При нормальной работе наверное около 1M PPS в чнн при атаках и около трёх проскакивало. Debian 6, Ядро 3.16. Share this post Link to post Share on other sites
vlad11 Posted January 31, 2017 · Report post Debian 6, Ядро 3.16. Вам не страшно такое древнее на границе держать? Share this post Link to post Share on other sites
ichthyandr Posted February 1, 2017 · Report post Сервер: Материнка: Tean Проц: Intel® Xeon® CPU X5670 *2 Сетевые : двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1 двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3 Нагрузка: # uptime 17:11:00 up 14:41, 2 users, load average: 0,14, 0,24, 0,30 Пока полёт отличный А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть? Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ? Какое ядро? дистр? Это пограничник + NAS , куча правил iptables с ipset, так же CONNTRACK выключен при помощи raw NOTRACK, включен только для определённых ipset для редиректа абонентов на страницы заглушки, ещё на нём multicast в unicast перегоняется при помощи astra до 500M. При нормальной работе наверное около 1M PPS в чнн при атаках и около трёх проскакивало. Debian 6, Ядро 3.16. прерывания как разбросаны, если не секрет? Share this post Link to post Share on other sites
walertos Posted February 3, 2017 · Report post Вот так: Share this post Link to post Share on other sites
