ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Сильная нагрузка на сер вер- стриминг FLV



On 24.10.2011 15:21, Андрей Василишин wrote:

За рейд1 точно не скажу, потому что не помню как там куски файла
отдаются одному клиенту - всегда с одного диска или попеременно с разных
дисков

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

Вы не забывайте про seek'и, что лучше чтобы один клиент сикал по одному
диску или по 10-ти сразу, а если таких клиентов 3000, что будет?

там не один клиент. обычно клиентов больше, чем винтов на сервере,
так что в промежутках между запросами к одному файлу этот же винт
всеравно будет выполнять seek'и, чтобы обработать другие запросы,
обращения каких-то других клиентов к другим файлам с этого винта.
поэтому seek'и всеравно будут. какая тогда разница чем они вызваны?

один запрос клиента точно не будет *сразу* по 10 винтам seek'ать.
тем более, если клиентов 3000. это будет по 300 запросов на винт.
в среднем. а может быть и все 3000 запросов к одному винту,
в самом худшем случае, а все остальные винты будут простаивать.
(в том варианте когда нет raid1 и есть только независимые винты)

в любом случае, отдавать какой-то файл одновременно с N винтов -
это будет более производительный вариант, чем отдавать его с одного
единственного винта. и как минимум для стриминга где бывают очень
популярные файлы, к которым большое количество обращений - вариант
raid1 может оказаться лучше, чем "независимые винты" и try_files.

Раз не верите мне, то поверьте тогда Игорю, он производил тестирование

есть ссылка на то сообщение из архива рассылки ?

afair, он производил тестирование когда-то очень давно и только под gmirror/FreeBSD. для CentOS с XFS/ext4 и програмным mdraid / нормальным аппаратным RAID1 результаты тестирования производительности "RAID1 with N components" vs "full standalone N HDDs" могут быть совсем другими.

Для себя я когда-то перешел с рейд5
на стендэлон и увидел выигрыш в 2 раза.

raid5, raid0, raid10 - это все варианты raid`а с чередованием страйпов.
например, stripe size обычно 64М, 128М или 256М. если убрать эти рейды -
тогда производительность вырастет. но в RAID1 нет чередования страйпов.
и если система запрашивает прочитать с RAID-массива фрагмент размером
в 1, 2, 4, ... мегабайт - этот фрагмент будет читаться с одного винта,
без каких-либо лишних seek`ов и потери производительности из-за этого.

а если какой-то файл является очень популярным - то он будет читаться
не с одного, а с нескольких винтов одновременно (паралельно, разные фрагменты, в овтет на запросы разных клиентов) и суммарная пропускная способность дисковой подсистемы вырастет в столько раз (примерно) сколько винтов являются компонентами RAID1 массива.

поэтому - мне совсем не понятно, почему N отдельных винтов будут
работать якобы быстрее, чем RAID1 массив из N компонент (винтов).
( как в случае, когда N==2, так и при N==3, N==4, N==5, N==... )

туда получится записать больше файлов - это да. но *производительность* от того, что один файл будет лежать только на одном единственном винте (или только на двух винтах) - совсем не вырастет, а только упадет, имхо.

--
Best regards,
 Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.