Низкая скорость чтения/запись mdadm raid 5

Попробуй повысить stripe_cache_size http://habrahabr.ru/post/111036/

raid5 для файла подкачки ? ...
эт мягко говоря лишне

Во-первых, как уже сказали, stripe_cache_size.

Во-вторых, НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ dd КАК БЕНЧМАРК. По крайней мере, со стандартным bs. Лучше используй pv или специальные тесты для ФС.

Сделал как советовали: echo 8192 > /sys/block/md2/md/stripe_cache_size

Координально результат не поменялся:

cat /dev/zero | pv > ./zero.dd
4.76GB 0:01:14 [1.34MB/s]

pv ./zero.dd > /dev/null 
4.76GB 0:00:32 [ 148MB/s] [=================================>] 100% 

Специальный тесты для ФС не подскажите, а то сим вопросом только сегодня озадачился, обычно pv хватало?

А как правильней, в зеркало сей раздел?

да нигде - щас свап только на всякий случай и нужен
суть рейда - сохранить инфу при поломке диска - а в свапе сохранять и нечего
ябы свапу скормил несколько гиг фалик на корневой fs - если лениво делать партицию - но целый рейд5 только для него - это вообще смысла не имеет

Сделал как советовали: echo 8192

А память позволяет? Это лишние 160 Мб под дисковый кэш

первые две секунды со скоростью под 350 метров в секунду выкачивается гиг,

Насколько я понимаю, первые несколько секунд данные идут из дискового кэша. Используй dd [...] iflag=direct . При записи, соответственно - oflag=direct

Во время проверки открой другую консоль и посмотри atop'ом, что именно грузит систему.

Кстати, что такое pv? Искать в репозитории по двум буквам бесполезно :)

Кстати, что такое pv? Искать в репозитории по двум буквам бесполезно :)

Да ну, если учесть что он так и называется. По крайней мере у меня в убунте.

Shell pipeline element to meter data passing through

pv (Pipe Viewer) can be inserted into any normal pipeline between two processes to give a visual indication of how quickly data is passing through, how long it has taken, how near to completion it is, and an estimate of how long it will be until completion.

To use it, insert it in a pipeline between two processes, with the appropriate options. Its standard input will be passed through to its standard output and progress will be shown on standard error.

а в свапе сохранять и нечего

Ага. Это очень весело, когда из-за поломки одного диска вся система просто намертво зависает 8).

Это ж свистелка с прогресс-баром для bash скриптов. Ты уверен что он корректно переварит сотни мегабайт в секунду и несколько гигабайт?

dd сам показыает скорость после завершения операции. Можно и в процессе: kill -USR1 $ddpid

Я? Я вообще мимо проходил. :)

:) Не обратил внимания на ник

я лиш о том - что делать отдельный raid5 для свапа - это перебор

Ты уверен что он корректно переварит сотни мегабайт в секунду и несколько гигабайт?

Легко.

Своп лучше на raid 1. У raid 5 очень плохо с производительностью когда один из дисков отказал. В результате, когда диск «умер», системе и так плохо, а тут у неё будет ещё тормозной swap, там совсем всё может перестать работать.

При замере скорости чтения делайте большой bs и, как вам уже написали, не используйте pipe'ы, dd сам выводит скорость.

И, я как понял, сейчас вы фактически замеряете скорость работы с файлом на файловой системе. По крайней мере чтение можно делать прямо с устройства /dev/md . Да и запись лучше бы тоже тестировать на устройство, загрузившись с другого диска. Хотя при записи нулей данных в файловой системе не останется.

Итак dd if=./zero.dd of=/dev/null bs=100M iflag=direct выдаёт в серднем 130 Мб/с, если смотреть через iotop то скорость скачками 90 или 190.

dd if=/dev/md2 of=/dev/null bs=100M iflag=direct выдаёт 250 Мб/с , тоже самое iotop показывает, запись на прямю я ессно не проверял у меня там система.

dd if=/dev/zero of=./zero.dd bs=100M oflag=direct выдаёт 90 Мб/с.

Сопсна видно что если читать на прямую с рейда то скорость существенно выше, т.е. тормозит файловая система, стоит ext3, можно эту проблему как-нибудь решить?

тесты для ФС не подскажите

вот http://www.iozone.org/

ext3 никогда не отличалась высокой производительностью. Но, в принципе не так уж все плохо. У вас скорость операций с файлом больше половины от скорости операций с RAID'ом. При этом, скорее всего у вас есть ещё обращения к диску от других программ, так как система работает с этого же диска, и это может влиять на результаты, так как позиционирование головок отнимает много времени.

Вобще со скоростью чтения/записи сложно. Во многих жёских дисках скорость работы с последними секторами примерно раза в 2 ниже, чем с начальными. hdparm показывает скорость работы с начальными секторами.

Сопсна меня этот вопрос заинтересовал после сравнения прогона HDtune на железном 2008 сервере с рейдом и на Xen виртуалке с 2008, и вот на железке мне показали 700 мб/с, а на виртуалке 100, после чего я сопнса и заинтересовался сколько у меня чтение/запись уже посредственно на программном рейде, и как показали измерения не на много меньше скорость в виртуалке, а вот то что скорость такая маленькая весьма огорчает.

Казалось бы, при чём тут какая-то винда...

а вот этими рекомендациями http://romanrm.ru/mdadm-raid кто-нить пользовался, особенно интересно узнать на что влияют вот эти параметры при создании ФС stride=,stripe_width= ?

из скольки дисков и какой рэйд используется в 2008 ?

тока что посмотрел, стоит 6 st3450857ss и всё это хозяйство в RAID 6, не мудрено что тест выдаёт скорость 700 метров в секунду