Linux md против LVM производительности

8

Я пытаюсь настроить свой NAS, использую openfiler и задаюсь вопросом, почему у меня относительно низкая производительность чтения с 4 дисков WD RE3 в RAID 5.

РЕДАКТИРОВАТЬ: Обратите внимание, я говорю о буферизированной скорости чтения диска, а не кешированные скорости

РЕДАКТИРОВАТЬ: Изменено форматирование, чтобы было ясно, что есть два набора вывода.

Когда я запускаю hdparm на мета-устройстве, я получаю ожидаемые уровни производительности, снижая громкость, и это в три раза быстрее!

Кто-нибудь есть идеи, почему? LVM это плохо?

декан

Мета-устройство / dev / md0 результаты

[root @ nas2 и т. д.] # hdparm -tT / dev / md0
/ DEV / md0:
 Время кэшированного чтения: 4636 МБ за 2,00 секунды = 2318,96 МБ / с
 Время чтения буферизованного диска: 524 МБ за 3,01 секунды = 174,04 МБ / с

Vol группа / dev / mapper / vg1-vol1 результаты

[root @ nas2 и т. д.] # hdparm -tT / dev / mapper / vg1-vol1
/ DEV / картографа / vg1-vol1:
 Время кэшированного чтения: 4640 МБ за 2,00 секунды = 2320,28 МБ / с
 Время чтения буферизованного диска: 200 МБ за 3,01 секунды = 66,43 МБ / с

Редактировать: см. Раздел справочной страницы hdparm, где предлагается, чтобы это был абсолютно правильный тест на производительность последовательного чтения, и это проблема, которую я пытаюсь решить.

-t Выполнять тайминги чтения устройства для сравнения и сравнения. Для получения значимых результатов эту операцию следует повторить 2-3 раза, в противном случае
              неактивная система (без других активных процессов) с по крайней мере парой мегабайт свободной памяти. Это отображает скорость чтения через буфер
              кэширование на диск без предварительного кэширования данных. Это измерение является показателем того, насколько быстро накопитель может поддерживать последовательное считывание данных при
              Linux, без каких-либо накладных расходов на файловую систему. Для обеспечения точных измерений буферный кеш очищается во время обработки -t с использованием BLKFLSBUF
              IOCTL. Если также указан флаг -T, то поправочный коэффициент, основанный на результате -T, будет включен в результат, сообщенный для -t
              операция.
Дин Смит
источник
ты пробовал тесты как bonnie++?
SaveTheRbtz

Ответы:

10

Настройки чтения по умолчанию для LVM действительно пессимистичны. Попробуйте blockdev --setra 8192 /dev/vg1/vol1и посмотрите, что из-за этого увеличит вашу производительность LVM. Вы всегда будете получать удар по производительности, используя LVM; мы измеряем его в правильно настроенных системах на уровне примерно 10% производительности базового блочного устройства.

romble
источник
4

У меня нет хорошего объяснения, но я могу подтвердить результаты.

Тестирование RAID (raid5, 4x1.5TB накопители)

root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2130 MB in  2.00 seconds = 1065.81 MB/sec
 Timing buffered disk reads:  358 MB in  3.00 seconds = 119.15 MB/sec
root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2168 MB in  2.00 seconds = 1084.54 MB/sec
 Timing buffered disk reads:  358 MB in  3.01 seconds = 119.10 MB/sec

Тест тома, который использует md2 в качестве физического устройства.

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2078 MB in  2.00 seconds = 1039.29 MB/sec
 Timing buffered disk reads:  176 MB in  3.03 seconds =  58.04 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2056 MB in  2.00 seconds = 1028.06 MB/sec
 Timing buffered disk reads:  154 MB in  3.03 seconds =  50.81 MB/sec

Я внес изменения, предложенные womble, и увидел такие результаты.

root@enterprise:# blockdev --setra 8192 /dev/mapper/vg2-data

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2106 MB in  2.00 seconds = 1053.82 MB/sec
 Timing buffered disk reads:  298 MB in  3.00 seconds =  99.26 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2044 MB in  2.00 seconds = 1022.25 MB/sec
 Timing buffered disk reads:  280 MB in  3.03 seconds =  92.45 MB/sec
оборота Зоредаче
источник
3

Убедитесь, что вы сравниваете яблоки с яблоками.

hdparm -t читает с начала устройства, которое также является самой быстрой частью вашего диска, если вы даете ему целый диск (и его вращающиеся тарелки).

Убедитесь, что вы сравниваете его с LV в начале диска.

Чтобы увидеть использование карты pvdisplay -m.

(хорошо, конечно, разница в цифрах может быть незначительной. Но, по крайней мере, подумайте об этом :)

MikeyB
источник
На самом деле оказывается, что это не пренебрежимо мало. Если я использую том, который начинается с экстента 0, производительность почти одинакова. Это часть ответа, я уверен.
Дин Смит
На самом деле получается, что если том установлен, производительность ниже. Если я размонтирую, производительность тома будет соответствовать производительности исходного устройства. Это все еще кажется немного странным.
Дин Смит
0

Рабочая нагрузка, создаваемая hdparm -T, не является репрезентативной практически для любого случая использования, кроме потокового чтения из одного большого файла. Кроме того, если производительность является проблемой, не используйте raid5.

Ян Юнгникель
источник
3
Правильно, это не является представителем реальной рабочей нагрузки, я не предполагал, что это так. Это, однако, полезно для сравнения скоростей чтения необработанных устройств. Метаустройство и объем группы томов должны иметь сопоставимые исходные скорости последовательного чтения, а они - нет. В этом суть вопроса.
Дин Смит,
0

Вы можете выяснить, где hdparm проводит свое время, с помощью blktrace (если он находится в режиме ввода-вывода) или oprofile (если он находится на процессоре). Знание установки LVM также поможет (pvdisplay, vgdisplay, lvdisplay).


источник