The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Сравнение производительности аппаратного и программного RAID в Linux, opennews (??), 15-Июл-08, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


29. "Сравнение производительности аппаратного и программного RAID в Linux"  +/
Сообщение от uvi (??), 16-Июл-08, 03:39 
Софт-рейд на большом числе дисков загрузит все ядра и на задачи то не останется. Тест проведен не корректно, при небольшом числе дисков (4-6) на современном железе софт рейд сделает любой (абсолютно любой) аппаратный рейд. Но беда в том, что надо не только читать и писать данные, но и их обрабатывать, так что софт рейд почти годится для серъезных применений.

На самом деле сейчас ситуация плачевная в среднем классе (до 2к$ за контроллер). На сайтах производителей висит реклама, типа наша карточка самая быстрая, типа 600-800Mb/s RAID6 - все это фигня скажу я вам. Перебрал несколько вариантов (от 300$ до 1,5к$ SATA,SCSI,SAS), все они загибаются при нагрузке и система переходит в синхронный режим.
Все работает хорошо при небольшом (до 1000-2000) параллельном количестве читающих/пишущих процессов с недопредельной производительностью (скажем 90% от потенциала проца рейда).

Вся проблема в дизайне рейда. Там проц то один и со всеми винтами он общается ПООЧЕРЕДИ. Также серъезный недостаток - мылй объем кэш и неэффективное его использование.

Вот пример, HP DL360G5 с HP Smart Array 400i 256Mb  с 6 винтами SAS 15k проигрывает старому SCSI SRCU41L с 64мб на реальной задаче с БД. В 2 раза при одинаковой конфигурации распределения дисков по рейдам и в 4-6 раз при RAID5 на новеньком доругещем HP против нескольких RAID1.

Самые топовые контроллеры не держат нагрузку.

А про глюки прошивок лучше промолчать - всплывают тогда, когда итак все плохо. Вообщем надежность аппартаного решения тоже под большим вопросом и вопрос тут в том, предусмотрел ли индусских программист все возможные ситуации...

Вывод один - надо дробить задачи на подзадачи и выносить их на выделенные серверы, так чтобы не доводить до предела нагрузку на аппаратный рейд.

Ответить | Правка | Наверх | Cообщить модератору

31. "Сравнение производительности аппаратного и программного RAID..."  +/
Сообщение от uvi (??), 16-Июл-08, 03:41 
>...так что софт рейд почти годится
>для серъезных применений.

хотел написать тут почти НЕ годится...поправьте плиз.

Ответить | Правка | Наверх | Cообщить модератору

32. "Сравнение производительности аппаратного и программного RAID..."  +/
Сообщение от Michael Shigorinemail (ok), 16-Июл-08, 03:58 
>Софт-рейд на большом числе дисков

Это каком?  16 -- достаточное? :)

>загрузит все ядра и на задачи то не останется.

Ну в ящике, куда можно засунуть "большое количество дисков" -- обычно процессор(ы) и память в качестве довеска к ним.  Задачи выполняются где-то неподалёку.

>Тест проведен не корректно, при небольшом числе дисков (4-6)
>на современном железе софт рейд сделает любой (абсолютно любой) аппаратный рейд.

Не совсем.  Например, если производитель материнки ухитрился очень криво развести то же SATA (пример под руками -- Tyan S2881, SiI3114 на PCI32/33), то может заткнуться и на двух.  При этом железный контроллер в PCI-X намного веселей.

На менее клиническом случае есть риск всё равно заткнуться по шине недалеко от двух.

Другое дело, что на том же пресловутом nForce Pro 2200/2050 SATA раскидано по обоим мостам (как и гигабиты) и всё очень даже стремительным домкратом.

А жалезная Areca или 3ware на 16 SATA-дисках может упереться в свой чахлый камушек и DDR266, даже не в шину.  Бишь построить софтрейд будет в итоге быстрей...

>На самом деле сейчас ситуация плачевная в среднем классе (до 2к$ за
>контроллер). На сайтах производителей висит реклама, типа наша карточка самая быстрая,
>типа 600-800Mb/s RAID6 - все это фигня скажу я вам.

Ну да, кто ж будет вешать рядом нагрузочные данные. :]

>Перебрал несколько вариантов (от 300$ до 1,5к$ SATA,SCSI,SAS), все они загибаются
>при нагрузке и система переходит в синхронный режим.
>Все работает хорошо при небольшом (до 1000-2000) параллельном количестве
>читающих/пишущих процессов с недопредельной производительностью (скажем 90%
>от потенциала проца рейда).

Кстати, диски какие?  С большим количеством читателей лучше 73..146@15k в большем количестве, чем несколько трёхсоток.  А если много временных данных -- посмотрите на tmpfs?

>Вся проблема в дизайне рейда. Там проц то один и со всеми винтами он общается
>ПООЧЕРЕДИ. Также серъезный недостаток - мылй объем кэш и неэффективное его
>использование.

...и это тоже да.

>Вывод один - надо дробить задачи на подзадачи и выносить их на
>выделенные серверы, так чтобы не доводить до предела нагрузку на
>аппаратный рейд.

Есть ещё один вариант (тж. http://new.magic.kiev.ua/ru/solutions/clusters/storage/)
-- кластерные ФС.  Если выкрутиться с дроблением не получается.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

38. "Сравнение производительности аппаратного и программного RAID..."  +/
Сообщение от uvi (??), 16-Июл-08, 04:37 
>Кстати, диски какие?  С большим количеством читателей лучше 73..146@15k в большем
>количестве, чем несколько трёхсоток.  А если много временных данных --
>посмотрите на tmpfs?

Диски именно такие, тормозят на HP400i.
В моей задаче идет чтение/запись в oracle, отдельно на raid1 redo, остальное на 4 x raid10. на raid5 из 6 все вместе еще более плачевно.


Ответить | Правка | Наверх | Cообщить модератору

131. "Сравнение производительности аппаратного и программного RAID..."  +/
Сообщение от Michael Shigorinemail (ok), 18-Июл-08, 00:00 
>Диски именно такие, тормозят на HP400i.

P400i?  Вроде особо плачевного впечатления в DL385 на восьми 2.5" не произвёл...

>В моей задаче идет чтение/запись в oracle

А.  Почти удалось избежать, сорри.  Разве что может иметь смысл попробовать отнести постоянную синхронизируемую запись куда-то отдельным зеркалом (журнал, например).

Вообще бывает полезно глянуть Multi-Disk HOWTO, оно старенькое, но толковое.

>на raid5 из 6 все вместе еще более плачевно.

Эт как раз понятно -- и трансфера, и обсчёта, и seek'ов больше.  И ещё и потоки данных на одних шпинделях смешиваются -- их хорошо помогает разводить.  Трейдофф между унификацией и оптимизацией стораджа :-/

Ответить | Правка | Наверх | Cообщить модератору

135. "Сравнение производительности аппаратного и программного RAID..."  +/
Сообщение от csdoc (ok), 18-Июл-08, 01:45 
> Вот пример, HP DL360G5 с HP Smart Array 400i 256Mb
> с 6 винтами SAS 15k проигрывает старому SCSI SRCU41L с 64мб
> на реальной задаче с БД. В 2 раза при одинаковой конфигурации
> распределения дисков по рейдам и в 4-6 раз при RAID5
> на новеньком доругещем HP против нескольких RAID1.

RAID 5 очень плохо подходит для серверов баз данных,
кроме того имеет ошибку в дизайне, т.н. "write hole",
что может привести к потере/искажению данных массива.

при теперешних обьемах и ценах винтов нет смысла возиться
с RAID 5 / 6 - почти везде будет лучше использовать RAID 10.
разве что с массива в основном только читают и данных очень много.

> Самые топовые контроллеры не держат нагрузку.

а если попробовать в режиме RAID 10 ? RAID 5, RAID 6 и т.п. типы массивов
просто не предназначены для работы с большим количеством операций записи.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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