Hello Андрей,

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 точно не скажу, потому что не помню как там куски файла
АВ> отдаются одному клиенту - всегда с одного диска или попеременно с разных
АВ> дисков, однозначно будет хуже в момент записи, так как запись идет
АВ> одновременно на все веники, остальные рейды проигрывают однозначно.
Там в комментариях написано:

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

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

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

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

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

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

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



Best regards,
CoolCold [COOLCOLD-RIPN]

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