Сервер для фильмов или VDS c большим HDD от 500 Гб.

Замечательно когда метаданные лежат в памяти, а с данными вы что то делаете? :)

Тут многие реализовывали подобные вещи и понимают, что физические возможности логикой не обмануть

Пока ваши сообщения тут выглядят как "вы не можете, а я могу".

Давайте подробности: сколько данных, размер каждого файла, количество потоков, общая ширина используемой ими полосы (графические данные воспринимаются легче)

Что вы там реализовывали? Физические возможности как раз достаточные, нужно всего по 60 мбайт с диска тянуть, а это случайными 2+ мегабайтными блоками любой диск сможет. Только вот никаких "сколько потоков" быть не может, поток один на диск, отдельный и читать с диска он должен мимо кэша файловой системы. Клиентов может быть столько, сколько хватит оперативки под их буферы.

Есть еще вариант попроще, это read ahead, читать с диска в обычном режиме мелкими запросами, но давать ему складывать в кэш фс по пару мегабайт наперед, пока не много клиентов - будет работать, а потом в какой-то непредсказуемый момент резко начнутся тормоза.

Не удивлен :)

Потоков скачивания имелось ввиду.

Данных, о которых я писал выше, я так понимаю, ждать не стоит. Спасибо за теорию.

Не храню графики многолетней давности, сори.

UPD: ТС если еще надо, пиши в личку, из спортивного интереса посмотрю, что можно выжать в текущей конфигурации.

И толку, я же говорю, при такой схеме все равно гигабит с 2-х дисков при условиях ТС никак не потянуть, может удастся мбит 300 и то, чем больше будет файлов, а их количество будет только расти, тем хуже будет дискам. zzzit я использую кучу схем в том числе aio+directio, и sendfile. с двух обычных сата-дисков при чем сата2 с условиями тс ну никак не потянуть гигабит, разве что десяток очень популярных файлов кешить в tmpfs а остальное раздавать с дисков aio+directio (такое тоже делали, оперы правда поболее было), но тут еще надо смотреть список открытых файлов, имеет ли смысл что-то кешить, или там равномерные обращения ко всем файлам.

По 18 мбайт/с с диска чтоли? Несеръезно.

Оба метода и через sendfile и через aio (речь об nginx'е, правильно?), не гарантируют, что к диску не будет параллельных обращений. Потому и так плохо.

Эм, а как обслуживать клиентов, по очереди? Один скачал, даем второму? Интересно, сколько юзеров останется у ТС при такой схеме. Или что Вы имеете ввиду под "параллельными обращениями"?

---------- Добавлено 21.07.2013 в 20:38 ----------

Ну, тут я соврал немного, можно в принципе с 4-х дисков гигабит, то есть ТСу с двух можно будет вытянуть 500 Мбит/с и то до поры до времени, мое лично наблюдение, как только диск заполняется больше чем на 75% он все меньше и меньше отдает по скорости.

Смотрите, если несколько запросов пришли одновременно они могут быть обработаны двумя способами: послать все их в ядро и ждать ответов от всех сразу постепенно посылая запросы еще, как в случае с aio или послать один запрос на 2 мегабайта, подождать ответа, послать второй, подождать ответа, послать третий, подождать ответа и т.д. В первом случае они будут обрабатываться на усмотрение планироващика, который будет стараться угодить всем сразу в ущерб пропускной способности, а во втором случае у планировщика всегда только один запрос и полный контроль над тем, сколько данных за один запрос мы можем получить остается у нас и позволяет минимизировать количество позиционирований головки. Естественно, если пришло 3 запроса и ответ от диска занимает 30 мс, то первый клиент начнет получать ответ через 30 мс, второй через 60 мс, третий через 90 мс, но это незаметно для посетителей.

zzzit, и что это за планировщик такой?

А теперь все то же самое в масштабах http://highload.biz/ru/faq/#1. А именно 2250 одновременных просмотров... ну хорошо, всего 500 пользователей смотрят фильмЫ.

Лень считать, но или кто-то ждет "вечность", или опять возвращаемся к уменьшению порционности и затыкам в IO.

---------- Добавлено 22.07.2013 в 00:17 ----------

Сферический, вакуумный...