IBM DS3400 размер блока массива R10 и размер блока кэша системы

Вопрос который меня давно интересовал – как в цифрах будет влиять изменение размера сегмента райда на производительность на разных размерах блока нагрузки.

Что такое вообще размер сегмента, segment size в терминологии IBM? В DS3000/4000 это размер данных, который должен быть записан на диск или прочитан с диска, перед тем, как система продолжит запись/чтение на следующий диск.

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

В чистой теории максимальная производительность достигается тогда, когда размер страйпа диска максимально приближен к размеру IO которым система создающая нагрузку взаимодействует с самой системой. С другой стороны все рекомендации производителей дисковых систем сводятся к тому, что нужно выбирать размер страйпа для массива по умолчанию, что фактически означает прямую зависимость оптимизации кода прошивки контроллера под конкретный размер страйпа массива. В 3400 системе по умолчанию это 128кб, для медиа контента (большие файлы) предлагается блок 256кб. Вообще размер этого самого страйпа может меняться шагами 16-32-64-128-256-512 кб.

В руководстве IBM дает только 2 принципиальных рекомендации по размеру сегмента:
1. Для маленького IO размер сегмента массива должен быть равен или больше, чем размер IO.
2. Размер IO не обязательно должен совпадать с размером сегмента для достижения максимальной производительности.

Около полугода назад я ставил тест при повышении размера страйпа с 32 до 512 кб и замерами производительности и был изрядно удивлен тем, что на любом типе нагрузки максимальная скорость достигалась на размере сегмента 128 или 256 кб, даже на самых маленьких размерах IO. Сейчас я проделывал туже операцию на DS3400 сконцентрировавшись на 2-х размерах сегмента: 128кб (по умолчанию) и 256кб (предлагается системой для медиа нагрузки). Также я менял размер блока кэша системы с 4кб (по умолчанию) на 16кб, это максимальное значение для данной системы.

Управление размером кэша производится на уровне всей системы целиком и в DS3400 делается из консольной строки.

Тесты проводились на 2-х контроллерной системе DS3400 подключенной через FC свитч к 1 портовому FC HBA на сервере который создавал рабочую нагрузку. В каждом контроллере системы стоит по 512МБ кэша. Ниже представлены диаграммы на которых видно влияние тех или иных настроек на производительность системы.

Последовательное чтение

Из результатов видно, что изменяемые характеристики не имею сильного влияния на производительность, ясно видно что система быстро доходит до порога 400 мб/сек, ограничения сервера с одним HBA адаптером и перестает расти. На меньших скоростях видно, что в точке, где размер IO совпадает с размером блока кэша достигает повышение производительности относительно соседних результатов.

Последовательная запись

На графиках ясно виден результат рекомендации IBM “сегмент больше или равен IO” только сильнее это видно не на сегменте массива, а на размере блока кэша. Наглядно видно насколько выше результаты система дает, когда работает с кэшем нежели чем с дисковой емкостью. Наилучший результат получается в случае кэш-16кб, сегмент 256кб.

Случайное чтение

Также, как и в последовательном чтении, видно, что изменяемые настройки практически не влияют на производительность системы. можно отметить что в конфигурации 16кб кэш блок, 256кб сегмент система быстрее всего доходит до потолка интерфейса в 400МБ, при этом не теряя в производительности на маленьком блоке.

Случайная запись

Видно, что на маленьком блоке IO значения практически не влияют на IOPS, а на большом чуть быстрее оказывается 16кб блок кэша, 256кб размер сегмента.

Смешанная нагрузка (33% чтение), 100% случайная

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

Какие можно сделать выводы?

1. я думаю что в любом случае стоит ставить размер блока кэша системы в 16кб. Поскольку система DS3000 не обладает таким уж быстрым контроллером и не предполагает того, что на неё будут падать десятки тысячи мелких IO в секунду от какой нибудь высоконагруженной БД, кэш будет использоваться нерационально не так уж и часто. Синтетические тесты показывают, что и на маленьком размере блока система не проседает. Изменение размера блока  кэша на DS3000 делается командой “set storageSubsystem cacheBlockSize= XX KB;”, где ХХ – размер нового блока. Процедура выполняется мгновенно и применяется ко всей системе.

2. Скорее всего рационально использовать размер сегмента не в 128Кб, по умолчанию, а в 256кб. Я думаю что при реальной нагрузке это как минимум не снизит производительность работы, но вероятно и повысит её в определенных ситуациях. Скорее всего размер сегмента в 128кб по умолчанию сложился исторически с ранних версий прошивок системы.
Изменение размера сегмента для уже созданного луна возможно из командной строки, командой “set logicalDrive  ["logicalDriveName"] segmentSize= XX KB ;”, нужно учитывать, что процедура выполняется тем медленее, чем больше размер LUN’а к которой она применяется и чем больше система нагружена, процесс запросто может идти несколько часов. При этом процедура не отменяема и относится к монопольным, и если к примеру в момент перестройки понадобиться переконфигурить еще что ни будь, это не удастся сделать до окончания изменения размера сегмента. Процедура не прерывает доступ к информации в момент своей работы.

Книжка по теме:
http://www.redbooks.ibm.com/abstracts/sg246363.html?Open - DS4000 Best Practices and Performance Tuning Guide