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

Nic Bonding - Даст ли прирост?

Навеяно всякими мега-супер тестами производительности

(FreeBSD,em)

Так как стандартно 1 сетевая карточка использует 1 ядро, то если поставить dual карточку и объеденить два интерфейса мы получим две карточки, которые будут забирать по одному ядру каждое.

Тем самым мы не только получим двойной буфер, но и распареллелим весь траффик на два ядра. Современные свитчи поддерживаю LACP.

 

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

 

---

 

А теперь вопрос: где я наврал? будет ли это работать?

Edited by TiFFolk

Share this post


Link to post
Share on other sites
Так как стандартно 1 сетевая карточка использует 1 ядро

Уже неверно.

Share this post


Link to post
Share on other sites
Так как стандартно 1 сетевая карточка использует 1 ядро

Уже неверно.

Rx|Tx очереди обрабатываются только одним потоком

Share this post


Link to post
Share on other sites

В Linux очередь из верхних половин обработчиков прерываний (softirq) обрабатываются несколькими тредами ksoftirqd, которых в SMP-ядрах всегда по одному на каждый процессор/ядро. Выигрыш от bonding будет скорее не в снижении нагрузки на процессор, а в уменьшении задержек и в увеличении устойчивости к DoS-атакам, т.к. пакеты будут обрабатываться сразу двумя аппаратными очередями.

Edited by photon

Share this post


Link to post
Share on other sites
Так как стандартно 1 сетевая карточка использует 1 ядро

Уже неверно.

Jab, я конечно понимаю, но расскажите в двух словах, почему?

 

Разные дистрибутивы рассматриваем?

Share this post


Link to post
Share on other sites
Так как стандартно 1 сетевая карточка использует 1 ядро, то если поставить dual карточку

и объеденить два интерфейса мы получим две карточки, которые будут забирать по одному ядру каждое.

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

хорошая идея, только...

 

Современные свитчи поддерживаю LACP.
тут небольшая заметка:

для каких задач будет использоваться машина, потому что некоторые свичи

даже умеют балансировку по IP а некоторые только по МАС адресу источника

(имхо как обычно - чем больше навешано в софте, тем больше глюков - поэтому свич ещё надо подобрать) - это про Длинк

 

Те получим прирост в производительности на многопроцессорных машинах,

даже если траффика меньше чем два гигабита, только за счет распараллеливания.

да, если с умом подойти к проектированию такой системы или системы в целом.

на счет двух гигабит: тут уже надо Intel I/OAT (Intel I/O Acceleration Technology)

судя по тестам зарубежных коллег.

 

А теперь вопрос: где я наврал? будет ли это работать?
будет работать, зависит от задач.

 

выглядит это примерно так:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   13 root        1 171 ki31     0K     8K CPU0   0 145.9H 72.27% idle: cpu0
   10 root        1 171 ki31     0K     8K RUN    3 144.9H 69.78% idle: cpu3
   12 root        1 171 ki31     0K     8K CPU1   1 139.8H 65.58% idle: cpu1
   11 root        1 171 ki31     0K     8K CPU2   2 130.1H 65.09% idle: cpu2
   29 root        1 -68    -     0K     8K -      1  22.6H 33.59% em1 taskq
   30 root        1 -68    -     0K     8K -      2  34.8H 30.76% em2 taskq
   31 root        1 -68    -     0K     8K -      3  19.1H 27.59% em3 taskq
   28 root        1 -68    -     0K     8K -      0 811:03 18.16% em0 taskq
    5 root        1 -68    -     0K     8K sleep  0 174:31  6.49% ng_queue3
    3 root        1 -68    -     0K     8K sleep  0 175:31  6.30% ng_queue1
    4 root        1 -68    -     0K     8K sleep  0 175:42  5.96% ng_queue2
    2 root        1 -68    -     0K     8K sleep  0 173:54  5.86% ng_queue0

"BRAS", вопреки разговорам о mpd и ng_car на одной машине ищу этот глюк,

но за два месяца - всё стабильно

ng_queueX - это обработка ng_car&ng_bpf

трафик на if_lagg интерфейсе:

            input        (lagg0)           output
   packets  errs      bytes    packets  errs      bytes colls
     80086     0   67284257      79950     0   67176477     0
     65348     0   55208020      65224     0   55132644     0
     72699     0   61335162      72576     0   61204540     0
     77913     0   65184702      77785     0   65119166     0
     77797     0   66478451      77678     0   66373087     0

на другой стороне кабеля - Cisco 2960G

 

P.S. когда эта машина загнётся - понятия не имею,

когда начнуться проблемы, тогда начну крутить ручки

Edited by Giga-Byte

Share this post


Link to post
Share on other sites
Jab, я конечно понимаю, но расскажите в двух словах, почему?

Разные дистрибутивы рассматриваем?

   39 root        1  43    -     0K    16K WAIT    4 107.8H 21.83% em2_rx_kthread_0
   40 root        1  43    -     0K    16K WAIT    5 107.7H 21.83% em2_rx_kthread_1
  157 root        1  43    -     0K    16K WAIT    6  88.3H 20.21% em1_rx_kthread_3
  156 root        1  43    -     0K    16K CPU2    2  88.3H 20.12% em1_rx_kthread_2
   36 root        1  43    -     0K    16K WAIT    6  88.3H 19.82% em1_rx_kthread_1
   35 root        1  43    -     0K    16K CPU6    4  88.4H 19.48% em1_rx_kthread_0
  152 root        1  43    -     0K    16K WAIT    0  80.2H 17.92% em0_rx_kthread_2
   32 root        1  43    -     0K    16K CPU6    0  80.2H 17.92% em0_rx_kthread_1
   31 root        1  43    -     0K    16K WAIT    4  80.4H 17.68% em0_rx_kthread_0
  153 root        1  43    -     0K    16K WAIT    1  80.2H 17.29% em0_rx_kthread_3
   43 root        1  43    -     0K    16K WAIT    7  74.4H 14.79% em3_rx_kthread_0
   44 root        1  43    -     0K    16K WAIT    7  74.3H 14.79% em3_rx_kthread_1
   53 root        1 -68    -     0K    16K CPU1    1  62.6H 11.77% dummynet
   30 root        1 -68    -     0K    16K CPU0    0 634:03  1.66% em0_txcleaner
   34 root        1 -68    -     0K    16K WAIT    5 440:09  0.68% em1_txcleaner
   42 root        1 -68    -     0K    16K WAIT    6 320:23  0.00% em3_txcleaner
   38 root        1 -68    -     0K    16K WAIT    2 238:42  0.00% em2_txcleaner
   21 root        1 -44    -     0K    16K WAIT    7  47:31  0.00% swi1: net

 

Это если не вспоминать про igb(4) и ixgb(4)

Share this post


Link to post
Share on other sites
Jab, я конечно понимаю, но расскажите в двух словах, почему?

Разные дистрибутивы рассматриваем?

   39 root        1  43    -     0K    16K WAIT    4 107.8H 21.83% em2_rx_kthread_0
   40 root        1  43    -     0K    16K WAIT    5 107.7H 21.83% em2_rx_kthread_1
  157 root        1  43    -     0K    16K WAIT    6  88.3H 20.21% em1_rx_kthread_3
  156 root        1  43    -     0K    16K CPU2    2  88.3H 20.12% em1_rx_kthread_2
   36 root        1  43    -     0K    16K WAIT    6  88.3H 19.82% em1_rx_kthread_1
   35 root        1  43    -     0K    16K CPU6    4  88.4H 19.48% em1_rx_kthread_0
  152 root        1  43    -     0K    16K WAIT    0  80.2H 17.92% em0_rx_kthread_2
   32 root        1  43    -     0K    16K CPU6    0  80.2H 17.92% em0_rx_kthread_1
   31 root        1  43    -     0K    16K WAIT    4  80.4H 17.68% em0_rx_kthread_0
  153 root        1  43    -     0K    16K WAIT    1  80.2H 17.29% em0_rx_kthread_3
   43 root        1  43    -     0K    16K WAIT    7  74.4H 14.79% em3_rx_kthread_0
   44 root        1  43    -     0K    16K WAIT    7  74.3H 14.79% em3_rx_kthread_1
   53 root        1 -68    -     0K    16K CPU1    1  62.6H 11.77% dummynet
   30 root        1 -68    -     0K    16K CPU0    0 634:03  1.66% em0_txcleaner
   34 root        1 -68    -     0K    16K WAIT    5 440:09  0.68% em1_txcleaner
   42 root        1 -68    -     0K    16K WAIT    6 320:23  0.00% em3_txcleaner
   38 root        1 -68    -     0K    16K WAIT    2 238:42  0.00% em2_txcleaner
   21 root        1 -44    -     0K    16K WAIT    7  47:31  0.00% swi1: net

 

Это если не вспоминать про igb(4) и ixgb(4)

 

Это стандартные драйвера или драйвера от Яндекса?

 

Так как стандартно 1 сетевая карточка использует 1 ядро

Ну вот тогда зачем писать сразу "против".

 

Share this post


Link to post
Share on other sites
Это если не вспоминать про igb(4) и ixgb(4)
Это стандартные драйвера или драйвера от Яндекса?

igb и ixgb - драйвера от Intel'а.

Share this post


Link to post
Share on other sites
Это если не вспоминать про igb(4) и ixgb(4)
Это стандартные драйвера или драйвера от Яндекса?

igb и ixgb - драйвера от Intel'а.

Вы показали загрузку em, где em-модифицированный драйвер от яндекса, о нем я и спросил.

 

И исходя из текста первого поста, можно было догадаться, что тут не спрашивают про линукс или про igb, потому что в этих случаях такая проблема не стоит, хотя наверно ваш характер, судя по нику и постам, не сильно отличается от зеленого земноговодного животного.

Share this post


Link to post
Share on other sites
Вы показали загрузку em, где em-модифицированный драйвер от яндекса, о нем я и спросил.

Разве это был не риторический вопрос ?

 

И исходя из текста первого поста, можно было догадаться, что тут не спрашивают про линукс или про igb, потому что в этих случаях такая проблема не стоит

Особенно если учесть, что упоминание em в исходном посте волшебным образом появилось уже после того, как я ответил. :-)

Share this post


Link to post
Share on other sites

А с чего вдруг стало видно, что у em драйвера от Яндекса? Каждая сетевуха на своё ядро, всё по старому.

 

photon, поподробнее можно, с примерами? Ещё год назад был свидетелем, как восьмиядерный ксеоновый линуксовый сервер обрабатывал (NAT+ipcad) гигабитный трафик только, в сущности, двумя ядрами, остальные простаивали.

Edited by Dyr

Share this post


Link to post
Share on other sites

photon, поподробнее можно, с примерами? Ещё год назад был свидетелем, как восьмиядерный ксеоновый линуксовый сервер обрабатывал (NAT+ipcad) гигабитный трафик только, в сущности, двумя ядрами, остальные простаивали.

Это другое. Речь идет о приеме и передаче пакетов на уровне виртуальных устройств и драйверов сетевух, а вы говорите про NAT и тем более копирование пакетов в userland для обсчета в ipcad. В iptables от giant locks не до конца избавились еще, а ipcad представляет собой один процесс с одним тредом, вот и висит на одном процессоре. Проблемы с блокировками и производительностью в конкретных подсистемах ядра решаются только программированием. Для параллелизма нужны соответствующие алгоритмы и реентрабельность функций. Если речь идет о пользовательских процессах, то здесь тоже вся нагрузка по обеспечению параллелизма лежит на программисте. Я лишь говорю, что механизм обработки верхних половин прерываний поддерживает параллелизм и interface bonding тут дополнительного выигрыша не даст. За остальные подсистемы не скажу.

Edited by photon

Share this post


Link to post
Share on other sites
Это другое. Речь идет о приеме и передаче пакетов на уровне виртуальных устройств и драйверов сетевух, а вы говорите про NAT и тем более копирование пакетов в userland для обсчета в ipcad. В iptables от giant locks не до конца избавились еще, а ipcad представляет собой один процесс с одним тредом, вот и висит на одном процессоре.

:-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке.

Share this post


Link to post
Share on other sites

:-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке.

Да без разницы сколько там ног. Просто топикстартер ошибочно думает, что bonding магически улучшит параллелизм обработки трафика где-либо выше уровня драйверов устройств.

Share this post


Link to post
Share on other sites
Да без разницы сколько там ног. Просто топикстартер ошибочно думает, что bonding магически улучшит параллелизм обработки трафика где-либо выше уровня драйверов устройств.

Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?

 

:-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке.

Там не было разговора об одной сетевухи, там были слова, что одна сетевуха-одно ядро.

 

 

 

 

 

А с чего вдруг стало видно, что у em драйвера от Яндекса? Каждая сетевуха на своё ядро, всё по старому.

Ну это видно из его top'a который он привел.

Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров.

Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра.

Share this post


Link to post
Share on other sites
Ну это видно из его top'a который он привел.

Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров.

Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра.

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

Share this post


Link to post
Share on other sites
Ну это видно из его top'a который он привел.

Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров.

Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра.

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

И драйвера от яндекса?

Share this post


Link to post
Share on other sites
И драйвера от яндекса?

И драйвера от яндекса. По-моему там это четко видно. :-)))

Share this post


Link to post
Share on other sites
И драйвера от яндекса?

И драйвера от яндекса. По-моему там это четко видно. :-)))

Вот и я про тоже:

 

А с чего вдруг стало видно, что у em драйвера от Яндекса?

Share this post


Link to post
Share on other sites

Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?

Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding.

Share this post


Link to post
Share on other sites
Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?
Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding.

em, в FreeBSD?

Share this post


Link to post
Share on other sites
И драйвера от яндекса?

И драйвера от яндекса. По-моему там это четко видно. :-)))

Вот и я про тоже:

 

А с чего вдруг стало видно, что у em драйвера от Яндекса?

тот кто ставил, понимает.

в нативных нету параметра dev.em.X.rx_kthreads

 

Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?
Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding.

em, в FreeBSD?

как раз Владимир, aka wawa это и реализовал (а может и группой) в "em-yandex-driver"

Share this post


Link to post
Share on other sites
как раз Владимир, aka wawa это и реализовал (а может и группой) в "em-yandex-driver"

:-) Потом оказалось, что у Core Quad не один кэш, а два попарно, и все кинулись прибивать гвоздями треды к ядрам, чтобы уйти от деградации предикшина на глубоких конвейерах. :-)

Share this post


Link to post
Share on other sites
прибивать гвоздями треды к ядрам, чтобы уйти от деградации предикшина на глубоких конвейерах. :-)
а можно поподробнее и с методами?)

или хотя бы куда посмотреть

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
Sign in to follow this