The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Оценка производительности аппаратного 3ware RAID10 и программного RAID10 в Linux

03.09.2009 23:14

Оценка производительности аппаратного 3ware RAID10 и программного RAID10 в Linux (md). Linux обогнал 3ware по блочной записи более чем на 126%, по перезаписи на 65%, по блочному чтению на 10%, но проиграл в тесте "random seek" на 37%.

  1. Главная ссылка к новости (http://blog.unixstyle.ru/index...)
Лицензия: CC-BY
Тип: Обобщение
Короткая ссылка: https://opennet.ru/23281-raid
Ключевые слова: raid, benchmark, linux
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (14) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, prapor (??), 23:53, 03/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Приедет заказанный 9650SE-4LPML, надо будет погонять аналогичный тест.
     
  • 1.2, Одмин (?), 01:18, 04/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сходится с моими тестами. Тока я gmirror тестировал. Правда, gmirror сильно слил на поточных операциях, но на random io отыгрался.

    Кстати, это хорошо что развенчивается миф о том что софтварные рейды много жрут и что это "решение для бедных". Я бы сказал что lsi это решение для тех у кого слишком много денег :).

     
     
  • 2.3, Аноним (-), 02:33, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну-ну, я бы посмотрел как ты будешь гонять 500 Гб БД на софтовом рейде, да к тому же еще и с неисправленным с версии 2.6.17 багом (якобы после перехода на libata), который на некотором железе приводит к блокировкам при 1 интенсивной операции записи, которой отдается приоритет. Все остальное просто висит. Т.е. юзать можно и оно работает, но не для production. С аппаратными рейдами на том же железе ситуация не повторяется, все ОК.
     
     
  • 3.4, аноним (?), 02:37, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе про gmirror а ты про глюки линуксов. У меня на gmirror весь продакшен, с железными недорайдами тоже намучался в свое время. Они не решение для бедных и не решение для тех у кого слишком много денег. Они - решение для тех кто головой думать не способен.
     
  • 3.5, Lindemidux (??), 07:36, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ставишь BFQ и нет бага.
     
  • 3.9, PSV (?), 08:22, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну-ну, я бы посмотрел как ты будешь гонять 500 Гб БД на
    >софтовом рейде, да к тому же еще и с неисправленным с
    >версии 2.6.17 багом (якобы после перехода на libata), который на некотором
    >железе приводит к блокировкам при 1 интенсивной операции записи, которой отдается
    >приоритет. Все остальное просто висит. Т.е. юзать можно и оно работает,
    >но не для production. С аппаратными рейдами на том же железе
    >ситуация не повторяется, все ОК.

    при io шедулере отключенном никаких блокировок нет

     
  • 3.12, Одмин (?), 12:47, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ха-ха-ха :). Чувак, ты явно не админ. Тот баг что ты описываешь не зависит от типа рейда, он на аппаратных точно так же вылезает ибо проблема в libata через который работают дрова твоего "мегарейда". И зря ты своим продакшеном на 500гиг хвастаешься, это немного.
     
     
  • 4.13, Аноним (-), 14:19, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ты прав я не админ, я их начальник. Но и ты похоже не админ ибо мат.часть хромает по полной, советую покурить топик (http://linuxforum.ru/index.php?showtopic=67731) и иногда заглядывать в исходники и читать рассылки, об этом баге еще в 2007 году писал Линус, на некотором железе он и поныне проявляется в частности на моей рабочей мамке ASUS M2NBP-VM. Софтовый рейд там конечно работать будет, но одна интенсивная операция записи здорово затормозит все остальное (операции чтения/записи), причем CPU будет мало загружен при этом.

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

    На некотором железе, а так же на ядрах 2.6.17 этого нет.

     
     
  • 5.16, PSV (?), 19:54, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Смена шедулера или его отключение при этом ни на что не влияет! Это реальный опыт товарищи, а не предположение. На аппаратном рейде без каких либо подкруток это не повторяется.

    И я пишу о реальном случае, реального софтверного райда10. Нагрузка создавалась и на процессор и на io и на дисковую подсистему одновременно. На фоне всей нагрузки еще и тесты скорости файловой системы прогонялись по нескольку суток. Все проблемы с тем что возникал периодически "задумчивый" доступ к диску прошли после выставления noop. Что и рекомендуется при работе с хитрыми блочными устройствами.

     
  • 2.7, Аноним (-), 07:48, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Сходится с моими тестами. Тока я gmirror тестировал. Правда, gmirror сильно слил
    >на поточных операциях, но на random io отыгрался.
    >
    >Кстати, это хорошо что развенчивается миф о том что софтварные рейды много
    >жрут и что это "решение для бедных". Я бы сказал что
    >lsi это решение для тех у кого слишком много денег :).
    >

    Ну уже а загрузку цп не учитываем?

     
     
  • 3.8, PSV (?), 08:20, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    4 ядра, на одно замапить процесс софтрайда...
     
     
  • 4.10, tesseract (ok), 10:33, 04/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Тут не поспоришь- если ядра загружена на 50% то разницы нет. Прогресс вывел аппартные рэйды из необходимых железок. Другой вопрос, какая там будет загрузка например при замене битых дисков. Или PostgesQL Vacuum хотелось бы сравнить для наглядости. Синтетика она сферического коня в вакууме демонстрирует, а прошивка RAID-ов пишется под реальные операции.  
     
     
  • 5.19, Elenium (ok), 00:12, 07/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну у меня на в райде 5 на 2.2тер массиве из 4-х винтов при замене одного винта загрузка одного проца где-то 20-25% (это pIII 1гг) дисковая подсистема конечно тормозит, но она есстессна тормозит и на честном райде. На xeone или хотябы core2 загрузка будет незаметна. Лично я крайне доволен софтовым райдом md под centos 5.3 ядром хотябы потому что отваливались 2 винта в raid5, массив объявлялся оффлайн и после замены одного винта и подключение второго старого все заводилось и нормально работало. Может и были глюки раньше со сменой/модификацие/развитием libata подсистем то щас каких то епик глюков я незамечаю на centos в частности
    update. им стоит пользоваться в частности из-за того что его можно админить из консоли без перезагрузки. те банальная ситуация была; сервак в 2к км.  необходимо было расширить дисковое пространство, местные техники меняли винты с 250 гб на 1 тер, каждый раз перестраивая райд, в итоге после смены 4 винтов я расширил райд на все пространство, и все это без перезагрузок!!! Да сервак лагал пару суток но люди зато хоть как-то работали с серваком.
     

  • 1.14, Аноним (-), 16:52, 04/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я как-то с помощью bonnie тестировал RAID Smart Array 6i 512Mb с 8-и SAS дисками в сравнении с программным RAID (HP DL380G5, 8Гб, 2x Xeon X5460 3.16ГГц). Сравнивал несколько геометрий RAID. Могу сказать, что в некоторых тестах (скорость перезаписи) разница была до трёх раз в пользу программного RAID. Особенно это заметно на RAID6. На RAID5 разница около двух раз в отдельных тестах, но и на RAID0 в целом программный массив побыстрее аппаратного.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру