TiFFolk Опубликовано 17 октября, 2009 (изменено) · Жалоба Навеяно всякими мега-супер тестами производительности (FreeBSD,em) Так как стандартно 1 сетевая карточка использует 1 ядро, то если поставить dual карточку и объеденить два интерфейса мы получим две карточки, которые будут забирать по одному ядру каждое. Тем самым мы не только получим двойной буфер, но и распареллелим весь траффик на два ядра. Современные свитчи поддерживаю LACP. Те получим прирост в производительности на многопроцессорных машинах, даже если траффика меньше чем два гигабита, только за счет распараллеливания. --- А теперь вопрос: где я наврал? будет ли это работать? Изменено 18 октября, 2009 пользователем TiFFolk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 17 октября, 2009 · Жалоба Так как стандартно 1 сетевая карточка использует 1 ядро Уже неверно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 17 октября, 2009 · Жалоба Так как стандартно 1 сетевая карточка использует 1 ядро Уже неверно. Rx|Tx очереди обрабатываются только одним потоком Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 18 октября, 2009 (изменено) · Жалоба В Linux очередь из верхних половин обработчиков прерываний (softirq) обрабатываются несколькими тредами ksoftirqd, которых в SMP-ядрах всегда по одному на каждый процессор/ядро. Выигрыш от bonding будет скорее не в снижении нагрузки на процессор, а в уменьшении задержек и в увеличении устойчивости к DoS-атакам, т.к. пакеты будут обрабатываться сразу двумя аппаратными очередями. Изменено 18 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 18 октября, 2009 · Жалоба Так как стандартно 1 сетевая карточка использует 1 ядро Уже неверно. Jab, я конечно понимаю, но расскажите в двух словах, почему? Разные дистрибутивы рассматриваем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 18 октября, 2009 (изменено) · Жалоба Так как стандартно 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. когда эта машина загнётся - понятия не имею, когда начнуться проблемы, тогда начну крутить ручки Изменено 18 октября, 2009 пользователем Giga-Byte Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 18 октября, 2009 · Жалоба 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) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 18 октября, 2009 · Жалоба 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 ядро Ну вот тогда зачем писать сразу "против". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 18 октября, 2009 · Жалоба Это если не вспоминать про igb(4) и ixgb(4) Это стандартные драйвера или драйвера от Яндекса? igb и ixgb - драйвера от Intel'а. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 18 октября, 2009 · Жалоба Это если не вспоминать про igb(4) и ixgb(4) Это стандартные драйвера или драйвера от Яндекса? igb и ixgb - драйвера от Intel'а. Вы показали загрузку em, где em-модифицированный драйвер от яндекса, о нем я и спросил. И исходя из текста первого поста, можно было догадаться, что тут не спрашивают про линукс или про igb, потому что в этих случаях такая проблема не стоит, хотя наверно ваш характер, судя по нику и постам, не сильно отличается от зеленого земноговодного животного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 18 октября, 2009 · Жалоба Вы показали загрузку em, где em-модифицированный драйвер от яндекса, о нем я и спросил. Разве это был не риторический вопрос ? И исходя из текста первого поста, можно было догадаться, что тут не спрашивают про линукс или про igb, потому что в этих случаях такая проблема не стоит Особенно если учесть, что упоминание em в исходном посте волшебным образом появилось уже после того, как я ответил. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 19 октября, 2009 (изменено) · Жалоба А с чего вдруг стало видно, что у em драйвера от Яндекса? Каждая сетевуха на своё ядро, всё по старому. photon, поподробнее можно, с примерами? Ещё год назад был свидетелем, как восьмиядерный ксеоновый линуксовый сервер обрабатывал (NAT+ipcad) гигабитный трафик только, в сущности, двумя ядрами, остальные простаивали. Изменено 19 октября, 2009 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 октября, 2009 (изменено) · Жалоба photon, поподробнее можно, с примерами? Ещё год назад был свидетелем, как восьмиядерный ксеоновый линуксовый сервер обрабатывал (NAT+ipcad) гигабитный трафик только, в сущности, двумя ядрами, остальные простаивали. Это другое. Речь идет о приеме и передаче пакетов на уровне виртуальных устройств и драйверов сетевух, а вы говорите про NAT и тем более копирование пакетов в userland для обсчета в ipcad. В iptables от giant locks не до конца избавились еще, а ipcad представляет собой один процесс с одним тредом, вот и висит на одном процессоре. Проблемы с блокировками и производительностью в конкретных подсистемах ядра решаются только программированием. Для параллелизма нужны соответствующие алгоритмы и реентрабельность функций. Если речь идет о пользовательских процессах, то здесь тоже вся нагрузка по обеспечению параллелизма лежит на программисте. Я лишь говорю, что механизм обработки верхних половин прерываний поддерживает параллелизм и interface bonding тут дополнительного выигрыша не даст. За остальные подсистемы не скажу. Изменено 19 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 19 октября, 2009 · Жалоба Это другое. Речь идет о приеме и передаче пакетов на уровне виртуальных устройств и драйверов сетевух, а вы говорите про NAT и тем более копирование пакетов в userland для обсчета в ipcad. В iptables от giant locks не до конца избавились еще, а ipcad представляет собой один процесс с одним тредом, вот и висит на одном процессоре. :-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 октября, 2009 · Жалоба :-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке. Да без разницы сколько там ног. Просто топикстартер ошибочно думает, что bonding магически улучшит параллелизм обработки трафика где-либо выше уровня драйверов устройств. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 19 октября, 2009 · Жалоба Да без разницы сколько там ног. Просто топикстартер ошибочно думает, что bonding магически улучшит параллелизм обработки трафика где-либо выше уровня драйверов устройств. Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное? :-) Судя по фигурировавшем в исходном посте упоминании про одну сетевуху, речь шла об одноногой машинке. Там не было разговора об одной сетевухи, там были слова, что одна сетевуха-одно ядро. А с чего вдруг стало видно, что у em драйвера от Яндекса? Каждая сетевуха на своё ядро, всё по старому. Ну это видно из его top'a который он привел. Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров. Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 19 октября, 2009 · Жалоба Ну это видно из его top'a который он привел.Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров. Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра. Там где я приводил - четыре сетевухи, восемь логических ядер, и шестнадцать потоков на них. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 19 октября, 2009 · Жалоба Ну это видно из его top'a который он привел.Вот именно, что каждая сетевуха свое ядро не радионально в эпоху 4ъ ядерных процессоров. Так как обычно 2 сетевухи на 4 ядра, я спрашивал о распараллеливании обработки очередей на свободные ядра. Там где я приводил - четыре сетевухи, восемь логических ядер, и шестнадцать потоков на них. И драйвера от яндекса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 19 октября, 2009 · Жалоба И драйвера от яндекса? И драйвера от яндекса. По-моему там это четко видно. :-))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 19 октября, 2009 · Жалоба И драйвера от яндекса? И драйвера от яндекса. По-моему там это четко видно. :-))) Вот и я про тоже: А с чего вдруг стало видно, что у em драйвера от Яндекса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 октября, 2009 · Жалоба Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное? Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 19 октября, 2009 · Жалоба Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding. em, в FreeBSD? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 21 октября, 2009 · Жалоба И драйвера от яндекса? И драйвера от яндекса. По-моему там это четко видно. :-))) Вот и я про тоже: А с чего вдруг стало видно, что у em драйвера от Яндекса? тот кто ставил, понимает. в нативных нету параметра dev.em.X.rx_kthreads Я как раз думал на уровне драйверов устройств, с чего вы взяли обратное?Ну моя мысль была такой, что на уровне драйверов устройств нагрузка распределяется на несколько CPU даже без bonding. em, в FreeBSD? как раз Владимир, aka wawa это и реализовал (а может и группой) в "em-yandex-driver" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 21 октября, 2009 · Жалоба как раз Владимир, aka wawa это и реализовал (а может и группой) в "em-yandex-driver" :-) Потом оказалось, что у Core Quad не один кэш, а два попарно, и все кинулись прибивать гвоздями треды к ядрам, чтобы уйти от деградации предикшина на глубоких конвейерах. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adeep Опубликовано 21 октября, 2009 · Жалоба прибивать гвоздями треды к ядрам, чтобы уйти от деградации предикшина на глубоких конвейерах. :-)а можно поподробнее и с методами?)или хотя бы куда посмотреть Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...