Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: балансинг по жестким диска м
On Monday, January 12, 2009 at 23:56:26, Olexander Shtepa wrote:
>> OS> Так что "ручная привязка" это уже оттюненый метод (насколько я понял).
>> только при 7 дисках для системы 7 одинаковых копий файла одного файла
>> будут 7-ю различными файлами, и каждый из них будет занимать память в кеше.
>> в случае использования RAID-1 - это будет 1 файл,
>> и если его часто запрашивают - он будет уже в кеше.
OS> Прямой кандидат на DirectIO, если условия задачи позволяют.
при использовании directio файл вообще не будет попадать в кеш.
а частоиспользуемые мелкие файлы лучше все-таки держать в кеше.
и как метод ручной привязки файлов к дискам не тюнить, при N
дисках - эффективность кэширования файлов в памяти средствами
операционной системы будет в N раз хуже, потому что 1 файл
будет представлен в памяти в N копиях. - и это неустранимо.
directio имеет смысл использовать только для (очень) больших файлов.
>> что-то мне подсказывает, что метод, который при выборе диска
>> для запроса "pick the disk whose head is closest" будет работать
>> более оптимально, чем метод привязки файлов к дискам.
OS> Если я не отстал от прогресса, то IDE/SATA диски имеют чисто логическую
адресацию
OS> головка/дорожка/сектор и неимеют никакого отношения к физической топологии
диска.
OS> Так что это довольно сомнительное свойство..
CHS адресация сейчас не используется, а LBA адресация имеет отношение
к физическому устройству жесткого диска - линейный адрес сектора указывает
положение сектора на пластине, - чем меньше адрес, тем ближе сектор
к краю (началу) диска.
OS> На счет SCSI/SAS - совершенно не в курсе, но сомневаюсь, так как
современные диски
OS> имеют переменное число секторов на дорожку, перемещенные сектора - мозг
вскипит
OS> всё это учитывать, это дело внутреннего контроллера диска.
seek - это операция позиционирования на дорожку. сколько физически секторов
на трек умещается - это совершенно не важно. зная LBA адреса двух секторов
можно вычислить "расстояние" между ними - чем меньше расстояние,
тем ближе треки на которых размещены эти сектора.
примерно это и происходит в /* Find the disk whose head is closest */
http://lxr.linux.no/linux+v2.6.28/drivers/md/raid1.c#L491
OS> Кстати, именно по этому должен иметь эффект использования очередей (NCQ в
SATA),
OS> сам контроллер диска имеет всю физическую инфу и может распланировать
процесс самым
OS> эффективным образом.
NCQ/TCQ будет работать еще эффективнее, если на один диск направить
запросы к секторам, что находятся в 1/3 от начала диска, на второй -
те, что надодятся ближе к центру диска, а на третий - те, что ближе
к концу диска. суммарная производительность такого массива будет выше,
чем если бы запросы были бы разбросаны по всем дискам случайным образом.
примерно именно этим и занимается код в функции read_balance
http://lxr.linux.no/linux+v2.6.28/drivers/md/raid1.c#L400
>> 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.
поэтому я считаю, - нет причин для performance degrade
при использовании software raid-1 в linux через mdraid.
и кроме того - я не вижу причин по которым "ручное" привязывание
файлов к дискам должно быть эффективнее чем код software raid-1.
--
Best regards,
Gena
|