Как бы вам обьяснить то чтоб понятно было... Если в рейд контроллере стоит тормозной проц, он будет тормозить на любых уровнях рейда, просто на один больше на других меньше. Десктопный контроллер (какой нить ICH) это вообще не рейд контроллер, т.н. софт рейд. По сути обучный SATA контролллер. В нем вообще нет никакого мозга и да, там ограничения по скорости не будет, винты на линейном трансфере выдают все что могут.nimus писал(а): В режиме RAID-0 быстрого или умного контроллера не надо. Любой десктопный умудряется пропускать 400 МБ/сек, а больше мне и не надо, т.к. шина пропустит только 350-380 МБ/сек. Поэтому я уверен, что скорости контроллера должно быть достаточно. К тому же контроллер за $3500 наврядли искуственно замедлен ниже уровня встроенных в чипсеты простеньких контроллеров.
Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Модераторы: Trinity admin`s, Free-lance moderator`s
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Мож он у вас WB кеш отрубает через какое то время? Например потому, что ему батарейка перестает нравится.nimus писал(а): Теперь главная проблема придумать последовательность действий, которые без временной недоступности контроллера заставят его перейти в нужный режим и, главное, ОСТАВАТЬСЯ В НЕМ.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
проблема явно не имеет отношения к кэшу, т.к. тупит на операциях, не подлежащих кэшированию.ITER писал(а):Мож он у вас WB кеш отрубает через какое то время? Например потому, что ему батарейка перестает нравится.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Вообще все операции проходят через кеш.nimus писал(а):проблема явно не имеет отношения к кэшу, т.к. тупит на операциях, не подлежащих кэшированию.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Ну а если он выключен на уровне контроллера? Не думаю.ITER писал(а):Вообще все операции проходят через кеш.
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Сравнивая с десктопными поделками, Вы забываете об одном:nimus писал(а):Любой десктопный умудряется пропускать 400 МБ/сек
всякий десткопный контроллер оставляет кэш диска включенным, а любой внятный RAID-контроллер первым делом отключает кэш дисков.
После такой операции производительность системы падает в разы.
И единственный способ привести ее к более или менее нормальному состоянию - использовать кэш контроллера.
Если еще и кэш контроллера отключить, то все будет работать со скоростью перфокарт.
Почтовый адрес для связи: a.ivanov@trinitygroup.ru | ICQ: 112586598
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Что значит выключен? Полностью выключить кеш невозможно, можно выключить кеш на запись, но это не значит что кеш перстанет использоваться.nimus писал(а):Ну а если он выключен на уровне контроллера? Не думаю.ITER писал(а):Вообще все операции проходят через кеш.
Ой да ладно вам. На каком нибудь ICH при линейном чтении будет вообще до лампочки, включен кеш у дисков или выключен. При линейном чтении кеш вообще не нужен.exLH писал(а):Сравнивая с десктопными поделками, Вы забываете об одном:nimus писал(а):Любой десктопный умудряется пропускать 400 МБ/сек
всякий десткопный контроллер оставляет кэш диска включенным, а любой внятный RAID-контроллер первым делом отключает кэш дисков.
После такой операции производительность системы падает в разы.
И единственный способ привести ее к более или менее нормальному состоянию - использовать кэш контроллера.
Если еще и кэш контроллера отключить, то все будет работать со скоростью перфокарт.
- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Я про запись.ITER писал(а):При линейном чтении кеш вообще не нужен.
Почтовый адрес для связи: a.ivanov@trinitygroup.ru | ICQ: 112586598
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Тот самый продавец. Поскольку здесь было высказано немало нелестных слов в его адрес, то я вправе представить ожидания заказчика с целью объективной оценки ситуации специалистами. Итак,
Касательно ожидаемой производительности дисковой подсистемы.
Согласно практически полученным данным на наших прочих серверах на массивах более старой архитектуры, а также многочисленным результатам независимых тестов 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 потоков это почти ничего для сервера ))
Прочие показатели также не блещут, например, время доступа. Но давайте сначала разберемся хоть с чем-то.
Вы можете обосновать более низкие показатели ожидаемой производительности для данной конфигурации оборудования? Хотелось бы увидеть ссылки на реально проводимое тестирование близкого к нашему оборудования, где обосновывается причина столь низкой производительности. Судя по характеристикам железа имеющиеся показатели производительности не обоснованы.
С уважением, ************,
Главный специалист по ИТ,
******************
Ваши выводы, коллеги?
Касательно ожидаемой производительности дисковой подсистемы.
Согласно практически полученным данным на наших прочих серверах на массивах более старой архитектуры, а также многочисленным результатам независимых тестов 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 потоков это почти ничего для сервера ))
Прочие показатели также не блещут, например, время доступа. Но давайте сначала разберемся хоть с чем-то.
Вы можете обосновать более низкие показатели ожидаемой производительности для данной конфигурации оборудования? Хотелось бы увидеть ссылки на реально проводимое тестирование близкого к нашему оборудования, где обосновывается причина столь низкой производительности. Судя по характеристикам железа имеющиеся показатели производительности не обоснованы.
С уважением, ************,
Главный специалист по ИТ,
******************
Ваши выводы, коллеги?
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
В смысле вы ждете, что кто то за вас вашу работу сделает? Это ведь вы продавец, вот ВЫ и расскажите почему такая низкая производительность, зачем нам бородатые ссылки на статьи двухлетней давности, в которых тестят софт-рейды?Saler писал(а):Тот самый продавец.
...
Вы можете обосновать более низкие показатели ожидаемой производительности для данной конфигурации оборудования? Хотелось бы увидеть ссылки на реально проводимое тестирование близкого к нашему оборудования, где обосновывается причина столь низкой производительности. Судя по характеристикам железа имеющиеся показатели производительности не обоснованы.
С уважением, ************,
Главный специалист по ИТ,
******************
Ваши выводы, коллеги?
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Мой текст - это первый и последний абзац. Все остальное - цитирование заказчика.
По сути Вашего вопроса, то данная производительность является среднестатистической для данного типа оборудования. Увеличить ее можно путем увеличения числа дисков в массиве, вот и все.
В железке очевидна недоработка производителя - нельзя определить размер страйпа!!!
Здесь, очевидно, присутствует резерв для оптимизации производительности.
К тому же задокументирована она, мягко говоря, не очень - начальный уровень. Задали вопрос вендору, пока без результата.
По сути Вашего вопроса, то данная производительность является среднестатистической для данного типа оборудования. Увеличить ее можно путем увеличения числа дисков в массиве, вот и все.
В железке очевидна недоработка производителя - нельзя определить размер страйпа!!!
Здесь, очевидно, присутствует резерв для оптимизации производительности.
К тому же задокументирована она, мягко говоря, не очень - начальный уровень. Задали вопрос вендору, пока без результата.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Вы располагаете такой статистикой? Хм.. интересно.Saler писал(а): По сути Вашего вопроса, то данная производительность является среднестатистической для данного типа оборудования.
Вы в этом уверены? Что вырастет скорость в линейных операциях? Или только iops'ы на random'е?Saler писал(а): Увеличить ее можно путем увеличения числа дисков в массиве, вот и все.
Ну хоть что-то полезное сделали.Saler писал(а): Задали вопрос вендору, пока без результата.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Очень признателен, практически горд, за Вашу оценку моей работы.
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Раз уж общение с продавцом идет тут, ниже информация для сопоставления ))
Благодаря устранению, при эмуляции нагрузки сервера как сервера баз данных через IOMETER при тех же настройках теста из этого оборудования уже сейчас удалось выжать 1350 IOPS в режиме 0+1 на 6 дисков и 240МБ/сек на линейной записи.
В ИОПСах это в 10 раз больше результата прошлых тестов на RAID 0 на 5 дисков, и в 15 раз больше теста на аналогичном пуле (0+1 на 6 дисков). Так какие всё же "среднестатистические" показания считать верными? 120-140 или 1350? Стоит ли продолжать убеждать, что 140 IOPS на рандомных операциях и 90 МБ/сек на последовательных это нормально? Или есть шанс, что мнение поставщика изменится? Приглашаю посмотреть на реальность цифр, только поможет ли это поставщику?
Очень жаль ПРОЧИХ клиентов, которые получили от продавца такое решение и были убеждены продавцом в том, что это нормально и достаточно быстро. Ну или поставщик немного лукавит, убеждая в среднестатистичности данных. Ведь во всех ответах от поставщика цифры отсутствуют.
Есть всего два варианта: либо поставщик технически безграмотен, либо поставщик крайне недобросовестен в отношении клиентов. Что имеет место в этом случае?
P.S. Линейная запись в один поток пока остается непонятным ограничением, но сервер хоть можно начинать использовать как сервер баз данных. А вот по линейной записи в один поток надо разбираться, где и буду ждать ответа от L2.
С уважением, заказчик )
На данном этапе без помощи поставщика причина была найдена. Писать о ней не хочу, интересно услышать от поставщика.Saler писал(а):По сути Вашего вопроса, то данная производительность является среднестатистической для данного типа оборудования. Увеличить ее можно путем увеличения числа дисков в массиве, вот и все.
Благодаря устранению, при эмуляции нагрузки сервера как сервера баз данных через 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
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Низкая произв-ноcть дисковой подсистемы на IBM BladeCenter S
Коллеги, разборок тут не надо.
По линейной записи - 240м/с есть вполне нормальная цифра. Может быть конечно и больше - только зачем? Главное - иопсы!
По линейной записи - 240м/с есть вполне нормальная цифра. Может быть конечно и больше - только зачем? Главное - иопсы!
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 77 гостей