Перейти к содержимому
Калькуляторы

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

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

(FreeBSD,em)

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

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

 

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

 

---

 

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

Изменено пользователем TiFFolk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Уже неверно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Уже неверно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Уже неверно.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так как стандартно 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. когда эта машина загнётся - понятия не имею,

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

Изменено пользователем Giga-Byte

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это если не вспоминать про igb(4) и ixgb(4)
Это стандартные драйвера или драйвера от Яндекса?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это если не вспоминать про igb(4) и ixgb(4)
Это стандартные драйвера или драйвера от Яндекса?

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

 

 

 

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

em, в FreeBSD?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

 

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

em, в FreeBSD?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.