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

[TiFFolk]

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

(FreeBSD,em)

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

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

 

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

 

---

 

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

Edited October 18, 2009 by TiFFolk

[jab]

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

Уже неверно.

[TiFFolk]

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

Уже неверно.

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

[photon]

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

Edited October 18, 2009 by photon

[Giga-Byte]

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

Уже неверно.

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

 

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

[Giga-Byte]

Так как стандартно 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 October 18, 2009 by Giga-Byte

[jab]

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)

[TiFFolk]

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 ядро

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

 

[jab]

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

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

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

[TiFFolk]

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

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

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

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

 

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

[jab]

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

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

 

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

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

[Dyr]

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

 

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

Edited October 19, 2009 by Dyr

[photon]

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

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

Edited October 19, 2009 by photon

[jab]

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

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

[photon]

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

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

[TiFFolk]

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

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

 

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

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

 

 

 

 

 

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

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

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

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

[jab]

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

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

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

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

[TiFFolk]

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

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

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

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

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

[jab]

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

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

[TiFFolk]

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

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

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

 

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

[photon]

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

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

[TiFFolk]

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

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

em, в FreeBSD?

[Giga-Byte]

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

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

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

 

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

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

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

 

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

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

em, в FreeBSD?

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

[jab]

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

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

[adeep]

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

а можно поподробнее и с методами?)

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