The OpenNET Project / Index page

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

Увеличение скорости перестроения программного RAID в Linux 
Перестроение большого программного 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

Посмотреть текущую скорость ресинхронизации можно в выводе команды:

   cat /proc/mdstat

В результате вышеуказанных манипуляций время перестроения RAID было уменьшено с 22 до 2 часов.


Если для рабочего RAID включить режим сохранения битовых карт (write-intent
bitmap), то можно дополнительно увеличить скорость ресинхронизация после
развала RAID в результате краха системы или экстренного отключения питания.
Обратной стороной данного режима является небольшое замедление операций записи
данных в RAID:

   mdadm --grow --bitmap=internal /dev/md0

Отключить данный режим можно так:

   mdadm --grow --bitmap=none /dev/md0
 
29.06.2010 , Источник: http://www.cyberciti.biz/tips/linux...
Ключи: raid, speed, optimization, linux, mdadm / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Диски и файлы / RAID массивы

Обсуждение [ RSS ]
  • 1.1, Zulu (?), 01:53, 30/06/2010 [ответить]  [↓]     [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    Году в 2007 я тоже перся, найдя все это.

    Только все это не бесплатно: битмапы постоянно стоят кажется около процента скорости, так что надо считать окупится ли это или нет.
    А скорость ребилда так вообще просто увеличивается за счет текущих дисковых операций. 50 мб/сек? да не вопрос, но что у вас станет с собственно задачами, выполняемыми сервером?

     
     
  • 2.2, LionSoft (ok), 10:11, 30/06/2010 [^] [^^] [^^^] [ответить]      [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    > но что у вас станет с собственно задачами, выполняемыми сервером?

    ничего страшного: зависит-же от задачи сервера... Если это backup сервер который работает активно по ночам, то потратить 2 часа днем на перестройку массива можно и на максимальной скорости.

     

  • 1.3, PavelR (??), 20:42, 30/06/2010 [ответить]  [↑]     [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    а если он днем не загружен, то перестройка и так будет идти на максимальной для дисков скорости, ну если ограничение speed_limit_max конечно не достигнуто...
     
  • 1.4, Одмин (?), 01:52, 01/07/2010 [ответить]      [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    А каким образом подключение битмапа должно ускорить синхронизацию? Чтобы синкалось быстро они должны быть всегда включены а не на этапе ребилда.
     
  • 1.5, rm_ (ok), 08:52, 01/07/2010 [ответить]  [↓]     [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    > Если ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых карт

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

     
     
  • 2.6, rm_ (ok), 09:02, 01/07/2010 [^] [^^] [^^^] [ответить]      [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    Если же ресинхронизация производилась в результате краха (внеплановой перезагрузки) системы, и вы хотите, чтобы в будущем подобные случаи приводили не к полной, а к частичной (ещё на порядок более быстрой) ресинхронизации, можно включить на массиве режим использования битовой карты намерений записи (write-intent bitmap):

       mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md0

    Использование битовой карты замедляет работу с массивом на запись, однако этот эффект можно уменьшить, использовав достаточно большое значение блока карты (как в примере выше - 131072).
    (об этом и других параметрах см. http://romanrm.ru/mdadm-raid )

     

  • 1.7, Igor (??), 18:48, 10/02/2011 [ответить]  [↑]     [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    Интересное наблюдение:
    при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 500G) увеличивается
    Заметил когда параллельно сборке массива запустил компиляцию.
    Скорость сборки при ненагруженном процессоре 24Mb/sec
    При нагруженном burnP5 - скорость 60Mb/sec

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

     
     
  • 2.8, rm_ (ok), 18:52, 10/02/2011 [^] [^^] [^^^] [ответить]      [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    > Интересное наблюдение:
    > при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска
    > 500G) увеличивается
    > Заметил когда параллельно сборке массива запустил компиляцию.
    > Скорость сборки при ненагруженном процессоре 24Mb/sec
    > При нагруженном burnP5 - скорость 60Mb/sec
    > Понять не могу почему.

    echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    дальше догадаетесь или расписывать?

     
     
  • 3.9, Igor (??), 19:34, 10/02/2011 [^] [^^] [^^^] [ответить]      [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
    		• +/–
    Догадался, но даже при макс частоте (perfomance) эффект сохраняется.
    Ресурсов процессора на ребилд расходуется 5-10%, не думаю что частота должна как-то сильно (более 2х раз) повлиять на ребилд
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:

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

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