Arial Georgia Tahoma Times New Roman Verdana

Описание теста Intel IOMeter

Изначально для тестирования дисков нами был выбран Adaptec ThreadMark 2.0. Врожденным недостатком данного теста являлась малая информативность — всего одно средневзвешенное результирующее значение. Кроме того, в последнее время при тестировании новых «быстрых» дисков начала вызывать серьезные сомнения и достоверность результатов. По крайней мере, корреляция с результатами WinBench стала практически пропала. В создавшейся ситуации я решил последовать примеру ведущего сайта в области носителей информации — StorageReview и перейти к использованию теста Intel IOMeter.

При использовании теста я пользовался методикой, разработанной StorageReview. Те, кто хочет прочитать данную методику в оригинале, могут прочитать ее там же (раздел Operating Systems and Benchmarks — Part 4). Я же далее приведу краткое описание теста и методики тестирования.

IOMeter, в отличие, например, от WinBench, основанного на реальных приложениях, является полностью синтетическим тестом. Это придает ему очень большую гибкость и одновременно создает массу сложностей при настройке для тестера. Дополнительные сложности вызывает тот факт, что можно тестировать не только один диск на однопроцессорной машине (чем мы занимаемся), но и дисковые массивы в многопроцессорных конфигурациях и даже совокупность компьютеров в сети. Впрочем, далее эти возможности рассматриваться не будут.

IOMeter работает с так называемыми «workers». Intel рекомендует создавать по одному «рабочему» на процессор, поэтому в дальнейшем считаем, что worker у нас один. Далее, каждый worker тестирует «цель» или «цели» (target), которые представляют собой либо неразделенный (unpartitioned) физический диск, либо один или несколько разделов (partition) на диске. Дальше начинается самое интересное. Каждому worker может быть присвоена «модель доступа» (access pattern), которая представляет собой набор параметров, в соответствии с которыми данный worker организует доступ к target.

Вы еще следите за изложением? Тогда идем дальше. Модель доступа содержит следующие переменные:

• Transfer Request Size — минимальный блок данных, к которому может обращаться тест.
• Percent Random/Sequential Distribution — процент запросов, являющихся случайными. Остальные, естественно, являются последовательными.
• Percent Read/Write Distribution — процент запросов на чтение. Еще одна важная переменная, прямо не входящая в модель доступа — # of Outstanding I/Os — определяет число одновременных запросов ввода/вывода для данного worker-а и, соответственно, загрузку диска.

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

Итак, для тестов предлагаются 3 модели доступа — File Server (модель определена Intel и идет в комплекте с IOMeter), Workstation и Database (определены StorageReview). Ниже приведена таблица параметров для каждой модели, взятая опять-таки со StorageReview(раздел Operating Systems and Benchmarks — Part 5 ). Там же вы можете прочитать и о причинах выбора таких моделей.

Теперь о том, что касается параметра # of Outstanding I/Os. Если этот параметр установить равным 1, то, в сочетании со 100%-м значением Percent Random/Sequential Distribution получаем фактически измерение значения времени случайного доступа (random access time). Значение 4 соответствует загрузке элементарного приложения типа Windows Calculator. Как показали исследования, проведенные специалистами StorageReview, в среднем на реальных приложениях этот параметр принимает значение 30-50. Значение параметра больше 100 соответствует большой загрузке диска (например, при дефрагментации). В соответствии с этим предлагается проводить тесты с использованием пяти следующих значений данного параметра.

Кроме этого, можно устанавливать время выполнения теста (в Trial Version, к сожалению, только вручную — нажатием на кнопку STOP) и время от начала работы теста до начала измерений (rump-up time). Тут я так же не стал оригинальничать и вслед за коллегами принял время выполнения каждого из 15 тестов (5 видов загрузки для каждой из 3 моделей доступа) равным 10 минутам, а задержку rump-up — равной 30 секундам. Тестируются физические диски (не поделенные на разделы и неформатированные).

Теперь самое важное — что же мы получаем на выходе. Опять-таки вслед за коллегами я включил в обзоры следующие результаты.

• Total I/Os Per Second — среднее число запросов, выполненных за секунду. Запрос состоит из позиционирования и чтения/записи блока соответствующего размера.
• Total MBs Per Second — то же самое, но другими словами. В случае моделей, работающих с блоками одного размера (Workstation и Database) — просто произведение Total I/Os Per Second на размер блока.
• Average I/O Response Time — для линейной (1 outstanding I/O) загрузки — опять-таки то же, что и Total I/Os Per Second (Total I/Os Per Second = 1000 milliseconds / Average I/O Response Time). С возрастанием загрузки значение возрастает, но нелинейно. Результат зависит от оптимизации drive firmware, шины и операционной системы.
• CPU Effectiveness, или, иначе, I/Os per % CPU Utilization — с этим все ясно.