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

Конфигурирование, планирование RAID систем, возможности, технологии, теория. Qlogic, LSI Logic, Adaptec ...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
sml
member
Сообщения: 26
Зарегистрирован: 17 ноя 2004, 18:48
Откуда: Москва
Контактная информация:

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

Сообщение sml » 30 май 2005, 18:29

Имеем такой стенд:
- 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
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 30 май 2005, 18:43

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

sml
member
Сообщения: 26
Зарегистрирован: 17 ноя 2004, 18:48
Откуда: Москва
Контактная информация:

Сообщение sml » 30 май 2005, 18:52

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

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

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 30 май 2005, 19:18

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

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 31 май 2005, 17:31

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

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

sml
member
Сообщения: 26
Зарегистрирован: 17 ноя 2004, 18:48
Откуда: Москва
Контактная информация:

Сообщение sml » 31 май 2005, 18:36

exLH писал(а):Собсно цель всего этого - померить, что эта система может.
На самом деле, в данном случае Вы измеряете производительность 6-ти дисков. Производительность аппарата имеет смысл мерить дисках на 40...
Возможно
Но нету у нас 40 дисков
А есть 6
И это, видимо, именно так конфигурация, в которой и будет работать наша система. А скорее даже на 4-х...
exLH писал(а): По измерениям:
Вы не указали самое интересное - настройки контроллера. Настройки кэша оказывают решающее влияние на результаты тестов.
Для чтения: ненулевое значение 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
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 31 май 2005, 18:47

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

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 01 июн 2005, 11:57

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

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

Насчет заполнения кэша тоже странно.
При скорость 2Мб/сек и размере кэша 1Гб он должен заполниться минут за 8-9.

Речь не идет о том, что кэш не флушится на диск и из-за этого скорость записи выше (если я не ошибаюсь, то данные старше 20сек автоматически из кэша флушатся). Речь о том, что за счет оптимизации запись происходит эффективнее. Тем более, что Вы настроили флуш так, чтобы он весь кэш сбрасывал на диск после заполнения.

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

sml
member
Сообщения: 26
Зарегистрирован: 17 ноя 2004, 18:48
Откуда: Москва
Контактная информация:

Сообщение sml » 01 июн 2005, 12:00

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

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

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

sml
member
Сообщения: 26
Зарегистрирован: 17 ноя 2004, 18:48
Откуда: Москва
Контактная информация:

Еще одна непонятка

Сообщение sml » 07 июн 2005, 13:13

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 07 июн 2005, 13:44

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

Ответить

Вернуться в «Массивы - RAID технологии.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 15 гостей