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х раз) повлиять на ребилд
| |
|
|
|