LINUX.ORG.RU

О скоростях RAID


0

0

Давным давно понравилось мне хранить файлы на домашнем сервере - всегда доступны, легко найти, обновить или переименовать и т.п. Много удобнее кучи болванок в сумке.

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

Захотелось мне RAID. Про встроенные почитал - жуть, лучше не пользоваться, ибо все-одно юзает процессор, при том что часто рассыпается. Софтварный - тоже не то.
Вообщем зхотелось мне RAID 5. Прикупил старенький PCI адаптер Dell CERC ATA 100/4ch (который OEM LSI MegaRAID 100/4ch), подключил к нему 3 barracuda 7200.9 по 500Gb и разочаровался - скорость записи около 5 Mb/sec. Причем как в венде, так и в linux.

Почитал интернет - у многих так. Единственно советовали включить режим кэша write back. У меня сервер на UPS'е, включил - скорость стала от 10 до 15 Mb/sec. Я обрадовался, но не очень.

Сделал вывод, что дело в железе. Захотел современую RAID карточку для PCI-X чтоб SATA II умела, тем более что ATA винты все сложнее купить, по крайней мере в нашей глубинке.

Купил Intel SRCS28X (который OEM LSI MegaRAID MR300-8XPB). Подключил к нему 3 barracuda 7200.11 по 1Tb и разачаровался так, что аж слеза навернулась - такое бабло, и в итоге скорость записи 5 Mb/sec! В настройках рейда write back не включается без бакап батарейки, цена которой 7 т.р. Вообщем купил вместо нее еще одну барракуду и собрал RAID 10 - который для меня был всегда эталоном скорости, надежности и недоступности. Ибо дорого.

И тут я разочаровался в очередной раз. Скорость записи на RAID 10 - 40 Mb/sec максимум. Этож скорость записи на один отдельно взятый винчестер? Где же распараллеливание?

Этот RAID я в windows не тестировал - ибо лень мне ставить винду, да и не буду ей пользоваться, даже если там быстрей будет.

Так вот вопрос в чем - где я не прав? Почему такие скорости?
Или так и надо? А какже тесты в инете? Или LSI - говно, и нужно раскашеливаться на 3ware? Или это Seagate виноваты? Или драйвера в ядре?

А поотдельности к винтам можно обращаться? Какая скорость в таком случае?

YAR ★★★★★
()

У меня на встроенном fakeraid 0 скорость записи как и чтения 250Мб/сек. Венда. И ни разу не рассыпался. А проц он жрет порядка 0,05..0,5% ну да все = я числодробилки на проце не считаю, мне 0,5% не жалко

Karapuz ★★★★★
()

Вообщем-то я натыкался на ветку в англоязычном форуме, где объяснялось, как надо форматировать винчестеры под линукс и freebsd, чтобы выравнивание секторов было правильным и тогда можно добиться нормальных скоростей записи даже на fakeraid 5

Karapuz ★★★★★
()

> Или LSI - говно,

Ну это уж черезчур категорично. Но со скорость у их дешевых рейдов всегда очень грустно было - факт.

anonymous
()

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

LSI не то, чтобы дешевый, скажем он дешевле 3ware. Даже не так, 3ware дороже остальных. Сложно назвать рэйд за 400 $ дешевым. Ну и у меня не LSI нативный, а DELL и Intel.

рейд 0 - это стрип. Надежность падает в 4 раза. А мне для хранения наоборот нужно. Так что о нём речи не идет. Вот софтварный рэйд 5 бывает?

Barlog_M
() автор топика
Ответ на: комментарий от Barlog_M

Soft бывает любой. Я вот 5-й использую на 4*320 Seagate 7200.10, скорость чтения - до 250 Мб/сек, запись могу глянуть. Вполне доволен.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Не, наверное, не гляну, массив забит под завязку и скорость при создании 10 Гб файла - около 100 Мбайт/сек, что не показатель.

YAR ★★★★★
()

В grub.conf играйся с параметрами ядра.

                      |запись| |чтение/запись|
_________________________________________
elevator=deadline       279     74.1
elevator=cfq            276     59.0
elevator=noop           306     74.2
elevator=as             292     73.8

У меня так вышло. Проверял dd if=/dev/zero of=100g bs=100M count=1000

fashka
()
Ответ на: комментарий от Barlog_M

> рейд 0 - это стрип. Надежность падает в 4 раза.

А почему бы не попробовать 1+0? Если дискового пространства не жалко. Есть пере штук таких и именно на LSI (правда сказзи) и скорость вполне приемлемая.

anonymous
()
Ответ на: комментарий от anonymous

> А почему бы не попробовать 1+0? Если дискового пространства не жалко. Есть пере штук таких и именно на LSI (правда сказзи) и скорость вполне приемлемая.

Внимательно читаем первое сообщение - "Вообщем купил вместо нее еще одну барракуду и собрал RAID 10"

Deleted
()

купи BBU, обычно в этом проблема. Это распространнённый случай с LSI.

А вообще, попробуй загнать в софтварный рейд и погонять бенчмарки. Не так плох софтварный рейд как о нём говорят. Собстно минуса два: чуть сильнее грузит проц и можно упереться по шине т.к. обычный pci сильно много не пропустит.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Первый минус - очень существенен - при большой дисковой нагрузке проседает процессор, при большой процессорной нагрузке проседает массив.

Deleted
()
Ответ на: комментарий от Deleted

> RAID6 на 3ware 9650se показатели: http://www.linux.org.ru/jump-message.jsp?msgid=3230050&cid=3230839

Вот копирование 500-метрового файла сразу после перезагрузки:

$ dd if=out of=out2 bs=50000
10000+0 records in
10000+0 records out
500000000 bytes (500 MB) copied, 4.98176 seconds, 100 MB/s
Ну и далее :)
$ sync
$ dd if=out of=out2 bs=50000
10000+0 records in
10000+0 records out
500000000 bytes (500 MB) copied, 2.30628 seconds, 217 MB/s

Deleted
()
Ответ на: комментарий от Deleted

Четырёхядерник решает эту проблему полностью. У меня на старом p4 2.4 при потоке 68+76=144мега в секунду чтения с двух хардов sy занимало 30процентов. Т.е. на core duo это будет процентов 10-15 cpu с одного ядра. По отдельности каждый хард выдаёт под 100метров в секунду, но, видимо, в шину упирается контроллер ich5 :)

Я советую не заморачиваться никакими аппаратными рейдами если хардов <=4.

Под нагрузкой никакой супер-пупер рейд не поможет, если нет ресурсов обрабатывать данные то быстрые диски не помогут. А если речь идёт о копировании то nice и ionice решат проблему.

Ну а про raid5 отдельная песня :)

true_admin ★★★★★
()

вставлю свои пять копеек:

evilhorse andrey # hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   668 MB in  2.00 seconds = 333.28 MB/sec
 Timing buffered disk reads:  302 MB in  3.01 seconds = 100.18 MB/sec
evilhorse andrey # lspci | grep RAID
02:02.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50)
evilhorse andrey # smartctl -i /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.11
Device Model:     ST3500320AS
Serial Number:    5QM2SJ9B
Firmware Version: SD15
User Capacity:    500 107 862 016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Sat Nov  8 20:03:07 2008 EET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

evilhorse andrey # 

generatorglukoff ★★
()
Ответ на: комментарий от true_admin

> /proc/sys/vm/drop_caches избавит от лишних перезагрузок

Но не скажет железному контроллеру сбросить кэш на винты.

Deleted
()
Ответ на: комментарий от Deleted

> Но не скажет железному контроллеру сбросить кэш на винты.

sync? :) Можно использовать длительные тесты чтобы это сильно не сказывалось. Имхо, +-5% роли не играет.

//true_admin

anonymous
()
Ответ на: комментарий от Karapuz

>Вообщем-то я натыкался на ветку в англоязычном форуме, где объяснялось, как надо форматировать винчестеры под линукс и freebsd, чтобы выравнивание секторов было правильным и тогда можно добиться нормальных скоростей записи даже на fakeraid 5

Дело говоришь, это влияет! Смотри опции у mkfs.ext3 -E stride=хх -O dir_index, где xx высчитывается из размера страйпа и кол-ва блоков fs, которые в него влезают https://bugzilla.altlinux.org/show_bug.cgi?id=15041

У меня доисторический P2 233Мгц, два винта ST3320620A, софтовый RAID1, контроллер ITE8212 Dual channel ATA RAID controller.

попугаи:

Timing buffer-cache reads: 128 MB in 1.74 seconds = 73.58 MB/sec Timing buffered disk reads: 64 MB in 1.92 seconds = 33.35 MB/sec

Запись правда все равно медленная, 8-10мб/с, подозреваю что из-за процессора.

WerNA ★★★★★
()
Ответ на: комментарий от WerNA

тогда уж и разделы надо выравнивать по границе этих страйдов :). Но тут дело скорее всего в отсутсвии BBU.

//true_admin

anonymous
()
Ответ на: комментарий от anonymous

> sync? :) Можно использовать длительные тесты чтобы это сильно не сказывалось. Имхо, +-5% роли не играет.

Ещё раз - sync говорит системе сбросить данные на винт. А между винтами и системой стоит довольно умная железка, у которой батарейка и кэш. sync не неё не действует.

Deleted
()
Ответ на: комментарий от true_admin

> Под нагрузкой никакой супер-пупер рейд не поможет

Поправка: "под нагрузкой никакой софтварный райд не поможет".

> если нет ресурсов обрабатывать данные то быстрые диски не помогут.

А на этот случай в хардварных райдах присутствует отдельный процессор и память :) В этом то их и преимущество перед софтовыми.

Deleted
()
Ответ на: комментарий от Deleted

> А на этот случай в хардварных райдах присутствует отдельный процессор

Слабенький. Что очень хорошо заметно в случае того же LSI.

> и память

Медленная и мало.

anonymous
()
Ответ на: комментарий от anonymous

> Слабенький.

Тем не менее он, во-первых, ЕСТЬ, в отличие от софтварного райда. Во-вторых - он там специализированный (ну по-крайней мере, должно быть так)

> Что очень хорошо заметно в случае того же LSI.

Ну я не знаю, как они такого добиваются, честно...

> Медленная и мало.

Опять же - во-первых, она есть. Во-вторых, не медленная :)

Deleted
()
Ответ на: комментарий от Deleted

>> А между винтами и системой стоит довольно умная железка, у которой батарейка и кэш. sync не неё не действует.

размер памяти этой железки сильно ограничен. Поэтому на тесте в десяток гигов это не скажется.

>> Поправка: "под нагрузкой никакой софтварный райд не поможет".

Тут ты не прав.

а) Работа хоть с рейдом хоть с обычным контроллером в любом случае требует ресурсов проца потому как dma занимается только пересылкой данных, а обработка на остаётся на ОС.

б) как только прога хочет считать/записать данные на носитель управление "переходит ядру которое потратит ровно столько процессорного времени сколько требует операция(preemptive, для простоты, не учитываю).

Это значит что не возникнет ситуация когда чтение с диска прекратиться только лишь потому что юзерспейс-проги выжрут проц. Что легко проверить на практике. Запусти сотню cpuburn и попробуй поработать с файлами. Никаких проблем не будет.

//true_admin

anonymous
()
Ответ на: комментарий от anonymous

> размер памяти этой железки сильно ограничен.

Я тестировал софт-рейд (md) и аппаратный контроллер (HPQ SmartArray P400, собственный процессор и 256MB battery-backed кэш) на линуксе, на одном и том же железе.

Так вот, без нагрузки softraid и hwraid дают сравнимые результаты - подъем с диска порядка 300 мегабайт в секунду (мерялось на объеме в 4GB). При мало-мальски серьезной нагрузке на I/O (последовательное чтение одного и того же фрагмента параллельно тремя потоками) производительность softraid падает примерно до 50-80 мегабайт в секунду для каждого потока, при практически нулевом уровне загрузки CPU. Производительность softraid в таком режиме опустилась, но до уровня 180 мегабайт в секунду для каждого потока. На деле это значит, что контроллер с кэшом гораздо лучше "держит" нагрузку.

Еще мы тестировали LSI Megaraid (128 Мб кэш) в режиме кэширования и с отключенным кэшем (RAID5). Опять таки, с кэшом скорость подъема с диска при параллельном чтении в разы выше (примерно 120 мб/секунду с кэшем против 30..40 мегабайт в секунду без кэша).

И да, LSI - г..но.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> Производительность softraid в таком режиме опустилась, но до уровня 180 мегабайт в секунду

Очепятка - следует читать как "Производительность hwraid в таком режиме опустилась, но до уровня 180 мегабайт в секунду"

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

как будет железка под рукой повторю этот опыт и напишу сюда или в admin.

У меня надобности в таких скоростях io не было ибо я сторонник поставить 16гиг оперативы в тачку чем крутые рейды ставить. При таких объёмах всё в оперативе крутиться, поэтому по скоросте все рейды отдыхают(после того как кэш прогреется :)).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> ибо я сторонник поставить 16гиг оперативы в тачку

Угу, вот только у нас _одна_ база 90GB, и рядом еще одна такая же для тестовых целей :-)

no-dashi ★★★★★
()
Ответ на: комментарий от true_admin

>У меня надобности в таких скоростях io не было ибо я сторонник поставить 16гиг оперативы в тачку чем крутые рейды ставить. При таких объёмах всё в оперативе крутиться, поэтому по скоросте все рейды отдыхают(после того как кэш прогреется :)).

В сервер? Ну, это правильное решение. И fakeraid на сервере все = не спасает, надо по-любому хардварный RAID 5, с батарейкой, памятью, блэкджеком и шлюхами

В машину разработчика на питоне? Ну, это выброшенные на ветер деньги, 4 Гб за глаза ему хватит

anonymous
()
Ответ на: комментарий от WerNA

>Дело говоришь, это влияет! Смотри опции у mkfs.ext3 -E stride=хх -O dir_index, где xx высчитывается из размера страйпа и кол-ва блоков fs, которые в него влезают https://bugzilla.altlinux.org/show_bug.cgi?id=15041

Я нашел обещанную ветку: http://forums.storagereview.net/index.php?showtopic=25786 How to achieve superb write speeds with nForce onboard RAID5, 280+MB/sec RAID5 writes with 5 HDD's, 220MB/s with 4, 130MB/sec wi

anonymous
()
Ответ на: комментарий от anonymous

> надо по-любому хардварный RAID 5

raid5 это лажа полная по скорости, ему уже ничего не поможет. Это проверили многие в nginx_ru. Так что как раз в raid5 я бы не особо парился типом рейда ибо это сознательный выбор в пользу ёмкости жертвую производительностью.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

>Может с этим на winfaq лучше?

С чем на winfaq? С вот этим:

>For a FreeBSD system with a default block size of 16K and a 3-drive RAID 5...

> 16K = stripe size x (3 - 1)

> 16K / 2 = stripe size

> 8K = stripe size...



>Using the default 16K block size, I would use a 8K stripe. And if I
where to increase the UFS2 block size to 64K (and fragment to 8K),
then a 32K stripe should be used with a 3-drive RAID 5.

>PS. AFAIK FreeBSD uses auto-tuned block I/O sizing, with minimum I/O
size being the block size for the partition. And the partitioning
tools let you define the start-end sectors, so aligning them to the
stripe width should be an easy task...

Не поймут-с. FreeBSD не Windows, однако

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.