Re: Функционал и интерфейс
В Срд, 18/03/2009 в 19:35 +0300, Alexey Pechnikov пишет:
> Hello!
>
> > > Еще есть ненулевое время на открытие сокета, обработку заголовков
> > > запроса, ожидание свободного процесса из пула процессов для вычислений и
> > > проч.
> >
> > Да, но это уже ботаника, без измерений нечего тут сказать.
>
> Вам гугл за неуплату отключили? :-)
>
> > > Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная
> > > очередь равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска
> > > может переставлять команды в очереди так, чтобы требовалось минимальное
> > > кол-во перемещений головки.
> >
> > Это NCQ на сколько я понял. Хорошая вещь, что бы сделать более
> > последовательным набор параллельных запросов. Где тут логика? Или я
> > всё-таки чего-то не понимаю, у SATA винтов головки независимо читают?
>
> Пример - нужно нам прочитать сколько-то блоков в 100 запросах. Если
> планировщик очереди получает все 100 запросов сразу и может их выполнить в
> один оборот диска, это будет в примерно в 100 раз быстрее, чем когда вы
> отправляете каждый запрос после завершения предыдущего.
Давай продолжим в треде "Скорость чтения с диска <последовательно одним
процессом> VS <параллельно несколькими>"
> >
> > > Для SSD дисков и вовсе параллельное чтение заложено в
> > > архитектуре.
> >
> > Про это в Инете не нашёл, можно ссылку?
>
> Посмотрите сколько чипов памяти стоит в SSD дисках. Каждый чип работает
> независимо, так что все лимитируется лишь контроллером.
>
> > > В пределах оптимальной очереди команд для диска и при помощи кэша ФС
> > > каждый из параллельных процессов чтения будет работать не медленнее, чем
> > > если бы он был единственный. То есть запуск N процессов чтения увеличит
> > > производительность в N раз при оптимальной нагрузке (линейно). Понятно,
> > > что при возрастании нагрузки линейной зависимости уже не будет.
> >
> > Как раз наоборот. Больше параллельных процессов пытающихся прочитать -
> > меньшая линейность чтения, NCQ, конечно как-то сгладит... Кто-нибудь
> > располагает результатами тестов?
>
> Утилиты для измерения io performance есть в дебиане. Возьмите и проверьте.
>
> > > Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?
> >
> > Нет. Буферы запросов и ответов, чтоб большие потоки по пайпам не гонять
> > туда-сюда.
>
> Ха.
>
> > > Данные обрабатываемого запроса в других процессах/потоках никому просто
> > > не нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже
> > > рассмотрено выше. А насчет общей памяти - от этого решения уже и многие
> > > СУБД отказываются. В результате использования shared memory тот же оракл
> > > масштабируется намного хуже терадата. PostgreSQL так же использует shared
> > > memory, что приводит к различным проблемам. Я уж не говорю про сложность
> > > такого решения.
> >
> > Ссылки на обсуждения можно посмотреть? Любая вещь используемая не по
> > назначению имеет свойство превращаться в грабли...
>
> На обсуждение чего, простите? У всех названных продуктов есть веб-сайты, где
> вы можете найти документацию и обсуждения.
>
> > Я считаю, что глупо думать, что раз apache2 так устроенна то это
> > наиболее оптимальный вариант.
>
> Я не знаю, как устроен apache2.
>
> > Так вот во многих приложениях их настоящая архитектура -
> > это пережиток прошлого, который дорого переделать.
>
> Ага, например, архитектура жестких дисков :-) Или живите с ней, или ставьте
> себе SSD, что сейчас уже возможно сделать.
>
> Best regards.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: