The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"Раздел полезных советов: Увеличение скорости перестроения пр..."  +/
Сообщение от 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_ email(ok) on 01-Июл-10, 08:52 
> Если ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых карт

ОМГ какой же махровый бред.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Вот так было бы правильнее"  +/
Сообщение от rm_ email(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 email(??) on 10-Фев-11, 18:48 
Интересное наблюдение:
при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 500G) увеличивается
Заметил когда параллельно сборке массива запустил компиляцию.
Скорость сборки при ненагруженном процессоре 24Mb/sec
При нагруженном burnP5 - скорость 60Mb/sec

Понять не могу почему.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру