Re: Еще раз о дисковой подси стеме

[Gena Makhomed <gmm@xxxxxxxxx>]

On 18.08.2011 16:48, Илья Винокуров wrote:

> Так вот, при параллельной работе нескольких потоков запросы к массиву будут 
> параллелиться между дисками.
теоретически - скорость работы может вырасти до 2 раз
путем уменьшения объема массива в 2 раза. причем, арифметика
тут достаточно простая, вместо 2 можно взять любое число.

например, можно достичь скорости чтения примерно в 5-10 раз больше,
если собрать RAID10 из двух компонент, каждая из которых
будет зеркалом из 5 винтов, из которых потом сделан RAID0.

но для этого - RAID 10 не нужен. для "горячего" контента
можно использовать SAS винт или зеркало из 2, 3, ... винтов.

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

п.с. возможно это уже даже реализовали в какой-то файловой
системе (ZFS/BTRFS), или же такую фичу можно туда добавить,
если совсем не хочется делать такую операцию своими силами.

> > Для современного диска нет ощутимой разницы в чтении 1К или 1М. Поэтому
> > читать с нескольких дисков блоки по 128К, чтобы набрать 1М - бессмысленно.
> Поэтому я и предложил увеличить размер блока данных.
не поможет. операция seek гораздо более "дорогая" чем кажется. поэтому
скорость линейного чтения гораздо выше, чем скорость рандомного чтения.

> Конечно же, речь идет о софтовом решении. По моему мнению будущее за софтовыми 
> RAID массивами,
> а точнее за RAIDовыми FS.
теоретически - ZFS самое лучшее решение. практически - оно не работает.
наверное нам надо будет ждать, пока не появятся 128-битные процессоры.

> > И всё равно он не полностью решает проблему - при попадании на границу
> > будут задействованы два диска вместо одного ?
> Если рассматривать работу в системе кучки процессов, насилующих RAID массив, то 
> факт попадания одного
> файла на границу не играет никакой роли.
играет, потому что это снижает производительность всего массива.
например, если вместо RAID0/RAID5/RAID6/RAID10 используется RAID1
или полностью независимые друг от друга диски - этого глюка нет,
и дисковая подсистема сервера будет работать более эффективно.

>  Главное, чтобы план чтения блоков с конкретного диска был оптимальным.
это не главное.

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

--
Best regards,
 Gena

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