форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Увеличение скорости перестроения пр..."	+/–
Сообщение от auto_tips on 30-Июн-10, 01:53
Перестроение большого программного 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.dev/tips/info/2398.shtml
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Увеличение скорости перестроения программного RAID в Linux"	+/–
Сообщение от Zulu on 30-Июн-10, 01:53
Году в 2007 я тоже перся, найдя все это. Только все это не бесплатно: битмапы постоянно стоят кажется около процента скорости, так что надо считать окупится ли это или нет. А скорость ребилда так вообще просто увеличивается за счет текущих дисковых операций. 50 мб/сек? да не вопрос, но что у вас станет с собственно задачами, выполняемыми сервером?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Увеличение скорости перестроения программного RAID в Linux"	+/–
	Сообщение от LionSoft (ok) on 30-Июн-10, 10:11
	> но что у вас станет с собственно задачами, выполняемыми сервером? ничего страшного: зависит-же от задачи сервера... Если это backup сервер который работает активно по ночам, то потратить 2 часа днем на перестройку массива можно и на максимальной скорости.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Увеличение скорости перестроения программного RAID в Linux"	+/–
Сообщение от PavelR (??) on 30-Июн-10, 20:42
а если он днем не загружен, то перестройка и так будет идти на максимальной для дисков скорости, ну если ограничение speed_limit_max конечно не достигнуто...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Увеличение скорости перестроения программного RAID в Linux"	+/–
Сообщение от Одмин on 01-Июл-10, 01:52
А каким образом подключение битмапа должно ускорить синхронизацию? Чтобы синкалось быстро они должны быть всегда включены а не на этапе ребилда.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Увеличение скорости перестроения программного RAID в Linux"	+/–
Сообщение от rm_ (ok) on 01-Июл-10, 08:52
> Если ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых карт ОМГ какой же махровый бред.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Вот так было бы правильнее"	+/–
	Сообщение от rm_ (ok) on 01-Июл-10, 09:02
	Если же ресинхронизация производилась в результате краха (внеплановой перезагрузки) системы, и вы хотите, чтобы в будущем подобные случаи приводили не к полной, а к частичной (ещё на порядок более быстрой) ресинхронизации, можно включить на массиве режим использования битовой карты намерений записи (write-intent bitmap):    mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md0 Использование битовой карты замедляет работу с массивом на запись, однако этот эффект можно уменьшить, использовав достаточно большое значение блока карты (как в примере выше - 131072). (об этом и других параметрах см. http://romanrm.ru/mdadm-raid )
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Увеличение скорости перестроения программного RAID в Linux"	+/–
Сообщение от Igor (??) on 10-Фев-11, 18:48
Интересное наблюдение: при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 500G) увеличивается Заметил когда параллельно сборке массива запустил компиляцию. Скорость сборки при ненагруженном процессоре 24Mb/sec При нагруженном burnP5 - скорость 60Mb/sec Понять не могу почему.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Увеличение скорости перестроения программного RAID в Linux"	+/–
	Сообщение от rm_ (ok) on 10-Фев-11, 18:52
	> Интересное наблюдение: > при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска > 500G) увеличивается > Заметил когда параллельно сборке массива запустил компиляцию. > Скорость сборки при ненагруженном процессоре 24Mb/sec > При нагруженном burnP5 - скорость 60Mb/sec > Понять не могу почему. echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor дальше догадаетесь или расписывать?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Увеличение скорости перестроения программного RAID в Linux"	+/–
	Сообщение от Igor (??) on 10-Фев-11, 19:34
	Догадался, но даже при макс частоте (perfomance) эффект сохраняется. Ресурсов процессора на ребилд расходуется 5-10%, не думаю что частота должна как-то сильно (более 2х раз) повлиять на ребилд
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема