DS-4400 - Непонятные результаты

[sml]

Имеем такой стенд:
- IBM FASTT700 STORAGE SERVER (два контроллера с 1G кэша)
- Шесть дисков 73G x 15K собраны в массив RAID-10
- На этом массиве сделан логический диск на 9Гб
- Этот логический диск подключен к серверу IBM x 336
На сервере SCO OpenServer 5.0.6
Почти все пространство логического диска поделено на 4 куска по 1.8Гб

Для каждого из этих кусков запускается программа (собственного написания), которая читает (или пишет) случайные блоки размером 2К в асинхронном режиме (AIO) по 10 запросов ввода/вывода параллельно.
Собсно цель всего этого - померить, что эта система может.

Так вот.
Мерили разные уровни RAID (в основном 1/10), разное кол-во дисков с разными размерами запросов и т.д.
И все более менее понятно получается.
Но в одном случае результат получается странный.
А именно в описанной выше конфигурации запускался тест чтения (те самые 4 процесса по 10 параллельных случайных запросов чтения), а потом - тест записи (всё то же самое, но блоки пишутся, а не читаются). Скорость записи (1880 kb/sec) получилась больше скорости чтения (1850 kb/sec).
Результат этот довольно стабильный, т.е. он повторяется.
Если еще упростить эксперимент, т.е. свести все к одному сегменту 1.8 Гб и одному процессу, который туда пишет (или читает), то все равно странность остается, даже усиливается. Скорость записи получается 2900, а скорость чтения - 2180 kb/sec.

Пробовали точно так же мерить RAID-1 на двух дисках и RAID-10 на четырех. Числа получаются понятные и этой странности нет. На восьми померить не можем, т.к. есть всего 6 дисков.

Массив больше никем не использовался.
Результат оценивался по:
- SCO'шный sar - это типа системный perfmon
- результат, собственно выдаваемый нашей программой
- результатам perfmon'а, которые показывает виндовая программа управления этим массивом (Storage Manager 9 Client)
Все эти числа практически совпадают.
Числа брались, ессно, не мгновенные, а средние. После того, как они устаканивались (для этого обычно хватает одной..двух минут).

Не то, чтобы это было плохо, а просто непонятно....

Как всё это понимать ?

[a_shats]

Эхе-хе... Ну кто ж мерит рандомные запросы в КБайт/сек
Вы уж определитесь - что хотите в итоге измерить.
В той конфигурации теста, про которую Вы говорите, куда логичнее было бы померить IOps'ы (Input/Output Operations/sec,в терминах перфмона - Disk Transfers/sec). Другой момент - для этого аппарата 4 процесса, а даже и 40 пишущих/читающих нитей - мало и никоим образом его истинной производительности не раскрывают. Надо 100-256, если на случайных запросах (и мерить IOps'ы). А так получается весьма частный случай, имеющий очень слабое отношение к реальности. Или Вы свою задачу моделировали ? Тогда опишите ее поподробнее - попробуем детальнее подсказать, что и как мерить.

[sml]

А в чем разница между килобайтами и IOp'сами ?
Мы ведь запускали запросы размером 2Кб.
Ну, т.е. "прочитать 2048" и "записать 2048".
Со случайного места.
Полученный результат можно выразить в чем угодно.
Полученные килобайты делим на 2 и получаем число операций в секунду. Можно хоть в мегабайтах выразить.
Сути ведь это не меняет...

Насчет количества процессов тоже все не совсем так. Каждый из процессов запускал по 10 параллельных асинхронных запросов. Они действительно работают параллельно и асинхронно. Так что можно считать, что это было 40 процессов. Число процессов вообще никакой роли не играет. Число параллельных запросов - другое дело.

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

[gs]

Я бы это отнес к разряду курьезов. Бывало и не такое - фирмварь контроллеров есть вещь в себе...

[exLH]

Собсно цель всего этого - померить, что эта система может.
На самом деле, в данном случае Вы измеряете производительность 6-ти дисков. Производительность аппарата имеет смысл мерить дисках на 40...
По измерениям:
Вы не указали самое интересное - настройки контроллера. Настройки кэша оказывают решающее влияние на результаты тестов.
Для чтения: ненулевое значение read-ahead multiplier будет негативно влиять на результаты чтения случайных блоков - кроме самого блока будет читаться еще лишних пачка, а вероятность обращения именно к ним при такой нагрузке очень мала.
cache block size большого размера также будет плохо сказываться на результате
Что касается записи, то наверняка включен режим write-back. Значит записываемые блоки попадают в кэш (который наполняется не очень быстро (см. получаемые скорости), а следовательно есть возможность сбросить его (кэш) на диски более оптимальным способом, упорядочив запросы к физическим дискам.
В общих чертах, это и приводит к получаемому соотношению скоростей (хотя все-таки, применительно к случайным запросам, правильнее мерить в IOPs ).

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

[sml]

Собсно цель всего этого - померить, что эта система может.
На самом деле, в данном случае Вы измеряете производительность 6-ти дисков. Производительность аппарата имеет смысл мерить дисках на 40...

Возможно
Но нету у нас 40 дисков
А есть 6
И это, видимо, именно так конфигурация, в которой и будет работать наша система. А скорее даже на 4-х...

По измерениям:
Вы не указали самое интересное - настройки контроллера. Настройки кэша оказывают решающее влияние на результаты тестов.
Для чтения: ненулевое значение read-ahead multiplier будет негативно влиять на результаты чтения случайных блоков - кроме самого блока будет читаться еще лишних пачка, а вероятность обращения именно к ним при такой нагрузке очень мала.
cache block size большого размера также будет плохо сказываться на результате
Что касается записи, то наверняка включен режим write-back. Значит записываемые блоки попадают в кэш (который наполняется не очень быстро (см. получаемые скорости), а следовательно есть возможность сбросить его (кэш) на диски более оптимальным способом, упорядочив запросы к физическим дискам.
В общих чертах, это и приводит к получаемому соотношению скоростей (хотя все-таки, применительно к случайным запросам, правильнее мерить в IOPs ).

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

Настройки контроллера такие:
cache block size = 4Kb
Собсно, можно ставить либо 4, либо 16. Ноль поставить нельзя, по крайней мере такой вариант не предлагается в Storage Manager.

Еще есть настройка start flushing и stop flushing
Измерения проводились при
start flushing = 100%
stop flushing = 0%

write back включен

Настройки логического диска:
все виды кэширования включены
Cache read ahead multiplier = 0
segment size = 64Kb

Больше там покрутить вроде бы нечего.

Насчет заполнения кэша тоже странно.
При скорость 2Мб/сек и размере кэша 1Гб он должен заполниться минут за 8-9. Кроме того, половина кэша, ВРОДЕ БЫ, занята под зеркало второго контроллера. Тест проводился дольше. 10 минут выдержки и собсно 10 минут измерений.

[gs]

Да не озадачивайтесь Вы особо. Такого рода приколов в дисковых системах масса, тем более что 4400 действительно расчитан на куда большие количества винтов и нагрузку (вообще странно видеть такую конфигурацию).
Да и результаты неизвестно какой программы комментировать довольно затруднительно. Лучше иометром бы поглядели.

[exLH]

И это, видимо, именно так конфигурация, в которой и будет работать наша система. А скорее даже на 4-х...
Хочется задать вопрос: а в чем сакральный смысл покупки DS4400 в таком раскладе?

segment size = 64Kb
А зачем так много? Под генерируемую нагрузку чем меньше, тем лучше должно быть.

Насчет заполнения кэша тоже странно.
При скорость 2Мб/сек и размере кэша 1Гб он должен заполниться минут за 8-9.
Речь не идет о том, что кэш не флушится на диск и из-за этого скорость записи выше (если я не ошибаюсь, то данные старше 20сек автоматически из кэша флушатся). Речь о том, что за счет оптимизации запись происходит эффективнее. Тем более, что Вы настроили флуш так, чтобы он весь кэш сбрасывал на диск после заполнения.

P.S. Обратите также внимание на имеющиеся средства мониторинга (Performance Monitor).

[sml]

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

На да ладно. Думаю, тему можно закрыть. Тем более, что там еще забавные зависимости выяснились. То ли в операционке, то ли в драйверах. Скорость записи и чтения зависит от того, с какого блока внути логического диска начинается division. division - это то, на что делится Partition в SCO OpenServer. Если с нечетного, то скорость в полтора раза ниже, чем если с четного. В общем, научное объяснение здесь искать, видимо, не надо...

А конфигурация ПОКА такая. Типа на вырост.

[sml]

Еще вылезла странность.
Не получается у нас запустить более 64 параллельных запросов ввода/вывода с одного сервера. Т.е. можно запустить один процесс, который будет запускать не более 64 запросов или запустить 4 процесса по 16 запросов. Больше - никак.
Все параметры в ядре SCO выкручены на максимум. Они не влияют.
При попытке запуска сверх этого лимита операционка говорит "resource temporarily unavailable".
По идее эта ошибка воозвращается, если не хватает каких-то физических ресурсов.
Вопрос: 64 - это случайно не ограничение HBA ?
HBA стоят такие: LSI7202XP-LC
В инете чего-то не могу найти упоминаний про такое...

[gs]

HBA имеет ограниченное количество одновремено обрабатываемых запросов. Более того, аналогичный параметр есть и у дисковой системы. Так что скорее всего кто-то из них ограничивает.
В большинстве адаптеров есть настройка, позволяющая это дело регулировать. Но я бы советовал не увлекаться, т.к. если с одной дисковой работает много адаптеров и в сумме (в момент пиковой нагрузки) они дадут нагрузку, большую, чем может проглотить дисковая, получите отказ в обслуживании. Собственно уже это может быть обоснованием ограничения числа таггед комманд в HBA.