Andron_buton: Эм, а как обслуживать клиентов, по очереди? Один скачал, даем второму? Интересно, сколько юзеров останется у ТС при такой схеме. Или что Вы имеете ввиду под "параллельными обращениями"?
Смотрите, если несколько запросов пришли одновременно они могут быть обработаны двумя способами: послать все их в ядро и ждать ответов от всех сразу постепенно посылая запросы еще, как в случае с aio или послать один запрос на 2 мегабайта, подождать ответа, послать второй, подождать ответа, послать третий, подождать ответа и т.д. В первом случае они будут обрабатываться на усмотрение планироващика, который будет стараться угодить всем сразу в ущерб пропускной способности, а во втором случае у планировщика всегда только один запрос и полный контроль над тем, сколько данных за один запрос мы можем получить остается у нас и позволяет минимизировать количество позиционирований головки. Естественно, если пришло 3 запроса и ответ от диска занимает 30 мс, то первый клиент начнет получать ответ через 30 мс, второй через 60 мс, третий через 90 мс, но это незаметно для посетителей.
Andron_buton: я использую кучу схем в том числе aio+directio, и sendfile
Оба метода и через sendfile и через aio (речь об nginx'е, правильно?), не гарантируют, что к диску не будет параллельных обращений. Потому и так плохо.
Саша Фоменс: Согласитесь, что мы все люди и взаимоотношения должны быть человеческими, никто никому не дает право грубить и хамить. А если уж и сорвался - будь добр ответить за свой поступок.
Не соглашусь. Лучше согласитесь, что мы все люди и у всех есть эмоции, и грубить и хамить вполне по человечески.
klamas: Тут многие реализовывали подобные вещи и понимают, что физические возможности логикой не обмануть
Что вы там реализовывали? Физические возможности как раз достаточные, нужно всего по 60 мбайт с диска тянуть, а это случайными 2+ мегабайтными блоками любой диск сможет. Только вот никаких "сколько потоков" быть не может, поток один на диск, отдельный и читать с диска он должен мимо кэша файловой системы. Клиентов может быть столько, сколько хватит оперативки под их буферы.
Есть еще вариант попроще, это read ahead, читать с диска в обычном режиме мелкими запросами, но давать ему складывать в кэш фс по пару мегабайт наперед, пока не много клиентов - будет работать, а потом в какой-то непредсказуемый момент резко начнутся тормоза.
Andron_buton: zzzit, ага, "если", "чтобы", "чтобы", это уже называется исключение. Еще раз, у ТС много файлов, мало дисков и оперы, тут "большие куски" никак не помогут выжать гигабит, в два раза увеличить раздачу, чем есть сейчас - еще может быть, но гигабит - отнюдь.
Эти "чтобы" и есть настройки, а не исключение. Оперы может и хватить, хз сколько у него одновременных клиентов.
Andron_buton: когда файлов (открытых, которые читаются в данный момент времени) очень много, то никакие большие куски не помогут
Неправда это, я тоже этим занимался когда-то, когда еще SSD дисков не было и вижимали с дисков все, что могли. Если метаданные всех файлов влазят в память, т.е. их не миллионы, то они вообще не помеха и диск не дергают, главное чтобы они не вытеснялись из кэша и в кэш не лезли сами файлы без надобности, ну и чтобы с каждым диском работал только один отдельный процесс.
Эм, а как обслуживать клиентов, по очереди? Один скачал, даем второму? Интересно, сколько юзеров останется у ТС при такой схеме. Или что Вы имеете ввиду под "параллельными обращениями"?
Смотрите, если несколько запросов пришли одновременно они могут быть обработаны двумя способами: послать все их в ядро и ждать ответов от всех сразу постепенно посылая запросы еще, как в случае с aio или послать один запрос на 2 мегабайта, подождать ответа, послать второй, подождать ответа, послать третий, подождать ответа и т.д. В первом случае они будут обрабатываться на усмотрение планироващика, который будет стараться угодить всем сразу в ущерб пропускной способности, а во втором случае у планировщика всегда только один запрос и полный контроль над тем, сколько данных за один запрос мы можем получить остается у нас и позволяет минимизировать количество позиционирований головки. Естественно, если пришло 3 запроса и ответ от диска занимает 30 мс, то первый клиент начнет получать ответ через 30 мс, второй через 60 мс, третий через 90 мс, но это незаметно для посетителей.
может удастся мбит 300
По 18 мбайт/с с диска чтоли? Несеръезно.
я использую кучу схем в том числе aio+directio, и sendfile
Оба метода и через sendfile и через aio (речь об nginx'е, правильно?), не гарантируют, что к диску не будет параллельных обращений. Потому и так плохо.
По крайней мере 2-е точно должно сходить с рук.
zzzit, и да и нет. "Человек" после извинится, а с "не человеком" нету смысла общаться далее.
Кому-то тяжело извиниться, кому-то нет, кто-то может извиниться, а потом подстеречь в темном переулке. Все люди разные, но все люди.
---------- Добавлено 21.07.2013 в 18:24 ----------
но, нужно понимать, что все уместно в свое время и в свое место, можно вести себя как хрюшка
Согласитесь, что мы все люди и взаимоотношения должны быть человеческими, никто никому не дает право грубить и хамить. А если уж и сорвался - будь добр ответить за свой поступок.
Не соглашусь. Лучше согласитесь, что мы все люди и у всех есть эмоции, и грубить и хамить вполне по человечески.
Данных, о которых я писал выше, я так понимаю, ждать не стоит. Спасибо за теорию.
Не храню графики многолетней давности, сори.
UPD: ТС если еще надо, пиши в личку, из спортивного интереса посмотрю, что можно выжать в текущей конфигурации.
Тут многие реализовывали подобные вещи и понимают, что физические возможности логикой не обмануть
Что вы там реализовывали? Физические возможности как раз достаточные, нужно всего по 60 мбайт с диска тянуть, а это случайными 2+ мегабайтными блоками любой диск сможет. Только вот никаких "сколько потоков" быть не может, поток один на диск, отдельный и читать с диска он должен мимо кэша файловой системы. Клиентов может быть столько, сколько хватит оперативки под их буферы.
Есть еще вариант попроще, это read ahead, читать с диска в обычном режиме мелкими запросами, но давать ему складывать в кэш фс по пару мегабайт наперед, пока не много клиентов - будет работать, а потом в какой-то непредсказуемый момент резко начнутся тормоза.
Эти "если" прокатывают ТОЛЬКО при определенных условиях, а именно определенных характеристиках контента.
Мое если было только одно, чтобы метаданные влазили в память и не вижу причин, чтобы контент ТСа не прокатывал.
zzzit, ага, "если", "чтобы", "чтобы", это уже называется исключение. Еще раз, у ТС много файлов, мало дисков и оперы, тут "большие куски" никак не помогут выжать гигабит, в два раза увеличить раздачу, чем есть сейчас - еще может быть, но гигабит - отнюдь.
Эти "чтобы" и есть настройки, а не исключение. Оперы может и хватить, хз сколько у него одновременных клиентов.
когда файлов (открытых, которые читаются в данный момент времени) очень много, то никакие большие куски не помогут
Неправда это, я тоже этим занимался когда-то, когда еще SSD дисков не было и вижимали с дисков все, что могли. Если метаданные всех файлов влазят в память, т.е. их не миллионы, то они вообще не помеха и диск не дергают, главное чтобы они не вытеснялись из кэша и в кэш не лезли сами файлы без надобности, ну и чтобы с каждым диском работал только один отдельный процесс.