Первым протестировал software RAID 1 (Linux, вкомпилен в ядро, управление через mdadm). Тут нельзя точно сказать была ли фрагментирована файловая система. Скорее всего нет.
13952fe0bca8f5c0620a3b7342c271e4000
Version 1.96 | Sequential Output | Sequential Input | Random Seeks |
Sequential Create | Random Create | |||||||||||||||||||||
Size | Per Char | Block | Rewrite | Per Char | Block | Num Files | Create | Read | Delete | Create | Read | Delete | ||||||||||||||
K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | |||
i | 4G | 48711 | 16 | 30173 | 6 | 72180 | 7 | 404.2 | 10 | 16 | 9949 | 34 | +++++ | +++ | 19722 | 65 | 13059 | 42 | +++++ | +++ | 19125 | 68 | ||||
Latency | 1600ms | 1209ms | 42633us | 116ms | Latency | 7598us | 319us | 16731us | 202us | 106us | 132us |
Общее время выполнения:
13952fe0bca8f5c0620a3b7342c271e4001
Запускал 3 раза hdparm, чтобы измерить линейную скорость чтения:
13952fe0bca8f5c0620a3b7342c271e4002
Hardware raid
Фрагментированная файловая система. bonnie++ настройки по умолчанию (2G)
13952fe0bca8f5c0620a3b7342c271e4003
Version 1.96 | Sequential Output | Sequential Input | Random Seeks | Sequential Create | Random Create | |||||||||||||||||||||
Size | Per Char | Block | Rewrite | Per Char | Block | Num Files | Create | Read | Delete | Create | Read | Delete | ||||||||||||||
K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | |||
g | 2G | 25516 | 8 | 17476 | 4 | 74342 | 6 | 293.4 | 4 | 16 | 13494 | 45 | +++++ | +++ | 16340 | 56 | 14492 | 49 | +++++ | +++ | 15954 | 56 | ||||
Latency | 2642ms | 2225ms | 128ms | 184ms | Latency | 432us | 311us | 347us | 616us | 108us | 129us |
13952fe0bca8f5c0620a3b7342c271e4004
Есть разница. По умолчанию в первый раз был запуск с 4G, а второй раз bonnie++ запустился с параметром 2G.
Есть большая разница в результатах bonnie++ на фрагментированной партиции и на нефрагментированной.
Дефрагментированная партиция (опция -s 4g):
13952fe0bca8f5c0620a3b7342c271e4005
Version 1.96 | Sequential Output | Sequential Input | Random Seeks | Sequential Create | Random Create | |||||||||||||||||||||
Size | Per Char | Block | Rewrite | Per Char | Block | Num Files | Create | Read | Delete | Create | Read | Delete | ||||||||||||||
K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | |||
g | 2G | 28469 | 8 | 19237 | 4 | 77328 | 6 | 335.1 | 4 | 16 | 13624 | 38 | +++++ | +++ | 17033 | 52 | 15045 | 44 | +++++ | +++ | 16016 | 53 | ||||
Latency | 1057ms | 526ms | 153ms | 209ms | Latency | 20959us | 308us | 339us | 11512us | 36us | 12055us |
13952fe0bca8f5c0620a3b7342c271e4006
Дефрагментированная партиция
Version 1.96 | Sequential Output | Sequential Input | Random Seeks | Sequential Create | Random Create | |||||||||||||||||||||
Size | Per Char | Block | Rewrite | Per Char | Block | Num Files | Create | Read | Delete | Create | Read | Delete | ||||||||||||||
K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | /sec | % CPU | |||
g | 4G | 28417 | 8 | 19218 | 4 | 68162 | 6 | 249.2 | 5 | 16 | 12733 | 36 | +++++ | +++ | 15441 | 47 | 15398 | 45 | +++++ | +++ | 16148 | 54 | ||||
Latency | 1069ms | 424ms | 177ms | 207ms | Latency | 23137us | 308us | 45001us | 14513us | 98us | 91us |
13952fe0bca8f5c0620a3b7342c271e4007
Линейное чтение у аппаратного рейда (запускал 3 раза):
13952fe0bca8f5c0620a3b7342c271e4008
Выводы:
Фрагментированность файловой системы (в нашем случае ReiserFS) оказывает значительное влияние на результаты. Нужно поискать пакет, который может тестировать сам диск, обращаясь к нему напрямую, а не через файловую систему. Поэтому выводу не претендуют на абсолютную точность) 0
Потребление процессора: Как правило софтварный рейд потребляет от 4 до 15% процессора больше (кроме случая последовательного создания файлов). Больше всего эта разница чувствуется при случайном удалении файлов, затем последовательном удалении, и затем последовательной записи. 0
Последовательная запись и перезапись: Программный рейд быстрее на 42%.
Последовательное чтение: Аппаратный рейд быстрее на 2-6,5%
Скорость позиционирования к случайному файлу: Программный рейд быстрее на 18%
Создание файлов: аппаратное решение быстрее при создании случайных файлов на 6% и при последовательном создании на 27%.
Удаление файлов: Программный рейд быстрее на 15% при удалении файлов.
Если говорить о времени исполнения теста, то за счёт большой разницы в скорости записи (в сторону программного рейда) программный рейд прошёл тест на 41% реального времени быстрее, но на 10% системного времени медленнее. 0
Итак, если нужно часто записывать медиафайлы, то софтварный рейд будет впечатляюще быстрее. А если на процессор идёт большая нагрузка, записывается много маленьких файлов или читаются большие, то предпочтительнее аппаратный рейд. 0
В целом складывается впечатление о победе софтварного рейда. За трату дополнительных 10% процессорного времени мы получает суперскорость записи (+42%) и большую скорость позиционирования (+18%) при весьма приличной скорости считывания (минус 2-6,5%). 0
Лично мой вывод: Всё равно буду использовать аппаратный рейд. Он более надёжен, меньше нагрузка на шину и процессор.