Re: Функционал и интерфейс
Hello!
> > Предложенная вами архитектура не годится. Хотя бы потому, что 1
> > "слушающий" процесс всегда будет "узким местом".
>
> Не будет. Его задача состоит только в том чтобы делать read() на сокет
> клиенты и write() на сокет процесса выполняющего вычисления, потом
> обратно, и так по кругу для всех клиентов. Нагрузка около нуля.
Еще есть ненулевое время на открытие сокета, обработку заголовков запроса,
ожидание свободного процесса из пула процессов для вычислений и проч.
> > Далее, операции чтения с диска могут
> > выполняться параллельно многими процессами (есть кэш диска плюс кэш
> > операционной системы). И для записи даже для SATA-диска размер очереди
> > команд, равный 1, далеко не оптимум, а для SAS дисков тем более.
>
> Вопрос конечно спорный. Скажу только, что если не принимать во внимание
> кэш ФС то в один момент времени один винт может обрабатывать равно один
> запрос, поэтому чтение одним процессом может быть производительнее,
> особенно если его очередь постарается сделать чтение более
> последовательным.
Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная очередь
равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска может
переставлять команды в очереди так, чтобы требовалось минимальное кол-во
перемещений головки. Для SSD дисков и вовсе параллельное чтение заложено в
архитектуре.
> Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
> кэшировать прям в процессе.
>
> Хотя стой, не надо плодить процессы и встраивать кэш. В любом случае
> один процесс читающий последовательно будет не медленее чем два
> параллельно. Кэш ФС тут помощник как в первом случае так и во втором.
В пределах оптимальной очереди команд для диска и при помощи кэша ФС каждый из
параллельных процессов чтения будет работать не медленнее, чем если бы он был
единственный. То есть запуск N процессов чтения увеличит производительность в
N раз при оптимальной нагрузке (линейно). Понятно, что при возрастании
нагрузки линейной зависимости уже не будет.
> > Не говоря уже о бессмысленности создания "бутылочного горла"
> > между читающими и вычисляющими процессами.
>
> Не знаю, на сколько это узкое горло, но если перейти от сокетов/пайпов к
> общей памяти или от процессов к нитям с общей памятью, этот вопрос точно
> отпадёт.
Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска?
Данные обрабатываемого запроса в других процессах/потоках никому просто не
нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже рассмотрено
выше. А насчет общей памяти - от этого решения уже и многие СУБД отказываются.
В результате использования shared memory тот же оракл масштабируется намного
хуже терадата. PostgreSQL так же использует shared memory, что приводит к
различным проблемам. Я уж не говорю про сложность такого решения.
> Я не пытаюсь угадать, я пытаюсь размышлять.
Размышления строятся на основе фактов, а не на догадках.
Best regards.
Reply to: