https://opennet.ru/openforum/vsluhforumID3/58500.html Оценка (http://blog.unixstyle.ru/index.php?/archives/66-Hardware-3ware-RAID10-vs-Linux-Software-RAID10.html) производительности аппаратного 3ware RAID10 и программного RAID10 в Linux (md). Linux обогнал 3ware по блочной записи более чем на 126%, по перезаписи на 65%, по блочному чтению на 10%, но проиграл в тесте "random seek" на 37%. <br><br>URL: http://blog.unixstyle.ru/index.php?/archives/66-Hardware-3ware-RAID10-vs-Linux-Software-RAID10.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=23281<br> https://opennet.ru/openforum/vsluhforumID3/58500.html#19 Sun, 06 Sep 2009 20:12:12 GMT Ну у меня на в райде 5 на 2.2тер массиве из 4-х винтов при замене одного винта загрузка одного проца где-то 20-25% (это pIII 1гг) дисковая подсистема конечно тормозит, но она есстессна тормозит и на честном райде. На xeone или хотябы core2 загрузка будет незаметна. Лично я крайне доволен софтовым райдом md под centos 5.3 ядром хотябы потому что отваливались 2 винта в raid5, массив объявлялся оффлайн и после замены одного винта и подключение второго старого все заводилось и нормально работало. Может и были глюки раньше со сменой/модификацие/развитием libata подсистем то щас каких то епик глюков я незамечаю на centos в частности<br>update. им стоит пользоваться в частности из-за того что его можно админить из консоли без перезагрузки. те банальная ситуация была; сервак в 2к км. необходимо было расширить дисковое пространство, местные техники меняли винты с 250 гб на 1 тер, каждый раз перестраивая райд, в итоге после смены 4 винтов я расширил райд на все пространство, и все это без перезагрузок!!! Да сервак лагал https://opennet.ru/openforum/vsluhforumID3/58500.html#16 Fri, 04 Sep 2009 15:54:56 GMT &gt; Смена шедулера или его отключение при этом ни на что не влияет! Это реальный опыт товарищи, а не предположение. На аппаратном рейде без каких либо подкруток это не повторяется.<br><br>И я пишу о реальном случае, реального софтверного райда10. Нагрузка создавалась и на процессор и на io и на дисковую подсистему одновременно. На фоне всей нагрузки еще и тесты скорости файловой системы прогонялись по нескольку суток. Все проблемы с тем что возникал периодически "задумчивый" доступ к диску прошли после выставления noop. Что и рекомендуется при работе с хитрыми блочными устройствами.<br> https://opennet.ru/openforum/vsluhforumID3/58500.html#14 Fri, 04 Sep 2009 12:52:17 GMT Я как-то с помощью bonnie тестировал RAID Smart Array 6i 512Mb с 8-и SAS дисками в сравнении с программным RAID (HP DL380G5, 8Гб, 2x Xeon X5460 3.16ГГц). Сравнивал несколько геометрий RAID. Могу сказать, что в некоторых тестах (скорость перезаписи) разница была до трёх раз в пользу программного RAID. Особенно это заметно на RAID6. На RAID5 разница около двух раз в отдельных тестах, но и на RAID0 в целом программный массив побыстрее аппаратного. <br> https://opennet.ru/openforum/vsluhforumID3/58500.html#13 Fri, 04 Sep 2009 10:19:11 GMT Ты прав я не админ, я их начальник. Но и ты похоже не админ ибо мат.часть хромает по полной, советую покурить топик (http://linuxforum.ru/index.php?showtopic=67731) и иногда заглядывать в исходники и читать рассылки, об этом баге еще в 2007 году писал Линус, на некотором железе он и поныне проявляется в частности на моей рабочей мамке ASUS M2NBP-VM. Софтовый рейд там конечно работать будет, но одна интенсивная операция записи здорово затормозит все остальное (операции чтения/записи), причем CPU будет мало загружен при этом.<br><br>Смена шедулера или его отключение при этом ни на что не влияет! Это реальный опыт товарищи, а не предположение. На аппаратном рейде без каких либо подкруток это не повторяется.<br><br>На некотором железе, а так же на ядрах 2.6.17 этого нет.<br> https://opennet.ru/openforum/vsluhforumID3/58500.html#12 Fri, 04 Sep 2009 08:47:22 GMT Ха-ха-ха :). Чувак, ты явно не админ. Тот баг что ты описываешь не зависит от типа рейда, он на аппаратных точно так же вылезает ибо проблема в libata через который работают дрова твоего "мегарейда". И зря ты своим продакшеном на 500гиг хвастаешься, это немного.<br> https://opennet.ru/openforum/vsluhforumID3/58500.html#10 Fri, 04 Sep 2009 06:33:48 GMT Тут не поспоришь- если ядра загружена на 50% то разницы нет. Прогресс вывел аппартные рэйды из необходимых железок. Другой вопрос, какая там будет загрузка например при замене битых дисков. Или PostgesQL Vacuum хотелось бы сравнить для наглядости. Синтетика она сферического коня в вакууме демонстрирует, а прошивка RAID-ов пишется под реальные операции. <br> https://opennet.ru/openforum/vsluhforumID3/58500.html#9 Fri, 04 Sep 2009 04:22:28 GMT &gt;Ну-ну, я бы посмотрел как ты будешь гонять 500 Гб БД на <br>&gt;софтовом рейде, да к тому же еще и с неисправленным с <br>&gt;версии 2.6.17 багом (якобы после перехода на libata), который на некотором <br>&gt;железе приводит к блокировкам при 1 интенсивной операции записи, которой отдается <br>&gt;приоритет. Все остальное просто висит. Т.е. юзать можно и оно работает, <br>&gt;но не для production. С аппаратными рейдами на том же железе <br>&gt;ситуация не повторяется, все ОК. <br><br>при io шедулере отключенном никаких блокировок нет<br> https://opennet.ru/openforum/vsluhforumID3/58500.html#8 Fri, 04 Sep 2009 04:20:37 GMT 4 ядра, на одно замапить процесс софтрайда... <br> https://opennet.ru/openforum/vsluhforumID3/58500.html#7 Fri, 04 Sep 2009 03:48:32 GMT &gt;Сходится с моими тестами. Тока я gmirror тестировал. Правда, gmirror сильно слил <br>&gt;на поточных операциях, но на random io отыгрался. <br>&gt;<br>&gt;Кстати, это хорошо что развенчивается миф о том что софтварные рейды много <br>&gt;жрут и что это "решение для бедных". Я бы сказал что <br>&gt;lsi это решение для тех у кого слишком много денег :). <br>&gt;<br><br>Ну уже а загрузку цп не учитываем? <br>