Перестроение большого программного RAID в Linux может занимать десятки часов. Скорость синхронизации mdraid зависит от proc-переменных /proc/sys/dev/raid/speed_limit_max и /proc/sys/dev/raid/speed_limit_min, задающих максимальную и минимальную пропускную способность синхронизации данных. По умолчанию значения этих переменных выставлены в 200000 и 1000 (Кб). Манипулируя данными параметрами можно существенно увеличить скорость перестроения RAID-массива.Подобрать оптимальные значения можно в зависимости от производительности текущей дисковой системы, чем выше скорость синхронизации, чем меньше ресурсов остается для обработки текущих дисковых операций. Установим минимальную скорость в 50 Мб/сек, а максимальную в 300 Мб/cек:
echo 50000 > /proc/sys/dev/raid/speed_limit_min
echo 300000 > /proc/sys/dev/raid/speed_limit_maxЕсли ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых карт:
mdadm --grow --bitmap=internal /dev/md0
После завершения синхронизации, отключаем данный режим:
mdadm --grow --bitmap=none /dev/md0
Посмотреть текущую скорость ресинхронизации можно в выводе команды:
cat /proc/mdstat
В результате вышеуказанных манипуляций время перестроения RAID было уменьшено с 22 до 2 часов.
URL: http://www.cyberciti.biz/tips/linux-raid-increase-resync-reb...
Обсуждается: http://www.opennet.me/tips/info/2398.shtml
Году в 2007 я тоже перся, найдя все это.Только все это не бесплатно: битмапы постоянно стоят кажется около процента скорости, так что надо считать окупится ли это или нет.
А скорость ребилда так вообще просто увеличивается за счет текущих дисковых операций. 50 мб/сек? да не вопрос, но что у вас станет с собственно задачами, выполняемыми сервером?
> но что у вас станет с собственно задачами, выполняемыми сервером?ничего страшного: зависит-же от задачи сервера... Если это backup сервер который работает активно по ночам, то потратить 2 часа днем на перестройку массива можно и на максимальной скорости.
а если он днем не загружен, то перестройка и так будет идти на максимальной для дисков скорости, ну если ограничение speed_limit_max конечно не достигнуто...
А каким образом подключение битмапа должно ускорить синхронизацию? Чтобы синкалось быстро они должны быть всегда включены а не на этапе ребилда.
> Если ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых картОМГ какой же махровый бред.
Если же ресинхронизация производилась в результате краха (внеплановой перезагрузки) системы, и вы хотите, чтобы в будущем подобные случаи приводили не к полной, а к частичной (ещё на порядок более быстрой) ресинхронизации, можно включить на массиве режим использования битовой карты намерений записи (write-intent bitmap):mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md0
Использование битовой карты замедляет работу с массивом на запись, однако этот эффект можно уменьшить, использовав достаточно большое значение блока карты (как в примере выше - 131072).
(об этом и других параметрах см. http://romanrm.ru/mdadm-raid )
Интересное наблюдение:
при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 500G) увеличивается
Заметил когда параллельно сборке массива запустил компиляцию.
Скорость сборки при ненагруженном процессоре 24Mb/sec
При нагруженном burnP5 - скорость 60Mb/secПонять не могу почему.
> Интересное наблюдение:
> при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска
> 500G) увеличивается
> Заметил когда параллельно сборке массива запустил компиляцию.
> Скорость сборки при ненагруженном процессоре 24Mb/sec
> При нагруженном burnP5 - скорость 60Mb/sec
> Понять не могу почему.echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
дальше догадаетесь или расписывать?
Догадался, но даже при макс частоте (perfomance) эффект сохраняется.
Ресурсов процессора на ребилд расходуется 5-10%, не думаю что частота должна как-то сильно (более 2х раз) повлиять на ребилд