Исходное сообщение
"Сравнение производительности аппаратного и программного RAID..." Отправлено Michael Shigorin, 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/) -- кластерные ФС.  Если выкрутиться с дроблением не получается.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>Софт-рейд на большом числе дисков > Это каком? 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/) > -- кластерные ФС. Если выкрутиться с дроблением не получается.
	Введите код, изображенный на картинке: