replicant Опубликовано 12 марта, 2014 · Жалоба ЧАСТЬ 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 глючной попался? Никто не сталкивался с подобным? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 марта, 2014 (изменено) · Жалоба Имхо, пофиг, но вот что обязательно нужно выключить, так это: 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 Изменено 13 марта, 2014 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 (изменено) · Жалоба У меня 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 Изменено 13 марта, 2014 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 марта, 2014 · Жалоба А perf top что показывает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 (изменено) · Жалоба А 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 Изменено 13 марта, 2014 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 (изменено) · Жалоба Такое чувство, что сервак что-то пытается сделать с пролетающими через него pptp туннелями, но зачем? Откуда ноги у gre_pkt_to_tuple ? Изменено 13 марта, 2014 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 (изменено) · Жалоба Все разобрался. Слона-то и не заметил. Причиной был подгрузившийся модуль NF_CONNTRACK_PPTP. После выгрузки все нормализовалось. Нагрузка на CPU железяки при пролетающих через нее суммарно 1.5 Гбит/с трафика теперь около 2.5-3.5%. Так и должно быть. Соответственно все остальные риторические вопросы тоже отпали сами собой. Изменено 13 марта, 2014 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 13 марта, 2014 · Жалоба intel_idle тоже надо убить, смотрите соседнюю ветку. Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 · Жалоба Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой". С этим согласен, но пока искал причину, то пришлось уменьшить до RSS=2,2, вместо 4,4. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 (изменено) · Жалоба 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 получается. Изменено 13 марта, 2014 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 13 марта, 2014 · Жалоба Достаточно убрать CONFIG_INTEL_IDLE или выставить параметр ядра. Переключение частоты тоже надо выключить. Каждое изменение стостояние активный-глубокий сон или переключение частоты сопровождается задержкой, когда данные с сетевухи не обрабатываются и иногда сопутствующими накладными расходами, могут быть дропы на ровном месте и на низкой нагрузке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 марта, 2014 (изменено) · Жалоба Переключение частоты тоже надо выключить. Каждое изменение стостояние активный-глубокий сон или переключение частоты сопровождается задержкой, когда данные с сетевухи не обрабатываются и иногда сопутствующими накладными расходами, могут быть дропы на ровном месте и на низкой нагрузке. Cstate 1 это не изменение частоты, а банальный halt в бездействии. Который практически бесплатен и дает огромную экономию энергии в сравнении с постоянным лупом(вспоминайте времена win95, когда этого халта не было в системе и охлаждали CPU программы типа waterfall). IMHO все-таки параметры intel_idle.max_cstate=0 processor.max_cstate=1(отключение intel idle, максимальный уровень сбережения - halt) оптимальны. Не зря их intel/hp/etc рекомендуют в сетевых гайдах. Изменено 13 марта, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 13 марта, 2014 · Жалоба Cstate 1 это не изменение частоты, а банальный halt в бездействии Изменение частоты касалось фразы "частота гуляет в пределах от 2.8 до 3.4 ГГц" топикстартера. И C1 тоже не глубокий сон, о котором писал :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 марта, 2014 · Жалоба vitalyb Согласен. Просто в последнее время вижу все больше рекомендаций косить все энергосбережение полностью, это не есть хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 марта, 2014 · Жалоба Указание параметров ядра решает и вопросы с частотой. 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
walertos Опубликовано 17 декабря, 2016 · Жалоба У меня дебиан ядро 3.16 в sysctl не одно параметра связанного с idle или cstate нет. Ядро собрано без этого. Но при задействовании двух 6ти ядерных камней Intel® Xeon® CPU X5670 при низкой нагрузке появляются дропы, всё перепробовал не могу решить проблему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 17 декабря, 2016 · Жалоба У меня было такое . Когда в одном vlan был loop (раз 1 час включался порт клиента и вырублася ), то на карты 82599 взлетел CPU до 100%. Серверы с 82576 такого не почувствовали. Может у вас чистый L3 и vlan не дохядт пачками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
walertos Опубликовано 18 декабря, 2016 · Жалоба Хоть бы кто-то написал что не один из этих параметров не видно в sysctl и, что нужно полюбому передавать через GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1 intel_idle.max_cstate=0" Посмотрим даст оно что-то или нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Morbid Опубликовано 18 декабря, 2016 · Жалоба Отпишитесь плиз по результатам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
walertos Опубликовано 18 декабря, 2016 (изменено) · Жалоба Сервер: Материнка: 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 Пока полёт отличный Изменено 18 декабря, 2016 пользователем walertos Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 24 декабря, 2016 (изменено) · Жалоба Сервер: Материнка: 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 ? Какое ядро? дистр? Изменено 24 декабря, 2016 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
walertos Опубликовано 29 января, 2017 · Жалоба Сервер: Материнка: 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 31 января, 2017 · Жалоба Debian 6, Ядро 3.16. Вам не страшно такое древнее на границе держать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 1 февраля, 2017 · Жалоба Сервер: Материнка: 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. прерывания как разбросаны, если не секрет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
walertos Опубликовано 3 февраля, 2017 · Жалоба Вот так: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...