The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Итоги встречи разработчиков OpenBSD в Словении: nginx займет..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Для слежения за появлением новых сообщений в нити, нажмите "Проследить за развитием треда".
. "Итоги встречи разработчиков OpenBSD в Словении: nginx займет..." +/
Сообщение от PereresusNeVlezaetBuggy (ok), 08-Окт-11, 19:30 
>> Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда
>> медленнее, чем его может жевать процессор.
> Это на сейчас неверный подход и самоуспокоение.  Конкретно у меня на
> сборочном ноуте сейчас основной упор именно в процессор -- поскольку сборка
> в tmpfs и SSD.

Сборка как бы всегда нагружала в первую очередь процессор. ;) А в случае tmpfs говорить про ввод-вывод вообще не особо уместно. ;) И главное, причём тут самоуспокоение, если сборка как раз идёт не в ядре? :)

> Причём вычислительная мощность одного процессорного ядра скорее остановилась, а I/O призадумалось
> только на HDD, и то 500Mb/s sustained write было не в
> диковинку на железе дешевле $3000 опять же лет пять тому (помнится,
> HP DL385 с P400i и 6/8? 2.5" SAS HDD).

МегаБАЙТ или мегаБИТ? ;)

>> Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись)
>> эдак гигабайт в секунду?
> Это они у нас и пять лет тому умели, если уже не
> больше (одна 16-портовая Areca затыкалась, но две восьмипортовки в тупом режиме
> более-менее справлялись).  Сейчас же при необходимости организовать такой поток цена
> вопроса -- меньше килобакса.

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

Я как бы не спорю, что параллелизация ввода-вывода в ядре в общем случае, как фича - это хорошо. Просто задачи, при которых она становится жизненно необходимой, далеко не самые распространённые. Хотя, конечно, кто-то по роду деятельности может постоянно сталкиваться с оными, и от этого зачастую начинает казаться, что всё крутится вокруг этих задач. :)

>> Не, конечно, можно при желании достаточно современный SCSI-контроллер засунуть
>> в машину с процом пятилетней давности, и наблюдать, как проц захлёбывается,
>> но мы-то говорим о реальных задачах, не?
> Поправочка: современный SCSI-контроллер в той машине будет себя чувствовать как родной.
>  Вероятно, подразумевались SAS/FC HBA. :)

Эм, а чем это SAS не SCSI? :)

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Итоги встречи разработчиков OpenBSD в Словении: nginx займет..., opennews, 24-Сен-11, 11:34  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру