В руководстве 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кб размер сегмента.
В смешанной нагрузке запись, как более медленная операция, всегда тянет за собой и чтение, таким образом результаты получаются очень похожи на тест с полностью случайной записью. Видно что на маленьком блоке IO скорость работы систем одинаковая, при большом блоке IO – системы с размером сегмента массива чуть выигрывают.
1. я думаю что в любом случае стоит ставить размер блока кэша системы в 16кб. Поскольку система DS3000 не обладает таким уж быстрым контроллером и не предполагает того, что на неё будут падать десятки тысячи мелких IO в секунду от какой нибудь высоконагруженной БД, кэш будет использоваться нерационально не так уж и часто. Синтетические тесты показывают, что и на маленьком размере блока система не проседает. Изменение размера блока кэша на DS3000 делается командой “set storageSubsystem cacheBlockSize= XX KB;”, где ХХ – размер нового блока. Процедура выполняется мгновенно и применяется ко всей системе.
2. Скорее всего рационально использовать размер сегмента не в 128Кб, по умолчанию, а в 256кб. Я думаю что при реальной нагрузке это как минимум не снизит производительность работы, но вероятно и повысит её в определенных ситуациях. Скорее всего размер сегмента в 128кб по умолчанию сложился исторически с ранних версий прошивок системы.
Изменение размера сегмента для уже созданного луна возможно из командной строки, командой “set logicalDrive ["logicalDriveName"] segmentSize= XX KB ;”, нужно учитывать, что процедура выполняется тем медленее, чем больше размер LUN’а к которой она применяется и чем больше система нагружена, процесс запросто может идти несколько часов. При этом процедура не отменяема и относится к монопольным, и если к примеру в момент перестройки понадобиться переконфигурить еще что ни будь, это не удастся сделать до окончания изменения размера сегмента. Процедура не прерывает доступ к информации в момент своей работы.
