Беседа.

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Беседа.

mitrofanzzz

Доброго времени суток уважаемое сообщество. Волею случая периодчески
общаюсь "ВКонтакте" и завязалась интересная беседа, но так как опыта
масштабного использования не имею, хотел бы поделиться с Вами и услышать
конструктивные разъяснения. Сразу вношу ясность - Никита
"злой_хреноплёт" Сохин - это я, Дмитрий Шварц - это не я.

Итак цитирую:

Никита "злой_хреноплёт" Сохин
8 мар 2010 в 21:21
постараюсь никого не обидеть. официальной точки зрения опенбздовцев я не
знаю, но в особо специфичных случаях мне всегда в голову приходит одна
фраза - If you want something, don`t ask, just hack... Собственно ты в
некоей мере это воплотил, нашел где этот вопрос уже решен. А термин
гугление как раз описывает процесс которым ты пришел к этому решению ;-)

Дмитрий Шварц
17 мар 2010 в 7:38
ОпенБСД на десктопе это не миф ))) ..... если ты очень аскетичен. И все
равно, лучше всего будет работать линь, простой незамороченный линь, арч
подходит как никуда лучше. ОпенБСД интересная ось, она не на все сервера
подойдет так же, скажем много трафа и у тебя снм камень, то валится
будет по прерываниям, если две разные сетевки, то будет затупы и
провалы. А вот если ты параноик, ты работаешь в серьезной конторе, где
секурити не просто слова, то пень как нельзя кстати ... у него код
чистенький, вылизанный, а ядро просто блеск. Да, теряются всякие
вкусняшки, но посути, что противоречит политики безопасности, идет оно
нахер ) ....

Никита "злой_хреноплёт" Сохин
19 мар 2010 в 8:23
>ОпенБСД интересная ось, она не на все сервера подойдет так же, скажем
>много трафа и у тебя снм камень, то валится будет по прерываниям, если
>две разные сетевки, то будет затупы и провалы.

Простите, но откуда такая информация?

Дмитрий Шварц
19 мар 2010 в 10:29
Прощаю ) ... я просто очень плотно работаю с ОпенБСД, я люблю эту ось,
мне нравится философия Тео. Так же есть такие моменты, которые меня в
ней не устраивают и я щас веду разработку форка опенка, точнее я точу
его под свои нужды ) ... А информация выявлена опытным путем, когда у
меня районные маршрутизаторы базировались на пне ) ... Щас переползли на
циски, но все равно ... пень мне ближе, родней .... это пень ... его
нада понять, прочувствовать .... если сравнивать с той же фряхой, он
гораздо мне приятней, я разбираюсь в системном программирование и код
пня мне очень, очень нравится. Это настойщий уникс-вей!....

Никита "злой_хреноплёт" Сохин
19 мар 2010 в 16:59
В рассылки писать не пробовали? Возможно ваши проблемы уже давно
решены...

Дмитрий Шварц
вчера в 12:35
Не решены. Банально, попробуй на пне тспдампом захватить поток в 100Mb,
анализ большого трафика нереален. Я щас на сях пишу демон, который будет
балансером между N машинами. На данный момент интересен балансер для
почты. А то у меня там фильтрация дикая и мне не нравится большие вайты
на сервере.

Никита "злой_хреноплёт" Сохин
вчера в 19:23
хм занятно, вы не будете против если я нашу беседу кину в рассылку по
опен бсд, уважаемые знатоки возможно подскажут или подтвердят...

Конец цитаты.

В связи с чем вопрос, действительно ли все так как описал Дмитрий Шварц?

--
С уважением Сохин Никита Александрович...


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Anton Maksimenkov-2
23 марта 2010 г. 9:26 пользователь mitrofanzzz <[hidden email]> написал:
> подойдет так же, скажем много трафа и у тебя снм камень, то валится будет по
> прерываниям, если две разные сетевки, то будет затупы и провалы. А вот если
...
> Не решены. Банально, попробуй на пне тспдампом захватить поток в 100Mb,
> анализ большого трафика нереален. Я щас на сях пишу демон, который будет
...
> В связи с чем вопрос, действительно ли все так как описал Дмитрий Шварц?

Если "валится по прерываниям" имеется ввиду, что на большом трафике
количество прерываний становится огромным и проц уже не успевает всё
это обрабатывать и предел пропускной способности наступает раньше
чем... то вобщем-то это так.
Затык в том, что почти всё ядро пока что работает в пределах одного
процессора. Если основная работа машины проходит в ядре, то
многопроцессорность не поможет.
Так что две и более сетевух - один чёрт одним процессором будут
попеременке обрабатываться. Захват потока и тому подобное - тоже всё
это в ядре, да ещё и копируется (bpf), так что тоже на одном и том же
процессоре.
В итоге - 2 сетевухи, да плюс tcpdump потока - вот уже все 3 задачи на
одном проце. Ну и так далее.

Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить
пропускной, ну или скорее отклик поживее будет. Но это так, полдела.
Распараллелить обработку прерываний надо. А распараллелить сетевой
стек, да ещё эффективно - это целое дело, фрибсдэвцы на это вроде
навалились; когда результаты будут пока не известно. Там задача не
просто распараллелить, а ещё и сделать это так, чтобы возможно большую
времени удерживаться в пределах кэшей процессоров (чтобы
производительность-то не просела)... вобщем проблем куча.
Кто, когда и зачём их будет решать - непонятно.
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Igor Zinovik-3
> Затык в том, что почти всё ядро пока что работает в пределах одного
> процессора. Если основная работа машины проходит в ядре, то
> многопроцессорность не поможет.
> Так что две и более сетевух - один чёрт одним процессором будут
> попеременке обрабатываться. Захват потока и тому подобное - тоже всё
> это в ядре, да ещё и копируется (bpf), так что тоже на одном и том же
> процессоре.
> В итоге - 2 сетевухи, да плюс tcpdump потока - вот уже все 3 задачи на
> одном проце. Ну и так далее.
>
> Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить
> пропускной, ну или скорее отклик поживее будет. Но это так, полдела.
> Распараллелить обработку прерываний надо. А распараллелить сетевой
> стек, да ещё эффективно - это целое дело, фрибсдэвцы на это вроде
> навалились; когда результаты будут пока не известно. Там задача не
> просто распараллелить, а ещё и сделать это так, чтобы возможно большую
> времени удерживаться в пределах кэшей процессоров (чтобы
> производительность-то не просела)... вобщем проблем куча.

Будет ли отказ (в смысле не использование) от ядерной блокировки
(giant lock) решением этой проблемы?
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

irix
In reply to this post by Anton Maksimenkov-2
Hello Anton,

Прошу прощения что встрял с офф топиком но может кто-то знает, всё что
ниже написано в NetBSD 5(или Current) и Linux реализовано ?

Если  нет,  написашите что реализовано. Прошу прощения что оффтопик но
очень интересно.

AM> Если "валится по прерываниям" имеется ввиду, что на большом трафике
AM> количество прерываний становится огромным и проц уже не успевает всё
AM> это обрабатывать и предел пропускной способности наступает раньше
AM> чем... то вобщем-то это так.
AM> Затык в том, что почти всё ядро пока что работает в пределах одного
AM> процессора. Если основная работа машины проходит в ядре, то
AM> многопроцессорность не поможет.
AM> Так что две и более сетевух - один чёрт одним процессором будут
AM> попеременке обрабатываться. Захват потока и тому подобное - тоже всё
AM> это в ядре, да ещё и копируется (bpf), так что тоже на одном и том же
AM> процессоре.
AM> В итоге - 2 сетевухи, да плюс tcpdump потока - вот уже все 3 задачи на
AM> одном проце. Ну и так далее.

AM> Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить
AM> пропускной, ну или скорее отклик поживее будет. Но это так, полдела.
AM> Распараллелить обработку прерываний надо. А распараллелить сетевой
AM> стек, да ещё эффективно - это целое дело, фрибсдэвцы на это вроде
AM> навалились; когда результаты будут пока не известно. Там задача не
AM> просто распараллелить, а ещё и сделать это так, чтобы возможно большую
AM> времени удерживаться в пределах кэшей процессоров (чтобы
AM> производительность-то не просела)... вобщем проблем куча.
AM> Кто, когда и зачём их будет решать - непонятно.



--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Беседа.

Ruslan Nekoz
Немного этих ваших сетевух, курить
http://www.intel.com/Assets/PDF/general/linecard_ec.pdf
Ключевые слова для поиска в доке и в гугле  MSI и MSI-X.
При прямых руках заводится и работает.

 
> AM> Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить
> AM> пропускной, ну или скорее отклик поживее будет. Но это
> так, полдела.
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4963 (20100321) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Anton Maksimenkov-2
23 марта 2010 г. 16:56 пользователь Ruslan Nekoz
<[hidden email]> написал:
> Ключевые слова для поиска в доке и в гугле  MSI и MSI-X.
>> AM> Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить

Это не то.
Интерупт митигэйшэн/коалесцинг и тому подобные словоблудия... это
когда не на каждый пакет прерывание дёргается, а сначала копится пачка
и потом дёргается прерывание. Чтобы процессор "отвлёкся" один раз, а
обработал за один проход целую пачку. В итоге - меньше "туда-сюда",
больше времени на полезную работу.

Интересно было бы услышать какой профит нам даёт MSI* хотя бы в теории
(отрывание проводка не в счёт).
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Dinar Talypov
In reply to this post by Igor Zinovik-3
>
> Будет ли отказ (в смысле не использование) от ядерной блокировки
> (giant lock) решением этой проблемы?
>
отчасти будет решением, но вопрос как отказаться от giant lock?
FreeBSD шло к этому около 10 лет.
Там все завязано на thread'ах, соответственно прерывание исполняется в контексте thread'а,
следовательно может шедулится на разные процессоры(это уже от шедулера зависит).

В опене, пока такого нет, все выполняется в процеесе ядра, а ядро на бутовом процессоре.

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

RE: Беседа.

Ruslan Nekoz
In reply to this post by Anton Maksimenkov-2
1.Меседж был в том что таких сетевух совсем немного.
2.На форуме nag.ru (это не реклама) можно поискать, там люди описывают
системы\нагрузки. Насчет опенка не встречал, пользуют в основном линь и фрю.


 

> -----Original Message-----
> From: Anton Maksimenkov [mailto:[hidden email]]
> Sent: Tuesday, March 23, 2010 6:33 PM
> To: [hidden email]
> Subject: Re: Беседа.
>
> 23 марта 2010 г. 16:56 пользователь Ruslan Nekoz
> <[hidden email]> написал:
> > Ключевые слова для поиска в доке и в гугле  MSI и MSI-X.
> >> AM> Сетевухи умеющие интеррупт митигэйшион отчасти могут добавить
>
> Это не то.
> Интерупт митигэйшэн/коалесцинг и тому подобные словоблудия...
> это когда не на каждый пакет прерывание дёргается, а сначала
> копится пачка и потом дёргается прерывание. Чтобы процессор
> "отвлёкся" один раз, а обработал за один проход целую пачку.
> В итоге - меньше "туда-сюда", больше времени на полезную работу.
>
> Интересно было бы услышать какой профит нам даёт MSI* хотя бы
> в теории (отрывание проводка не в счёт).
> --
> antonvm
>  
>
> __________ Information from ESET NOD32 Antivirus, version of
> virus signature database 4963 (20100321) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>  
>
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4963 (20100321) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

irix
In reply to this post by Dinar Talypov
Hello Dinar,

А как это в NetBSD 5 реализовали ?

Wednesday, March 24, 2010, 7:52:49 AM, you wrote:

>>
>> Будет ли отказ (в смысле не использование) от ядерной блокировки
>> (giant lock) решением этой проблемы?
>>
DT> отчасти будет решением, но вопрос как отказаться от giant lock?
DT> FreeBSD шло к этому около 10 лет.
DT> Там все завязано на thread'ах, соответственно прерывание
DT> исполняется в контексте thread'а,
DT> следовательно может шедулится на разные процессоры(это уже от шедулера зависит).

DT> В опене, пока такого нет, все выполняется в процеесе ядра, а ядро на бутовом процессоре.




--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Dinar Talypov
On Wed, 24 Mar 2010 11:13:32 +0200
irix <[hidden email]> wrote:

> Hello Dinar,
>
> А как это в NetBSD 5 реализовали ?
>
Примерно так же через LWP(lighweighted process) и scheduler activations.

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

irix
Hello Dinar,

А как опёношники хотят ?

Wednesday, March 24, 2010, 11:20:23 AM, you wrote:

DT> On Wed, 24 Mar 2010 11:13:32 +0200
DT> irix <[hidden email]> wrote:

>> Hello Dinar,
>>
>> А как это в NetBSD 5 реализовали ?
>>
DT> Примерно так же через LWP(lighweighted process) и scheduler activations.




--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Stanislav Kruchinin
In reply to this post by Ruslan Nekoz
On 24.03.2010 10:56, Ruslan Nekoz wrote:
> 1.Меседж был в том что таких сетевух совсем немного.

Серверные сетевухи Intel и Broadcom на PCIe поддерживают. В Linux-драйверах по
умолчанию включен NAPI, т.е. работает адаптивный rx polling. Прерывания как-бы и
не используются.

> 2.На форуме nag.ru (это не реклама) можно поискать, там люди описывают
> системы\нагрузки. Насчет опенка не встречал, пользуют в основном линь и фрю.

А что вы хотите от провайдеров, использующих топовое железо под PC-роутеры? Это
не SOHO какое-то, где дохлые Соекрисы справятся. Опен не используют для таких
задач прежде всего потому, что он не масштабируется на SMP. Проблемы с портами и
неандертальская система инициализации -- это вторично.


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Dinar Talypov
In reply to this post by irix
> А как опёношники хотят ?
>
похоже что-то свое затеяли. Хотя лучше у них спросить.
--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

RE: Беседа.

Ruslan Nekoz
In reply to this post by Stanislav Kruchinin

> Серверные сетевухи Intel и Broadcom на PCIe поддерживают. В
> Linux-драйверах по умолчанию включен NAPI, т.е. работает
> адаптивный rx polling. Прерывания как-бы и не используются.
>

Насчет броадкома не уверен - есть где почитать?
Прерывания как-бы используются %)


> > 2.На форуме nag.ru (это не реклама) можно поискать, там
> люди описывают
> > системы\нагрузки. Насчет опенка не встречал, пользуют в
> основном линь и фрю.
>
> А что вы хотите от провайдеров, использующих топовое железо
> под PC-роутеры? Это не SOHO какое-то, где дохлые Соекрисы
> справятся. Опен не используют для таких задач прежде всего
> потому, что он не масштабируется на SMP. Проблемы с портами и
> неандертальская система инициализации -- это вторично.
>

Таки да.
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4963 (20100321) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Anton Maksimenkov-2
In reply to this post by Dinar Talypov
>> Будет ли отказ (в смысле не использование) от ядерной блокировки
>> (giant lock) решением этой проблемы?
> отчасти будет решением, но

Тут надо понять - а что собсно надо?

А надо то, чтобы, например, обработка разных пакетов (обработка
прерывания, pf, роутинг, сокеты... хотя это и разные "части") могла
идти параллельно на разных процах. Тут всякие проблемы и зависимости.
Например, обрабатывать прерывания должен каждый цпу (если сетевуха
одна, то прерывания нужно динамично перенастраивать на разные цпу,
если несколько - опять же как-то раскидывать поровну по нагрузке), и в
процессе этого нужно файнграинед блокировками это всё обложить, чтобы
параллельно работающие обработчики на разных цпу не покрошили что-то.
Затем каждый цпу должен и дальше параллельно обрабатывать пакет - pf,
роутинг, сокеты... Всё это тоже нужно блокировками обложить внутри.
Где-то придётся синхронизироваться (чтобы "следующие" пакеты не
обгоняли "предыдущие", опять же ALTQ вообще думать надо, и так далее),
отслеживать какой цпу спешит и недогружен работой, а какой запаздывает
и перегружен прерываниями, пере-расчитывать-распределять прерывания...
Ну и ещё куча всяких "если" и проверок; хотя и вышеперечисленное
перераспределение и блокировки само по себе надо ещё сделать и
наладить.
Потом такая же разминка например для дискового I/O. А по уму бы и
подсистему памяти распараллелить, а то все будут постоянно тыкаться в
общую затычку.

Гигант лок или файн-граинед локи - это только инструменты. С их
помощью надо делать. Много.
Так много, что возможно даже лучше что-то в консерваториях поменять...
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Dinar Talypov

> Гигант лок или файн-граинед локи - это только инструменты. С их
> помощью надо делать. Много.
> Так много, что возможно даже лучше что-то в консерваториях поменять...
опять таки как достичь этого пресловутого fine-gained lock'а?
1) представить все что творится в ядре тредами, тогда задачи распаралеливания
выглядит как управление тредами внутри ядра, т.е. аналог того что есть в юзерланде - многозадачность
реализуется просто переключением задач с учетом времени выполнения (timesharing)
2) что-то другое, хотя скорее всего другого не дано. Если только запускать микроядра на каждом процессоре.

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Alexander Yurchenko-3
2010/3/25 Dinar Talypov <[hidden email]>:
> 2) что-то другое, хотя скорее всего другого не дано. Если только запускать микроядра на каждом процессоре.

Это правильный путь. F5 так делают например, на каждом ядре крутится
свой образ ОС.

> --
> Динар Талыпов

--
Alexander Yurchenko
Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Pavel Labushev-3
In reply to this post by Dinar Talypov
25.03.2010 13:49, Dinar Talypov пишет:

> 2) что-то другое, хотя скорее всего другого не дано. Если только запускать микроядра на каждом процессоре.

Другое дано, но, похоже, не опену с его эволюционным подходом. Например,
как оно должно быть (и частично уже есть) в стрекозе:
http://leaf.dragonflybsd.org/~aggelos/netmp-paper.pdf


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Dinar Talypov
On Thu, 25 Mar 2010 17:57:13 +0700
Pavel Labushev <[hidden email]> wrote:

> 25.03.2010 13:49, Dinar Talypov пишет:
>
> > 2) что-то другое, хотя скорее всего другого не дано. Если только запускать микроядра на каждом процессоре.
>
> Другое дано, но, похоже, не опену с его эволюционным подходом. Например,
> как оно должно быть (и частично уже есть) в стрекозе:
> http://leaf.dragonflybsd.org/~aggelos/netmp-paper.pdf
>
Это из 1 пункта, те же самые нити, привязанные к процессору, ничего нового


--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Беседа.

Pavel Labushev-3
25.03.2010 18:08, Dinar Talypov пишет:

>> Другое дано, но, похоже, не опену с его эволюционным подходом. Например,
>> как оно должно быть (и частично уже есть) в стрекозе:
>> http://leaf.dragonflybsd.org/~aggelos/netmp-paper.pdf
>>
> Это из 1 пункта, те же самые нити, привязанные к процессору, ничего нового

Как-то вы очень сплеча обобщаете. Те же самые, что и где? Ничего нового
по сравнению с чем?

В стрекозе большая часть сетевого стека построена на несколько других
тредах, которые по свойствам ближе к микроядрам: (почти) нет данных в
совместном доступе, нет потребности в fine-grained-схемах блокировки.
IPC - на базе обмена сообщениями, в том числе асинхронного. Да и система
в целом спроектирована с прицелом на простоту. Тратить годы в погоне за
fine-grained-локами там просто негде. Короче говоря, некорректно было бы
ставить ядро стрекозы в один ряд с монолитами, вроде линукса и ядер
других BSD.


12