[aabc]

Dark_Angel

Так как у драйвера есть предел размера очереди в 4096, то я советовал увеличить кол-во очередей в два раза, что по-сути увеличит очередь в два раза. При этом оказалось, что ixgbe оставляет векторов прерывания столько-же сколько cpu (то есть их в два раза больше не становится), по две очереди оказываются на одном прерывании. Это конечно от реализации драйвера зависит и не было предсказуемо. Но, если бы прерываний стало больше в два раза, то это всё равно нагрузка на [hard] irq, где она была небольшая. Грузило softirq.

 

Это всё было в контексте решения роста rx_no_dma_resources (QPRDC). Системную причину, почему он рос так и не выяснили. То ли флуктуации трафика (к чему я склоняюсь), то ли ещё что. Проще оказалось попробовать решение (увеличение очереди) и посмотреть результат.

Изменено 22 декабря, 2014 пользователем aabc

[junjunk2]

Dark_Angel

однозначно уверен, что не драйвер и не ядро. Т.к. их не менял. При этом ITR крутил в сторону увеличения и это не помогло, хотя и немного снизило количество ошибок. Причиной же мне кажется именно нелинейность нагрузки от трафика. То есть реально в определенные короткие промежутки времени очереди успевали забиваться до момента прерывания. Ошибки начинали появляться при трафике >=7Гбит/с при усреднении за 30 секунд. То есть сказать, сколько точно трафика было в каждый квант времени между прерываниями я не могу. Однако количество ошибок вырастало скачкообразно на 0.8-1.2 ошибок за раз, то есть вероятнее всего в моменты локального всплеска трафика. Сейчас перегрузил вторую машинку с такими же параметрами (8 RSS, 4 MSI-X вектора) на ядре 2.6.32-431.29.2.el6.x86_64 (CentOS 6.5), соответственно завтра к ночи смогу сравнить разницу в нагрузке при разных ядрах и отсутствии ошибок. Ну или узнать, что на старом ядре это не помогает и буду обновлять ядро :)

[Dark_Angel]

Спасибо за объяснения, парни. А до какого значения вы крутили ITR?

 

Потому как моя логика следующая: раз очередь переполняется и её размер уже максимален ( вы ведь поставили ring buffer в 4096? ), значит нужно выгребать её чаще, что можно сделать чаще прерываясь. Например, в 2 раза больше, чем прерывается, когда есть ошибки.

 

То есть больше очередей в данной ситуации выглядит как хак. Не самый плохой, но тем не менее.

 

Ну и да, похоже ошибки набегают от всплеска за промежуток замера.

[junjunk2]

У меня сейчас стоит 12000 прерываний на вектор. В случае автоматического подбора драйвером в ЧНН было около от 7 до 8 тысяч. При 12000 и 4х очередях ошибки сыпало так же, как и на 8000, может в чуть меньшем абсолютном значении, но порядок такой же был.

[Dark_Angel]

А есть возможность сделать столько же очередей сколько было и сделать 24К на вектор и посмотреть результат?

[junjunk2]

Да, сегодня в связи с выходом драйвера 3.23.2, буду переделывать и пробовать под последним ядром CentOS, заодно и попробую такой вариант. Кстати, ядро 2.6.32-431.29.2 с драйвером 3.22.3, 8 RSS, 4 IRQ, 12K на вектор - всё равно есть ошибки даже при пиковом трафике <7 гбит.

[alks]

to junjunk2, если у вас два сервера NAT и есть локальная связанность внутри сети между клиентами то у вас еще будет паразитный торрент трафик между пулами белых адресов обоих серверов

если так то прибейте его и получите еще несколько процентов cpu в бонус

и еще, попробуйте включить rpf-check на железке отдающей траф в сторону nat сервера

[junjunk2]

Dark_Angel

Даже при 8 RSS увеличение прерываний до 20К не дало избавления от ошибок.

и на ядре Centos в perf top вижу вот такое:

15.34%  [kernel]              [k] _spin_lock
 9.22%  [kernel]              [k] ip_route_input
 5.74%  [kernel]              [k] ixgbe_poll
 5.13%  [kernel]              [k] native_read_tsc
 3.91%  [kernel]              [k] delay_tsc

 

с чего бы это вдруг _spin_lock вылез в отрыв?...

[aabc]

на ядре Centos в perf top вижу вот такое:

15.34%  [kernel]              [k] _spin_lock
 9.22%  [kernel]              [k] ip_route_input
 5.74%  [kernel]              [k] ixgbe_poll
 5.13%  [kernel]              [k] native_read_tsc
 3.91%  [kernel]              [k] delay_tsc

 

с чего бы это вдруг _spin_lock вылез в отрыв?...

 

Делайте perf top -g (появится "+" в начале строк) потом ентером жмите на строчках, которые надо раскрыть. Будет такая же табличка тех функций кто вызывает _spin_lock с процентами. И там сверху будет виновник торжества.

 

Например

 

-   2.38%  [kernel]                        [k] _raw_spin_lock         
  - _raw_spin_lock                                                   
     + 41.78% sch_direct_xmit                                        
     + 11.46% enqueue_to_backlog                                     
     + 7.76% tick_do_update_jiffies64                                

[Dark_Angel]

Ну ошибок стало меньше/больше/так же? А когда 4 RSS очереди?

[junjunk2]

Dark_Angel

Не могу тут ничего сказать, т.к. ошибки ползут скачкообразно. Но порядок остался тот же - несколько сотен тысяч ошибок при 0.9 Mpps. 4 RSS пока еще не успел

[junjunk2]

Поскольку ядро не debug, то и perf top -g не может показать, откуда у каждого процесса ноги растут.

 

Переход на ядро 2.6.32.504.3.3 и установка драйвера 3.23.2 под ixgbe, а так же 8 RSS и 12000 прерываний на вектор - ошибки исчезли. Итого, вероятнее всего в ядро 504 в ветке CentOS впили что-то от Mainline, связанное с conntrack (т.к. фактически больше ничего не используется), отчего производительность ната реально возрасла.

 

Правда есть и побочный эффект - очень большое количество context switch, прямопропорциональное объему трафика (доходит до 22000 переключений в секунду). Причем на mainline ядре (правда 3.17.4) я такого не заметил (хоть там и было увеличение относительно 2.6.32.401, но значение не зависело от трафика и было стабильно около 2000 в секунду). Не думаю, что этому поспособствовал последний драйвер ixbge, но всё же поставлю на mainline этот драйвер для проверки.

[aabc]

Поскольку ядро не debug, то и perf top -g не может показать, откуда у каждого процесса ноги растут.

А.., в центосе чуть более старый perf и там надо делать: perf top -G

Изменено 27 декабря, 2014 пользователем aabc

[junjunk2]

aabc

Посмотрел, действительно -G показывает. Спасибо за подсказку. Однако сейчас ситуация нормальная и _spin_lock далеко не в топе.

 

Проанализировал ситуацию - действительно, ядро 3.17 производительнее ядра 2.6.32.х, постовляемого в CentOS. Разница следующая - при абсолютно одинаковых процессорах, памяти и сетевых, абсолютно одинаковых настройках сетевых, количестве записей в таблице маршрутизации и в таблицах iptables, на последнем ядре от CentOS ветки 6 при 56% загрузки процессора пережевывается 6.2 ГБит/с, 860 Kpps, 810000 conntracks, при этом на ядре 3.17.4 при тех же 56% загрузки - 6.8 Гбит/с, 1.01 Mpps, 900000 conntracks. вот такая вот разница. Ошибок на интерфейсах нет уже 3 дня, причем не только обсуждаемых выше, но и других (кроме rx_csum_offload_errors, что насколько я понимаю, не является ошибкой производительности, а ошибкой среды передачи данных)

[Dark_Angel]

Жаль, что не удалось проверить работу с 4 RSS, думаю ошибок тоже не будет при ручном ITR.

[junjunk2]

Подниму темку.

Поставили новый сервак - Xeon E5-1650 v2 + Intel X520-DA2. Собрал в LACP два порта.

Отконфигурил всё как обычно на NAT серверах. В итоге при 15Гбит/с - 2.2 Mpps - почти все ядра в полке. Немного неравномерно были нагружены, но не суть. Вопрос - нормальный ли это показатель? У кого есть опыт по нагрузке?

 

Так же параллельно при обновлении уже имевшихся серверов выявил интересную вещь - при включенных VT-x нагрузка значительно выше. При 5 Гбит/с 0.75 Мппс загрузка 34% на E3-1270 против 46% на абсолютно таком же железе с включенными VT-x. Причем intremap=off при загрузке ядра не помогает, надо именно отключить в BIOS.

 

Ну и пока максимальную производительность показало ядро 3.19.3. По perf top с небольшим отрывом идет fib_table_lookup ... не нашел информации, включили ли патчик от Alexander Duyck " fib_trie: Reduce time spent in fib_table_lookup by 35 to 75%" в ванильные ядра, кто-нибудь владеет данной информацией?

Изменено 24 января, 2016 пользователем junjunk2

[s.lobanov]

junjunk2

а чё, git log отменили?

 

да, включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e495f78d787b56ad249946b191406f4521b58150

[junjunk2]

Спасибо, что направили в нужное место. Эти патчи не попали в 3.19.х, т.к. опоздали на сутки в net-next, в итоге перешел на 4.1.16, получил еще чуть ускорения.

Итого на E3-1270v2 @3.5Ггц при 7.6 Гбит/с 1.15Mpps получаем ~55% нагрузки, ошибок на интерфейсе нет. Использовал пока что один порт от X520-DA2, сегодня еще попробую затестить ядро, пересобранное с опцией MCORE2, а на следующей неделе попробую запустить 2 порта и посмотреть, какой overhead будет у bonding и сколько вообще трафика может пережевать такое железо

[junjunk2]

Провел еще тесты. overhead от подключения второго порта и сбора LACP какой-то очень уж большой - порядка 15%, соответственно при 12Гбит/с @ 1.8Mpps нагрузка 98-100%.

Закралось смутное подозрение, что не совсем оптимально пакет обрабатывается. В моей схеме физичексие порты объединены в LACP, а in и out интерфейсы - это разные vlan поверх этого LACP. Есть подозрение, что пакет уходит не через ту очередь, через которую пришел, из-за выбора физического интерфейса в bonding. Есть ли у кого-нить опыт тюнинга таких вещей?

[Hawk128]

М.б. стоит попробовать без LACP? Через один физический пришло, через другой ушло?

[junjunk2]

Hawk128

тогда я уткнусь в 10Гбит на линке

[Hawk128]

Действительно.

 

А сейчас на вход 12 а на выход сколько проходит.

В вашем случае они суммируются.

И параметры слота и карты при загрузке на 8х заводятся?

[junjunk2]

сейчас получается 12 в пике full duplex, соотношение 1/6 - tx, 5/6 - rx. То есть rx примерно 10 гбит/с в пике.

при старте карта заводится как PCIe x8

ixgbe 0000:02:00.0: PCI Express bandwidth of 32GT/s available

ixgbe 0000:02:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)

ixgbe 0000:02:00.0 eth0: MAC: 2, PHY: 18, SFP+: 5, PBA No: E66560-002

ixgbe 0000:02:00.0: 00:1b:21:6b:8c:20

ixgbe 0000:02:00.0 eth0: Enabled Features: RxQ: 8 TxQ: 8 FdirHash

ixgbe 0000:02:00.0 eth0: Intel® 10 Gigabit Network Connection

ixgbe: Direct Cache Access (DCA) set to 1

ixgbe: Receive-Side Scaling (RSS) set to 8

ixgbe: Interrupt Throttling Rate (ints/sec) set to 12000

ixgbe: Flow Director packet buffer allocation set to 3

ixgbe: 0000:02:00.1: ixgbe_check_options: Flow Director will be allocated 256kB of packet buffer

ixgbe: Enabled/Disable FCoE offload Disabled

ixgbe: 0000:02:00.1: ixgbe_check_options: FCoE Offload feature disabled

ixgbe: LRO - Large Receive Offload Disabled

ixgbe: allow_unsupported_sfp Enabled

Изменено 26 января, 2016 пользователем junjunk2

[tartila]

Hawk128

тогда я уткнусь в 10Гбит на линке

 

Раскидайте нагрузку сегментацией либо роутингом, либо l2(vlan)+роутинг. Не надо никаких LACP - никогда профита от этой дряни не было...

[NiTr0]

к слову, включение LRO может помочь еще немного выжать.