В Срд, 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. -- Покотиленко Костик <cas...@meteor.dp.ua> -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org