Re: балансинг по жестким дискам

[Gena Makhomed <gmm@xxxxxxxxx>]

On Monday, January 12, 2009 at 17:08:33, Olexander Shtepa wrote:

>> OS> В линуксе это так:
>> OS>  * This routine returns the disk from which the requested read should
>> OS>  * be done. There is a per-array 'next expected sequential IO' sector
>> OS>  * number - if this matches on the next IO then we use the last disk.
>> OS>  * There is also a per-disk 'last know head position' sector that is
>> OS>  * maintained from IRQ contexts, both the normal and the resync IO
>> OS>  * completion handlers update this position correctly. If there is no
>> OS>  * perfect sequential match then we pick the disk whose head is closest.
>> 
>> разве этот алгоритм работы не будет оптимальнее
>> "ручной" привязки запрашиваемых файлов к дискам?

OS> К сожалению этот алгоритм работает на блочном уровне,
OS> а важна вся цепочка: nginx -> FS -> md -> disk

OS> Для того чтобы эта оптимизация срабатывала
OS> нужно чтобы запрашиваемые блоки данных были
OS> достаточно большого размера. Но как известно
OS> ужмёшь в одном месте - в другом вылезет.

размер блока считываемого с диска за один раз ограничен количеством
оперативной памяти и количеством клиентов (одновременных подключений)

и если я не ошибаюсь, его можно задать через output_buffers / 
sendfile_max_chunk,
если для отдачи файлов [не] используется sendfile, и даже можно выключить
кеширование в ram для файлов большого обьема через директиву directio.
и вот еще http://www.opennet.ru/base/net/nginx_tune_big_trans.txt.html

OS> Так что "ручная привязка" это уже оттюненый метод (насколько я понял).

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

в случае использования RAID-1 - это будет 1 файл,
и если его часто запрашивают - он будет уже в кеше.

OS> А с RAID-1 еще игратся надо.

что-то мне подсказывает, что метод, который при выборе диска
для запроса "pick the disk whose head is closest" будет работать
более оптимально, чем метод привязки файлов к дискам. например,
если file1 и fileN привязаны к диску 1, и file1 физически находится
в начале диска, а fileN - физически находится в конце диска,
и два клиента client1 и client2 скачивают соответственно файлы
file1 и fileN, то операционная система будет очень много времени
проводить в ожидании, пока диск будет позиционировать головки
с начала диска в конец диска и обратно. потому что pattern
чтения этих двух файлов с диска будет примерно вот такой:

rnd_seek, file1_chunk1, big_seek, fileN_chunk1,
big_seek, file1_chunk2, big_seek, fileN_chunk2,
big_seek, file1_chunk3, big_seek, fileN_chunk3,
big_seek, ...

хотя между двумя близко расположенными дорожками
диск сделает seek намного быстрее, даже если это
будет не исходный disk1, а какой-то другой diskX.

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

-- 
Best regards,
 Gena