LINUX.ORG.RU
ФорумAdmin

Проблема с сетевым адаптером

 


0

1

Добрый день.

Имеется серверная платформа Intel S5500 с установленным свежим CentOS 7, ядро 3.10.0-123.20.1.el7.x86_64. Версия BIOS платформы S5500.86B.01.00.0064.050520141428, тоже свежая.

На борту сетевая карта:

Handle 0x001C, DMI type 10, 6 bytes
On Board Device Information
        Type: Ethernet
        Status: Enabled
        Description: Intel 82576EB Ethernet

[root@* ~]# ethtool -i eth0
driver: igb
version: 5.0.5-k
firmware-version: 1.4.3
bus-info: 0000:01:00.0

Проблема в том, что на сервере неадекватно высок расход CPU на сетевые прерывания. Там, где аналогичные машины (супермикры кстати), расходуют 10% CPU на 100% утилизацию полосы сетевой карты синтетическим тестом, на этой машине уходит все 100% CPU и идет значительный packet loss. При том что конфиграция серверов аналогичная.

Я по началу грешил на firmware сетевой карты. Обновил BIOS и все что с ним прилагается на свежую версию, но там та же верси я 1.4.3 идет.

Вот так выглядит perf top здорового сервера:

 38.21%  svr                     [.] 0x00000000000fd929                                                                                               ♦
  3.88%  sr.so                   [.] 0x0000000000027079                                                                                               ▒
  2.16%  [kernel]                      [k] ipt_do_table                                                                                                     ▒
  1.43%  tcpdump                       [.] 0x0000000000005391                                                                                               ▒
  1.38%  [kernel]                      [k] ____nf_conntrack_find                                                                                            ▒
  1.32%  libc-2.17.so                  [.] __random                                                                                                         ▒
  1.31%  [kernel]                      [k] fib_table_lookup                                                                                                 ▒
  0.99%  [kernel]                      [k] _raw_spin_lock_bh                                                                                                ▒
  0.92%  libc-2.17.so                  [.] _int_malloc                                                                                                      ▒
  0.76%  de.so                 [.] CElementIDs::GetElement(ElementID)                                                                               ▒
  0.72%  [kernel]                      [k] igb_clean_rx_irq                                                                                                 ▒
  0.64%  libstdc++.so.6.0.19           [.] 0x0000000000068fa3                                                                                               ▒
  0.60%  [kernel]                      [k] tg_load_down                                                                                                     ▒
  0.50%  de.so                 [.] CElement::CallEventNoParent(char const*, CLuaArguments const&, CElement*, CPlayer*)                              ▒
  0.46%  [kernel]                      [k] inet_getpeer                                                                                                     ▒
  0.46%  libc-2.17.so                  [.] _int_free                                                                                                        ▒
  0.44%  [kernel]                      [k] nf_conntrack_in                                                                                                  ▒
  0.44%  libc-2.17.so                  [.] malloc                                                                                                           ▒
  0.44%  [kernel]                      [k] _raw_spin_lock                                                                                                   ▒
  0.44%  [kernel]                      [k] rcu_nocb_kthread                                                                                                 ▒

А вот так у «курильщика»

 35.61%  svr                     [.] 0x0000000000039183                                                                                               ♦
 15.31%  [kernel]                      [k] _raw_spin_lock_bh                                                                                                ▒
  3.94%  st.so                   [.] 0x0000000000007707                                                                                               ▒
  2.14%  cr.so                [.] amx_Exec                                                                                                         ▒
  1.43%  tcpdump                       [.] 0x000000000005cc7f                                                                                               ▒
  1.17%  cr.so                [.] amx_Exec                                                                                                         ▒
  1.10%  [kernel]                      [k] ____nf_conntrack_find                                                                                            ▒
  1.10%  libc-2.17.so                  [.] __random                                                                                                         ▒
  1.08%  [kernel]                      [k] ipt_do_table                                                                                                     ▒
  0.94%  [kernel]                      [k] fib_table_lookup                                                                                                 ▒
  0.71%  libc-2.17.so                  [.] _int_malloc                                                                                                      ▒
  0.62%  [kernel]                      [k] tg_load_down                                                                                                     ▒
  0.56%  crashdetect.so                [.] amx_Exec                                                                                                         ▒
  0.51%  libstdc++.so.6.0.19           [.] std::_Rb_tree_increment(std::_Rb_tree_node_base*)                                                                ▒
  0.49%  [kernel]                      [k] __schedule                                                                                                       ▒
  0.47%  [kernel]                      [k] nf_conntrack_free                                                                                                ▒
  0.47%  [kernel]                      [k] _raw_spin_unlock_bh                                                                                              ▒
  0.43%  [kernel]                      [k] igb_clean_rx_irq                                            

Напрягает _raw_spin_lock_bh. Но пока непонятно, куда копать дальше.


_raw_spin_lock_bh - блокировки между ядрами.

Ты же уже вроде решал эту проблему ранее.

сравни какие и сколько ядер обрабатывают прерывания от этой сетевой карты на обоих серверах.

vel ★★★★★
()
Ответ на: комментарий от vel

Решал. Но на этой машине какая-то специфическая проблема. Тут платформа другая (Intel), firmware сетевой карты отличается (стоит 1.4.3, на супермикрах 1.5.3), но в обновлениях от intel та же самая версия везде. Потому вроде как все самое свежее стоит. Вот и думаю, то ли я дурак и проблема где-то еще, то ли лыжи не едут.

Пребывания на 8 RxTx очередей делятся, как и должно быть, прибивать к ядрам их пробовал по разному, разницы не заметил.

Amoled
() автор топика
Ответ на: комментарий от vel

Проглядел кстати прошлый топик, вспомнил что советовали прибивать пребывания к камню где заходит шина PCI-E. Всегда прибивал их к последним 8-ми ядрам. Попробовал к первым 8-ми - разницы нет.

Amoled
() автор топика
Ответ на: комментарий от Amoled

На этой машине есть фильтрация по состоянию соединений (т.е. -m state) или NAT? Если нет, то запрети conntrack и посмотри. conntrack дает большую нагрузку при большом числе соединений в секунду.

Хорошо бы понять разницу в скорости прерываний от сетевушки. Если их число не отличается в разы, значит проблема не в сетевушке, а в обработке пакетов ядром. Иначе нужно настраивать InterruptThrottleRate

Я сталкивался с специфическими проблемами в igb драйвере в ванильном ядре, но проблема решалась путем установки драйвера с sourceforge. Там версия намного свежее чем в ядре. Оригинальные интеловские драйвера никогда не использовал.

vel ★★★★★
()
Ответ на: комментарий от Amoled

надо сравнить еще возможности этих плат по gro/tso

За счет этого можно сильно снизить число прерываний

vel ★★★★★
()
Ответ на: комментарий от Amoled

А кто дает эту 100% загрузку ?

Я бы посмотрел на соотношение irq/softirq

Если irq >> softirq - проблема с сетевушкой, иначе в выше - iptables/conntrack и сетевой стек.

vel ★★★★★
()
Ответ на: комментарий от vel

На сервере состояния отслеживаются, как и на всех остальных. Но конкретно этот тип трафика почти сразу после получения помечается как не отслеживаемый (конечно перед этим state NEW проверяется, но так у всех пациентов сделано).

Прерываний во время нагрузочного тестирования 200к. InterruptThrottleRate стоит в режиме 3, т.е. адаптируется под нагрузку, потому больше 200к не бывает. На других («здоровых») пациентах аналогичные показатели и параметры.

Драйвер igb пробовал собирать из сырцов с сайта Intel'а последней версии, там у них баг. Есть на багтеркере, есть решение, пробовал - стал ребутиться сервер рандомно без записей об ошибках. Откатил к чертям его к версии из ядра.

надо сравнить еще возможности этих плат по gro/tso

Подробнее пожалуйста. Пробовал включать/выключать их, особой разницы не заметил.

Я бы посмотрел на соотношение irq/softirq

Посмотрю.

Amoled
() автор топика
Ответ на: комментарий от Amoled

[qoute]Но конкретно этот тип трафика почти сразу после получения помечается как не отслеживаемый «iptables -t raw -A PREROUTING ... -j CT --notrack» ?

200к прерываний - это очень много.

Про gro/tso: включенный и работающий gro можно увидить через «tcpdump -ni ethX -c 10 greater 1500» и возможно через «ethtool -S ethX»

vel ★★★★★
()
Ответ на: комментарий от Amoled

Есть подозрение, что ITR не работает так как хотелось бы.

Я бы внимательно почитал README драйверов. Там есть интересные замечания на счет ITR,IntMode,RSS,DMAC

дефолтный ITR=3 на мелкопакетном трафике может давать слишком большое число прерываний. Я бы начал с ITR=4000-8000

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.