Jump to content
Калькуляторы

Linux NAT оптимизация для 10G+ трафика

Dark_Angel

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

 

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

Edited by aabc

Share this post


Link to post
Share on other sites

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), соответственно завтра к ночи смогу сравнить разницу в нагрузке при разных ядрах и отсутствии ошибок. Ну или узнать, что на старом ядре это не помогает и буду обновлять ядро :)

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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 вылез в отрыв?...

Share this post


Link to post
Share on other sites

на ядре 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                                

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Dark_Angel

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

Share this post


Link to post
Share on other sites

Поскольку ядро не 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 этот драйвер для проверки.

Share this post


Link to post
Share on other sites

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

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

Edited by aabc

Share this post


Link to post
Share on other sites

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, что насколько я понимаю, не является ошибкой производительности, а ошибкой среды передачи данных)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Поставили новый сервак - 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%" в ванильные ядра, кто-нибудь владеет данной информацией?

Edited by junjunk2

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

сейчас получается 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

Edited by junjunk2

Share this post


Link to post
Share on other sites

Hawk128

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now