Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S

[ITER]

В режиме RAID-0 быстрого или умного контроллера не надо. Любой десктопный умудряется пропускать 400 МБ/сек, а больше мне и не надо, т.к. шина пропустит только 350-380 МБ/сек. Поэтому я уверен, что скорости контроллера должно быть достаточно. К тому же контроллер за $3500 наврядли искуственно замедлен ниже уровня встроенных в чипсеты простеньких контроллеров.

Как бы вам обьяснить то чтоб понятно было... Если в рейд контроллере стоит тормозной проц, он будет тормозить на любых уровнях рейда, просто на один больше на других меньше. Десктопный контроллер (какой нить ICH) это вообще не рейд контроллер, т.н. софт рейд. По сути обучный SATA контролллер. В нем вообще нет никакого мозга и да, там ограничения по скорости не будет, винты на линейном трансфере выдают все что могут.

[ITER]

Теперь главная проблема придумать последовательность действий, которые без временной недоступности контроллера заставят его перейти в нужный режим и, главное, ОСТАВАТЬСЯ В НЕМ.

Мож он у вас WB кеш отрубает через какое то время? Например потому, что ему батарейка перестает нравится.

[nimus]

Мож он у вас WB кеш отрубает через какое то время? Например потому, что ему батарейка перестает нравится.

проблема явно не имеет отношения к кэшу, т.к. тупит на операциях, не подлежащих кэшированию.

[ITER]

проблема явно не имеет отношения к кэшу, т.к. тупит на операциях, не подлежащих кэшированию.

Вообще все операции проходят через кеш.

[nimus]

Вообще все операции проходят через кеш.

Ну а если он выключен на уровне контроллера? Не думаю.

[exLH]

Любой десктопный умудряется пропускать 400 МБ/сек

Сравнивая с десктопными поделками, Вы забываете об одном:
всякий десткопный контроллер оставляет кэш диска включенным, а любой внятный RAID-контроллер первым делом отключает кэш дисков.
После такой операции производительность системы падает в разы.
И единственный способ привести ее к более или менее нормальному состоянию - использовать кэш контроллера.
Если еще и кэш контроллера отключить, то все будет работать со скоростью перфокарт.

[ITER]

Вообще все операции проходят через кеш.

Ну а если он выключен на уровне контроллера? Не думаю.

Что значит выключен? Полностью выключить кеш невозможно, можно выключить кеш на запись, но это не значит что кеш перстанет использоваться.

Любой десктопный умудряется пропускать 400 МБ/сек

Сравнивая с десктопными поделками, Вы забываете об одном:
всякий десткопный контроллер оставляет кэш диска включенным, а любой внятный RAID-контроллер первым делом отключает кэш дисков.
После такой операции производительность системы падает в разы.
И единственный способ привести ее к более или менее нормальному состоянию - использовать кэш контроллера.
Если еще и кэш контроллера отключить, то все будет работать со скоростью перфокарт.

Ой да ладно вам. На каком нибудь ICH при линейном чтении будет вообще до лампочки, включен кеш у дисков или выключен. При линейном чтении кеш вообще не нужен.

[exLH]

При линейном чтении кеш вообще не нужен.

Я про запись.

[Saler]

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

Касательно ожидаемой производительности дисковой подсистемы.



Согласно практически полученным данным на наших прочих серверах на массивах более старой архитектуры, а также многочисленным результатам независимых тестов SAS RAID массивов, ожидаемая нами производительность дисковой подсистемы описана ниже для разных типов RAID массивов.

Для практического подтверждения верности расчета их можно сравнить с независимым тестом SAS RAID адаптеров. Например: http://www.thg.ru/storage/highpoint_roc ... epage.html. В тесте по ссылке сравниваются два SAS RAID адаптера стоимостью $150 и $350, 4 HDD Fujitsu MBA3174RC на 15 000 об/мин по 150Gb (один такой HDD дает около 120Мб скорости линейного чтения при 170Мб имеющихся у нас дисков).



RAID 0:

- скорость чтения = (скорость чтения одного HDD * кол-во дисков).

- скорость записи примерно равна скорости чтения (не более чем на 10% ниже).

Например, для 5-ти дисков: скорость линейного чтения = скорость линейной записи = 170Мб/сек * 5 = 850 Мб/сек.

Для тестовой системы на 4 диска из теста выше вот подтверждение:



При средней скорости чтения одного винта около 120 получаем >460 на выходе по линейной скорости чтения.

Для записи:



Запись – около 440Мб/сек на выходе по линейной скорости чтения.



RAID 0+1:

- скорость чтения =

для «умного» контроллера: (скорость чтения одного HDD * кол-во дисков).

для слабого контроллера: (скорость чтения одного HDD * кол-во дисков) / 2.

- скорость записи примерно равна скорости чтения / 2.

Под «умным» тут понимаю контроллер, который понимает, что для RAID 0+1 при чтении 4-х секторов читать можно по сектору со всех винтов и складывать результат. Пусть даже при параноидальной проверке совпадения данных на зеркалируемых томах получим падение скорости в 2 раза, но не более.

Соответственно, для 4-ти дисков:

скорость линейного чтения = 680 (или 340) Мб/сек.

скорость линейной записи = 340Мб/сек.





RAID 5:

- скорость чтения = (скорость чтения одного HDD * (кол-во дисков - 1).

- скорость записи примерно равна скорости чтения минус 10-15%.

Соответственно, для 5-ти наших дисков:

скорость линейного чтения = 680 Мб/сек.

скорость линейной записи > 570 Мб/сек.





Данные показатели линейной скорости не всегда помещаются в шину между SAS контроллером и отдельным лезвием, которая равна 3Gb. Даже если отключить второй контроллер, который должен дать еще 3Gb, то ограниченная шиной скорость получения данных от контроллера к блейду должна быть порядка 380Мб/сек. При этом, если второе лезвие общается с другим лезвием, и скорость массива достаточная (например, при RAID 0 или 5 режима), то и второе лезвие должно не менее шустро получать данные. Шина между корзиной и контроллером не может быть узким местом, т.к. она составляет 4х3Gb на каждый контроллер (т.е. 12Gb одному контроллеру на одну корзину).



Имеющиеся у нас результаты очень далеки от ожидаемых. Так, например, линейная скорость записи при измерении в один поток составляет около 90Мб/сек. И это в один поток! При параллельном запуске теста записи на втором сервере скорость падает. При нагрузочном тестировании через ИОМетер в 8 потоков суммарная скорость записи падает до 35Мб/сек. А 8 потоков это почти ничего для сервера ))



Прочие показатели также не блещут, например, время доступа. Но давайте сначала разберемся хоть с чем-то.



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



С уважением, ************,

Главный специалист по ИТ,
******************

Ваши выводы, коллеги?

[ITER]

Тот самый продавец.
...
Вы можете обосновать более низкие показатели ожидаемой производительности для данной конфигурации оборудования? Хотелось бы увидеть ссылки на реально проводимое тестирование близкого к нашему оборудования, где обосновывается причина столь низкой производительности. Судя по характеристикам железа имеющиеся показатели производительности не обоснованы.



С уважением, ************,

Главный специалист по ИТ,
******************

Ваши выводы, коллеги?

В смысле вы ждете, что кто то за вас вашу работу сделает? Это ведь вы продавец, вот ВЫ и расскажите почему такая низкая производительность, зачем нам бородатые ссылки на статьи двухлетней давности, в которых тестят софт-рейды?

[Saler]

Мой текст - это первый и последний абзац. Все остальное - цитирование заказчика.

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

В железке очевидна недоработка производителя - нельзя определить размер страйпа!!!
Здесь, очевидно, присутствует резерв для оптимизации производительности.

К тому же задокументирована она, мягко говоря, не очень - начальный уровень. Задали вопрос вендору, пока без результата.

[ITER]

По сути Вашего вопроса, то данная производительность является среднестатистической для данного типа оборудования.

Вы располагаете такой статистикой? Хм.. интересно.

Увеличить ее можно путем увеличения числа дисков в массиве, вот и все.

Вы в этом уверены? Что вырастет скорость в линейных операциях? Или только iops'ы на random'е?

Задали вопрос вендору, пока без результата.

Ну хоть что-то полезное сделали.

[Saler]

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

[nimus]

Раз уж общение с продавцом идет тут, ниже информация для сопоставления ))

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

На данном этапе без помощи поставщика причина была найдена. Писать о ней не хочу, интересно услышать от поставщика.
Благодаря устранению, при эмуляции нагрузки сервера как сервера баз данных через IOMETER при тех же настройках теста из этого оборудования уже сейчас удалось выжать 1350 IOPS в режиме 0+1 на 6 дисков и 240МБ/сек на линейной записи.
В ИОПСах это в 10 раз больше результата прошлых тестов на RAID 0 на 5 дисков, и в 15 раз больше теста на аналогичном пуле (0+1 на 6 дисков). Так какие всё же "среднестатистические" показания считать верными? 120-140 или 1350? Стоит ли продолжать убеждать, что 140 IOPS на рандомных операциях и 90 МБ/сек на последовательных это нормально? Или есть шанс, что мнение поставщика изменится? Приглашаю посмотреть на реальность цифр, только поможет ли это поставщику?

Очень жаль ПРОЧИХ клиентов, которые получили от продавца такое решение и были убеждены продавцом в том, что это нормально и достаточно быстро. Ну или поставщик немного лукавит, убеждая в среднестатистичности данных. Ведь во всех ответах от поставщика цифры отсутствуют.

Есть всего два варианта: либо поставщик технически безграмотен, либо поставщик крайне недобросовестен в отношении клиентов. Что имеет место в этом случае?

P.S. Линейная запись в один поток пока остается непонятным ограничением, но сервер хоть можно начинать использовать как сервер баз данных. А вот по линейной записи в один поток надо разбираться, где и буду ждать ответа от L2.

С уважением, заказчик )

[gs]

Коллеги, разборок тут не надо.

По линейной записи - 240м/с есть вполне нормальная цифра. Может быть конечно и больше - только зачем? Главное - иопсы!