Первым протестировал software RAID 1 (Linux, вкомпилен в ядро, управление через mdadm). Тут нельзя точно сказать была ли фрагментирована файловая система. Скорее всего нет.
13952fe0bca8f5c0620a3b7342c271e4000
|
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 |
| 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
|
| 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 |
| 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
|
| 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 |
| 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
Дефрагментированная партиция
|
| 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 |
| 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) оказывает значительное влияние на результаты. Нужно поискать пакет, который может тестировать сам диск, обращаясь к нему напрямую, а не через файловую систему. Поэтому выводу не претендуют на абсолютную точность)
Потребление процессора: Как правило софтварный рейд потребляет от 4 до 15% процессора больше (кроме случая последовательного создания файлов). Больше всего эта разница чувствуется при случайном удалении файлов, затем последовательном удалении, и затем последовательной записи.
Последовательная запись и перезапись: Программный рейд быстрее на 42%.
Последовательное чтение: Аппаратный рейд быстрее на 2-6,5%
Скорость позиционирования к случайному файлу: Программный рейд быстрее на 18%
Создание файлов: аппаратное решение быстрее при создании случайных файлов на 6% и при последовательном создании на 27%.
Удаление файлов: Программный рейд быстрее на 15% при удалении файлов.
Если говорить о времени исполнения теста, то за счёт большой разницы в скорости записи (в сторону программного рейда) программный рейд прошёл тест на 41% реального времени быстрее, но на 10% системного времени медленнее.
Итак, если нужно часто записывать медиафайлы, то софтварный рейд будет впечатляюще быстрее. А если на процессор идёт большая нагрузка, записывается много маленьких файлов или читаются большие, то предпочтительнее аппаратный рейд.
В целом складывается впечатление о победе софтварного рейда. За трату дополнительных 10% процессорного времени мы получает суперскорость записи (+42%) и большую скорость позиционирования (+18%) при весьма приличной скорости считывания (минус 2-6,5%).
Лично мой вывод: Всё равно буду использовать аппаратный рейд. Он более надёжен, меньше нагрузка на шину и процессор.
