В Срд, 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 дней, потому что ему не приходилось думать о проблемах обратной совместимости". Так вот во многих приложениях их настоящая архитектура - это пережиток прошлого, который дорого переделать. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
