Испытания RAID контроллера LSI Logic MegaRaid 320-1 64 Mb
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Снова здравствуйте все. Прошу прощения за задержку. Иометр я на сервак поставил. С интерфейсом программы я разобрался, да и с принципами работы теста тоже (почитал FAQ на вашем сервере). Но мне бы хотелось, чтобы ВЫ мне порекомендовали настройки теста, а я проведу тест. Тогда мы получим результаты, которым вы сможете доверять и мы сэкономим время. Что скажете, уважаемые сотрудники Тринити? Тестировать я буду уже RAID 5, т.к. вообще говоря, вчера перевел массив в RAID 5 для дальнейшего тестирования в сандре, и заодно проведу тест иометром с вашими параметрами. Конфигурацию железа вы знаете. Согласны?
Тогда получим результаты теста как сандрой, так и иометром. конечно, потом я опять переведу массив в RAID 0 и RAID 10, и прогоню тесты иометром с вашими настройками.
Тогда получим результаты теста как сандрой, так и иометром. конечно, потом я опять переведу массив в RAID 0 и RAID 10, и прогоню тесты иометром с вашими настройками.
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Итак. Я закончил тестирование сандрой также массива RAID 5, и теперь, объединив результаты этого теста с результатами, полученными при тестировании RAID 0 и RAID 10, получилась некая общая картина. Я переписал отчет заново. Вновь публиковать здесь отчет я не буду, т.к. это займет довольно много места. Вместо этого я разместил его на отдельной страничке:
http://www.dmaltk.narod.ru
Ну, и конечно, я жду параметров тестирования IOmeter от сотрудников Тринити, поскольку, действительно, интересно сопоставить результаты тестирования сандрой и иометром, произведенных в одинаковой среде.
P.S. Конечно, я могу и сам выбрать параметры тестирования в иометре, но мне хотелось бы все-таки получить их от сотрудников Тринити
http://www.dmaltk.narod.ru
Ну, и конечно, я жду параметров тестирования IOmeter от сотрудников Тринити, поскольку, действительно, интересно сопоставить результаты тестирования сандрой и иометром, произведенных в одинаковой среде.
P.S. Конечно, я могу и сам выбрать параметры тестирования в иометре, но мне хотелось бы все-таки получить их от сотрудников Тринити
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
До конфигов - по Вашему тестированию:
- Мерить надо бы не на линейных потоках и не Мбайт/сек , а IOps.
Вот это-то параметр был бы интереснее. Замечу сразу: на наших тестах этот контроллер давал из кэша 5-7К IOps.
1 пока пропускаю
2. Write Thru отключает кэш записи. Вообще . То, что показывает WT - производительность не кэша. но винтов.
3. и далее. RAID -контроллеры (кроме внешних и новых поколений внутренних) вообще не сильны на линейных потоках. Если б Вы померили софтовый RAID на простом HBA - скорее всего, он оказался бы быстрее .
- Мерить надо бы не на линейных потоках и не Мбайт/сек , а IOps.
Вот это-то параметр был бы интереснее. Замечу сразу: на наших тестах этот контроллер давал из кэша 5-7К IOps.
1 пока пропускаю
2. Write Thru отключает кэш записи. Вообще . То, что показывает WT - производительность не кэша. но винтов.
3. и далее. RAID -контроллеры (кроме внешних и новых поколений внутренних) вообще не сильны на линейных потоках. Если б Вы померили софтовый RAID на простом HBA - скорее всего, он оказался бы быстрее .
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Ну, не совсем так, прошу прощения за спор с Вами В журнале Хакер за март 2004 года (ver 12.03 (60) по ихнему, стр. 32) проводились такие тесты. Там тестировались дешевые RAID решения, основанные на встроенных в материнские платы контроллерах, а также программные реализации на основе windows 2000. Использовались ZD Winbench и SiSoft Sandra. Результаты там примерно следующие, привожу данные, полученные сандрой (да простит меня Хакер за перепечатку их материалов :
single Soft Hard Soft Hard
drive RAID 0 RAID 0 RAID 1 RAID 1
Sequental read, mb/sec 54 86 87 54 54
Sequental write, mb/sec 53 86 87 46 46
Random read, mb/sec 8 9 9 15 9
Random write, mb/sec 7 12 13 10 9
Как видите, скорость чтения-записи современных SATA (и IDE) винтов достаточно высоки, и тут MegaRaid действительно выглядит не лучшим образом - примерно такие же скорости показывает и он, хотя дешевые решения все же обгоняет. Но что касается операций случайного чтения-записи, то тут дешевые решения "проседают" очень сильно, и неважно, какая это реализация - soft или hard. В то время как MegaRaid держит те же скорости. Так что после этого, пожалуй, тот факт, что они у него равны (последовательная и случайная скорости, см. отчет), меня начинает скорее радовать, чем огорчать
P.S. Вы почему-то делаете упор только на линейные потоки, а ведь я тестировал MegaRaid также и на операциях случайного вводв-вывода.
P.P.S. Считаю нужным также сообщить дополнительную информацию по тестам. У Сандры количество очередей запросов равно количеству процессоров (в моем случае 4 - HT включен)
single Soft Hard Soft Hard
drive RAID 0 RAID 0 RAID 1 RAID 1
Sequental read, mb/sec 54 86 87 54 54
Sequental write, mb/sec 53 86 87 46 46
Random read, mb/sec 8 9 9 15 9
Random write, mb/sec 7 12 13 10 9
Как видите, скорость чтения-записи современных SATA (и IDE) винтов достаточно высоки, и тут MegaRaid действительно выглядит не лучшим образом - примерно такие же скорости показывает и он, хотя дешевые решения все же обгоняет. Но что касается операций случайного чтения-записи, то тут дешевые решения "проседают" очень сильно, и неважно, какая это реализация - soft или hard. В то время как MegaRaid держит те же скорости. Так что после этого, пожалуй, тот факт, что они у него равны (последовательная и случайная скорости, см. отчет), меня начинает скорее радовать, чем огорчать
P.S. Вы почему-то делаете упор только на линейные потоки, а ведь я тестировал MegaRaid также и на операциях случайного вводв-вывода.
P.P.S. Считаю нужным также сообщить дополнительную информацию по тестам. У Сандры количество очередей запросов равно количеству процессоров (в моем случае 4 - HT включен)
Чтоб не создавать новую тему поделюсь здесь своими испытаниями и наблюдениями.
Конфигурация тестовой машины.
Системная плата Supermicro P3TDL3, 1Gb Ram
2xPIII 1200Mhz
Megaraid 320-01 64Mb в PCI64 слоте, WB включен, firmware 37
4 диска Cheetah 336607LW
Система на отдельном массиве.
Проверить реально режим работы контроллера (PCI32/33 или PCI64/66) не смог, так как никакие доступные тесты не показали реальную частоту и разрядность шины, утилиты контроллера тоже это никак не фиксируют, дергание перемычки на плате (33/66) к изменению результов тестов хотя бы на +/- 0,1% не привело. Остается только взять на веру что шина PCI64 функционирует нормально.
Целью тестирования было проверить зависимость производмтельности дисковой подсистемы от настроек контроллера, прирост производительности по сравнению со старым контроллером.
Тестирование производилось при помощи инструмента Iometer используя стандартные паттерны FileServer и Database для трех типов массивов - Raid5, Raid0 и Raid10
Тестирование производилось на отформативанном разделе NTFS, 4k.
Пробный тест показал, что на пустом диске никакой разницы в результатах по сравнению с RAW режимом нет.
Украшательством не занимался, диаграмма стандартная из Excel, результаты по DB не привожу, так как цифры другие, но тенденции абсолютно теже.
GAM версии 6.01.01 не понравился, намного удобнее все реализовано в текстовом биосе. В GAM замечено некоторое количество багов и невнятное создание и удаление логических дисков. После создания в нем массива и рапорта что все Ок, при перезагрузке массив не был создан. Если сравнивать подобные утилиты для Adaptec и Promise, по понятности и логичности на первом месте Promise, потом Adaptec и только потом LSI.
Выводы:
Дисковая подсистема показывает лучшую производительность при стандартных настройках - Normal и DirectIO. Включение функции Cached IO роняет производительность но не смертельно в Raid10, возможно что на реальных приложениях будет выигрыш. На Raid5 есть ощутимый провал по чтению. Игра с настройками чтения приводит к падению производительности как на паттерне FS так и на паттерне DB.
Производительность массивов уровней 1,10 и 5 абсолютно логично и соотвествует теории. Выводы здесь же выше, что Raid5 на данном контроллер чуть тормознее Raid10 не могу признать состоятельными.
Вопросы по результам:
1. Включение режима Direct IO полность отключает функции кэша или нет? Если полностью, то непонятно зачем тогда нужен кэш на борту и различные ухищрения типа BBU и TBBU.
2. В тесте IOMETER есть результативный параметр Packets/Second. При практически одинаковых результатах IOps и MBps (что фактически одно и тоже, только в разных выражениях) значения этого параметра отдичаются.
Например при глубине очереди 256 цифры для массива Raid10 таковы:
Direct IO
IOps 840
MBps 9
Packets/Second 5
Cached IO
IOps 822
MBps 8.9
Packets/Second 8
3. Судя по тесту увеличение размера блока до 128Кб дает прирост скорости. На форуме же рекомендуют ставить дефолнтный размер 64. Насколько я понимаю рекомендации ставить меньший размер блока уходят корнями в прошлое, когда диски были тормозные и операция чтения занимала продолжительное время. Уменьшение блока приводило к большему дроблению по дискам, увеличиваю при этом у количество запросов, но снижая время самой операции чтения. Сейчас же, IMHO, разница времени чтения 128 против 64 настолько минимальна, что приводит порой к проигрышу при меньшем размере блока, так требуется еще время на обработку запроса. Возможно я не прав - глубоко в процесс работы контроллера и интерфейса не лез, но цифры подтверждают мою правоту и в случае FS и DB.
Конфигурация тестовой машины.
Системная плата Supermicro P3TDL3, 1Gb Ram
2xPIII 1200Mhz
Megaraid 320-01 64Mb в PCI64 слоте, WB включен, firmware 37
4 диска Cheetah 336607LW
Система на отдельном массиве.
Проверить реально режим работы контроллера (PCI32/33 или PCI64/66) не смог, так как никакие доступные тесты не показали реальную частоту и разрядность шины, утилиты контроллера тоже это никак не фиксируют, дергание перемычки на плате (33/66) к изменению результов тестов хотя бы на +/- 0,1% не привело. Остается только взять на веру что шина PCI64 функционирует нормально.
Целью тестирования было проверить зависимость производмтельности дисковой подсистемы от настроек контроллера, прирост производительности по сравнению со старым контроллером.
Тестирование производилось при помощи инструмента Iometer используя стандартные паттерны FileServer и Database для трех типов массивов - Raid5, Raid0 и Raid10
Тестирование производилось на отформативанном разделе NTFS, 4k.
Пробный тест показал, что на пустом диске никакой разницы в результатах по сравнению с RAW режимом нет.
Украшательством не занимался, диаграмма стандартная из Excel, результаты по DB не привожу, так как цифры другие, но тенденции абсолютно теже.
GAM версии 6.01.01 не понравился, намного удобнее все реализовано в текстовом биосе. В GAM замечено некоторое количество багов и невнятное создание и удаление логических дисков. После создания в нем массива и рапорта что все Ок, при перезагрузке массив не был создан. Если сравнивать подобные утилиты для Adaptec и Promise, по понятности и логичности на первом месте Promise, потом Adaptec и только потом LSI.
Выводы:
Дисковая подсистема показывает лучшую производительность при стандартных настройках - Normal и DirectIO. Включение функции Cached IO роняет производительность но не смертельно в Raid10, возможно что на реальных приложениях будет выигрыш. На Raid5 есть ощутимый провал по чтению. Игра с настройками чтения приводит к падению производительности как на паттерне FS так и на паттерне DB.
Производительность массивов уровней 1,10 и 5 абсолютно логично и соотвествует теории. Выводы здесь же выше, что Raid5 на данном контроллер чуть тормознее Raid10 не могу признать состоятельными.
Вопросы по результам:
1. Включение режима Direct IO полность отключает функции кэша или нет? Если полностью, то непонятно зачем тогда нужен кэш на борту и различные ухищрения типа BBU и TBBU.
2. В тесте IOMETER есть результативный параметр Packets/Second. При практически одинаковых результатах IOps и MBps (что фактически одно и тоже, только в разных выражениях) значения этого параметра отдичаются.
Например при глубине очереди 256 цифры для массива Raid10 таковы:
Direct IO
IOps 840
MBps 9
Packets/Second 5
Cached IO
IOps 822
MBps 8.9
Packets/Second 8
3. Судя по тесту увеличение размера блока до 128Кб дает прирост скорости. На форуме же рекомендуют ставить дефолнтный размер 64. Насколько я понимаю рекомендации ставить меньший размер блока уходят корнями в прошлое, когда диски были тормозные и операция чтения занимала продолжительное время. Уменьшение блока приводило к большему дроблению по дискам, увеличиваю при этом у количество запросов, но снижая время самой операции чтения. Сейчас же, IMHO, разница времени чтения 128 против 64 настолько минимальна, что приводит порой к проигрышу при меньшем размере блока, так требуется еще время на обработку запроса. Возможно я не прав - глубоко в процесс работы контроллера и интерфейса не лез, но цифры подтверждают мою правоту и в случае FS и DB.
Последний раз редактировалось Druqn 07 окт 2004, 15:50, всего редактировалось 2 раза.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
По Вашим вопросам:
1. Разница между Direct и Cached I/O по мануалу очень мутная - и кэширование чтения не отключается в любом случае.
2. Про IOps и MBps Вы кардинально не правы - эти параметры если и зависимы, то зависимость - разве что обратная
3. Увеличение блока до 128К дает прирост на практике только в этом паттерне. На самом деле, на типовой задаче (БД), для которой эти контроллеры используются - будет провал, проверено...
Кроме того, контроллеры на стареньких считалках в 66 МГц (320-1) и 100 МГц (320-2) практически уже с полгода как entry-level Современные вещи (320-2Х, готовящийся 320-2Е) имеют куда более мощные считалки (400 и 800 МГц), впрочем, ту же считалку, как и 2Е, имеет и готовящийся 300-8Х (SATA II, считалка 800 МГц - IOP331)
1. Разница между Direct и Cached I/O по мануалу очень мутная - и кэширование чтения не отключается в любом случае.
2. Про IOps и MBps Вы кардинально не правы - эти параметры если и зависимы, то зависимость - разве что обратная
3. Увеличение блока до 128К дает прирост на практике только в этом паттерне. На самом деле, на типовой задаче (БД), для которой эти контроллеры используются - будет провал, проверено...
Кроме того, контроллеры на стареньких считалках в 66 МГц (320-1) и 100 МГц (320-2) практически уже с полгода как entry-level Современные вещи (320-2Х, готовящийся 320-2Е) имеют куда более мощные считалки (400 и 800 МГц), впрочем, ту же считалку, как и 2Е, имеет и готовящийся 300-8Х (SATA II, считалка 800 МГц - IOP331)
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Ну собственно вполне ожидаемые результаты.
Рэйд5 НАМНОГО тормознее, чем рэйд10.
Что касается DirectIO и CachedIO. Насколько я понял из мануала (давно читал правда), в режиме Direct контроллер кидает данные сразу в оперативную память, а в Cached - они остаются и в его кэше тоже. Это касается ТОЛЬКО операций чтения и с режимом WB никак не связано.
И поначалу (на прошивках годичной давности) так оно и было - в режиме Cached шустрее работало чтение случайных блоков, а на линейных потоках было хуже ввиду большей загруженности контроллера. Но в последующих прошивках поведение контроллера резко изменилось и логически объяснить теперь я затрудняюсь. Могу дать только рекомендацию НЕ использовать CachedIO ни в каких задачах. Видимо с покупкой инженеров майлекса внутренние механизмы фирмвари сильно изменились и теперь этот параметр - просто наследие прошлого.
Рэйд5 НАМНОГО тормознее, чем рэйд10.
Что касается DirectIO и CachedIO. Насколько я понял из мануала (давно читал правда), в режиме Direct контроллер кидает данные сразу в оперативную память, а в Cached - они остаются и в его кэше тоже. Это касается ТОЛЬКО операций чтения и с режимом WB никак не связано.
И поначалу (на прошивках годичной давности) так оно и было - в режиме Cached шустрее работало чтение случайных блоков, а на линейных потоках было хуже ввиду большей загруженности контроллера. Но в последующих прошивках поведение контроллера резко изменилось и логически объяснить теперь я затрудняюсь. Могу дать только рекомендацию НЕ использовать CachedIO ни в каких задачах. Видимо с покупкой инженеров майлекса внутренние механизмы фирмвари сильно изменились и теперь этот параметр - просто наследие прошлого.
Про работу впустую честно говоря не понял 8)
Мне интересно было видеть поведение массива при различной нагрузке, а не просто померять производительность и сказать что быстрее. Задачи же сравнить SATA и SCSI вообще не стояло и этих данных на графиках нет.
Следующий шагом я потестирую именно на реальном DB приложении - 1С, не SQL, база под 700Мб - погоняю на отчетах с локали. Тогда можно будет делать выводы о реальном приложении.
И про 300-8Х можно попопдробнее, когда ожидаем? А то файлпомойку скоро время придет поапгрейдить, пока я на 150-6 нацелился, но слыша что SATAII не за горами решил тормознуть, тем более, Promise уже подсуетился.
ЗЫ: А что же за результат в Iometer Packets/Second кто нибудь может сказать? По доступным мне описаловкам теста я его назначения так и не нашел. Единственна закономерность, что по всем тестам Direct vs Cached IOps, Mbps и все остальное очень близки, а вот этот параметр отличается порой в 2 раза в сторону увеличения у Cached.
Мне интересно было видеть поведение массива при различной нагрузке, а не просто померять производительность и сказать что быстрее. Задачи же сравнить SATA и SCSI вообще не стояло и этих данных на графиках нет.
Наверное все таки записи? Судя по полученным данным этот параметр влияет на производительность именно по чтению, по записи практичесик не влияет.a_shats писал(а):1. Разница между Direct и Cached I/O по мануалу очень мутная - и кэширование чтения не отключается в любом случае.
Судя по описаниям самого интела, методики на storage review и экспериментам с калькулятором у меня вышло что MBps = IOps * размер блока или более сложно MBps = op1*Iops*block1+op2*Iops*block2 и т.д, где opN процент операций, block2 размер блока для этой операции. Соотвественно выходит что они зависимы, и в рамках поставленной задачи для относительного сравнения можно оперировать как IOps так и MBps. Кстати уважаемый мною IXBT в своих обзорах оперирует именно параметром MBps, возможно для упрощения восприятия.a_shats писал(а):2. Про IOps и MBps Вы кардинально не правы - эти параметры если и зависимы, то зависимость - разве что обратная
Паттерн DB тоже запускался, результат аналогичен. Соглашусь что Iometer хоть и претендует на точность, но результаты можно воспринимать только как сравнение на текущей (его) задаче. Можно делать выводы о дисках, контроллерах используя одинаковые настройки. Что будет в реальном приложении, особенно когда разница по Iometer минимальна, никто не скажет.a_shats писал(а):3. Увеличение блока до 128К дает прирост на практике только в этом паттерне. На самом деле, на типовой задаче
Следующий шагом я потестирую именно на реальном DB приложении - 1С, не SQL, база под 700Мб - погоняю на отчетах с локали. Тогда можно будет делать выводы о реальном приложении.
А вот здесь если можно поподробнее - не понял связь считалки на контроллере и размер блока? По моему если считалка тормозит, тем более нужно увеличивать размер блока?a_shats писал(а):Кроме того, контроллеры на стареньких считалках в 66 МГц (320-1) и 100 МГц (320-2) практически уже с полгода как entry-level
И про 300-8Х можно попопдробнее, когда ожидаем? А то файлпомойку скоро время придет поапгрейдить, пока я на 150-6 нацелился, но слыша что SATAII не за горами решил тормознуть, тем более, Promise уже подсуетился.
ЗЫ: А что же за результат в Iometer Packets/Second кто нибудь может сказать? По доступным мне описаловкам теста я его назначения так и не нашел. Единственна закономерность, что по всем тестам Direct vs Cached IOps, Mbps и все остальное очень близки, а вот этот параметр отличается порой в 2 раза в сторону увеличения у Cached.
WBR,
Alexander
Alexander
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
1. Нет, это таки чтение.
2. Про ИОпс и МБпс - Вы правы - я ошибся.
3. Там скорее, фирмваре крайнее - ну заточено оно под дефолтный размер страйпа (64К), по всем нашим тестам и рекомендациям LSI.
300-8X - прекрасная по спекам штука. Только - мы и сами еще сэмплов не видели, потому ничего определенного сказать не могу...
2. Про ИОпс и МБпс - Вы правы - я ошибся.
3. Там скорее, фирмваре крайнее - ну заточено оно под дефолтный размер страйпа (64К), по всем нашим тестам и рекомендациям LSI.
300-8X - прекрасная по спекам штука. Только - мы и сами еще сэмплов не видели, потому ничего определенного сказать не могу...
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 62 гостя