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