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

[CoolCold <coolcold@xxxxxxxxxxxx>]

Hello CoolCold,

Saturday, October 29, 2011, 8:36:14 AM, you wrote:

C> Hello Андрей,

C> Monday, October 24, 2011, 3:44:20 PM, you wrote:

АВ>> 24.10.2011 14:19, Gena Makhomed пишет:

>>> по какой причине этот вариант "почти рейд1" реализованный
>>> скриптами и через try_files будет лучше нормального raid1 ?
>>>
>>> есть ли данные экспериментов linux mdraid + XFS + flv streaming,
>>> которые подтверждают, что "независимые" винты будут лучше raid1
>>> (нормального (не глючного) програмного или нормального аппаратного)?
>>>
>>> когда этот вариант будет хуже - я уже писал, если какой-то файл
>>> становится очень популярным, то винт с ним становится перегруженным
>>> запросами, а все остальные винты при этом будут практически простаивать,
>>> и суммарная производительность сервера будет меньше, чем могла бы быть в
>>> случае использования нормального, а не "самодельного" raid1 массива.
>>>
>>> кстати, в raid1 массиве не обязательно должно быть всего 2 винта.
>>> вполне может быть 2, 3, 4, 5, 6, 7, ... с соответствующим ростом
>>> производительности массива raid1 при множественных random read.
>>>

АВ>> За рейд1 точно не скажу, потому что не помню как там куски файла 
АВ>> отдаются одному клиенту - всегда с одного диска или попеременно с разных 
АВ>> дисков, однозначно будет хуже в момент записи, так как запись идет 
АВ>> одновременно на все веники, остальные рейды проигрывают однозначно.
C> Там в комментариях написано:

C>  460 /*
C>  461  * This routine returns the disk from which the requested read should
C>  462  * be done. There is a per-array 'next expected sequential IO' sector
C>  463  * number - if this matches on the next IO then we use the last disk.
C>  464  * There is also a per-disk 'last know head position' sector that is
C>  465  * maintained from IRQ contexts, both the normal and the resync IO
C>  466  * completion handlers update this position correctly. If there is no
C>  467  * perfect sequential match then we pick the disk whose head is closest.
C>  468  *
C>  469  * If there are 2 mirrors in the same 2 devices, performance degrades
C>  470  * because position is mirror, not device based.
C>  471  *
C>  472  * The rdev for the device selected will have nr_pending incremented.
C>  473  */

C> from
C> 
http://neil.brown.name/git?p=linux-2.6;a=blob;f=drivers/md/raid1.c;h=4602fc57c961fd16edc5d558a050493a878fd50e;hb=HEAD#l460

C> MD(raid) файлами  вообще  не  оперирует, это не его дело, он про них и не 
знает даже. Поскольку mdraid является блочным
C> устройством,  оперирует  он блоками (внезапно). В каком месте - с дисков 
и/или md device происходит кэширование блоков в
C> VFS  я  не  знаю, нужно чтоб кто-нибудь посмотрел в исходники из тех кто 
знает C & linux kernel. От этого может зависеть
C> эффективность раскладывания файла по standalone дискам/raid1.
Проясняя вопрос:

The kernel caches pages of files, not pages of devices.
It doesn't matter where the page of data came from - it is the page of a file
that is cached.

by Neil Brown from http://www.spinics.net/lists/raid/msg36418.html


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

C> Заодно, может не все знают, но:
C> Individual devices in a RAID1 can be marked as "write-mostly".
C> These drives are excluded from the normal read balancing and will only
C> be read from when there is no other option.  This can be useful for
C> devices connected over a slow link.

C> from 
http://neil.brown.name/git?p=mdadm;a=blob;f=md.4;h=99faad1ac50c48a3592b7ac27e5c1a8d20070923;hb=HEAD#l217

C> через что, если массив небольшой, можно подключать в пару sata + ssd диски и 
раздача будет вестись с ssd только.

АВ>> По
АВ>> поводу неравномерной нагрузки - да такое бывает, обычно самые популярные 
АВ>> файлы попадают в кеш ОС, если даже и этого не хватает, у меня на этот 
АВ>> случай есть скрипт, который перенесет часть активных файлов на другие, 
АВ>> менее нагруженные веники, для 1-но гигабитных серверов с 6-ю вениками 
АВ>> случаи перегрузки одного веника крайне редки, быстрее все же упирается в 
АВ>> канал. Скрипт используется в частности на 5-ти гбитном сервере с 8-ю 
АВ>> вениками и даже не по крону или как демон, так как случаи все равно 
АВ>> довольно редки.



C> Best regards,
C> CoolCold [COOLCOLD-RIPN]

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


np:  < The system cannot find the file specified (e:\xmedia.info.txt) >
Best regards,
CoolCold [COOLCOLD-RIPN]

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