Я пытаюсь настроить свой 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++
?Ответы:
Настройки чтения по умолчанию для LVM действительно пессимистичны. Попробуйте
blockdev --setra 8192 /dev/vg1/vol1
и посмотрите, что из-за этого увеличит вашу производительность LVM. Вы всегда будете получать удар по производительности, используя LVM; мы измеряем его в правильно настроенных системах на уровне примерно 10% производительности базового блочного устройства.источник
У меня нет хорошего объяснения, но я могу подтвердить результаты.
Тестирование RAID (raid5, 4x1.5TB накопители)
Тест тома, который использует md2 в качестве физического устройства.
Я внес изменения, предложенные womble, и увидел такие результаты.
источник
Убедитесь, что вы сравниваете яблоки с яблоками.
hdparm -t
читает с начала устройства, которое также является самой быстрой частью вашего диска, если вы даете ему целый диск (и его вращающиеся тарелки).Убедитесь, что вы сравниваете его с LV в начале диска.
Чтобы увидеть использование карты
pvdisplay -m
.(хорошо, конечно, разница в цифрах может быть незначительной. Но, по крайней мере, подумайте об этом :)
источник
Рабочая нагрузка, создаваемая hdparm -T, не является репрезентативной практически для любого случая использования, кроме потокового чтения из одного большого файла. Кроме того, если производительность является проблемой, не используйте raid5.
источник
Вы можете выяснить, где hdparm проводит свое время, с помощью blktrace (если он находится в режиме ввода-вывода) или oprofile (если он находится на процессоре). Знание установки LVM также поможет (pvdisplay, vgdisplay, lvdisplay).
источник