Применение IOMeter для тестирования. Методика www.StorageReview.com.

Автор: Eugene Ra
Дата: 20.07.2001
Все фото статьи

Примечание


Перевод и публикация этой статьи выполнены с любезного разрешения Eugene Ra, автора и ведущего сайта StorageReview.
С оригиналом этой статьи можно ознакомится здесь.
Автор перевода - Анна Филатова, aka Rat.

Представляем IOMeter от Intel


Раньше из всех синтетических тестов мы предпочитали ThreadMark 2.0. Однако, довольно скоро мы заметили, что прослеживается некоторая взаимосвязь между результатами в ThreadMark и скоростью передачи последовательных данных, измеряемой тестом WinBench. Нигде это не проявлялось так явно как при тестировании ThreadMark’ом производительности конфигураций RAID 0 (в отличие от очень незначительного прироста в WinBench) и при тестировании с жесткими дисками семейства Quantum Bigfoot, которые хотя и славятся своей медлительностью, но все же демонстрируют более или менее приемлемую скорость передачи последовательных данных. Мы уже давно подумывали о том, чтобы отказаться от использования этого теста. Однако каждый раз, когда мы осторожно намекали на наше решение, мы получали гору писем, в которых пользователи умоляли нас не отказываться от этого теста, поскольку он, якобы, очень точно отражал действительность. Последней каплей, переполнившей чашу нашего терпения, стала весьма неожиданная реакция самих разработчиков ThreadMark, представителей компании Adaptec: их заметно развеселил тот факт, что мы использовали ThreadMark в качестве полноценного бенчмарка для наших исследований. Совет, который мы получили от них, еще раз подтверждает. Что мы с самого начала были на правильном пути: специалисты из компании Adaptec порекомендовали нам воспользоваться IOMeter от Intel.
Хотя интерфейс IOMeter далеко не самый удобный, эту утилиту безусловно отличает исключительная гибкость в использовании. В отличие от WinBench 99, который использует реальные приложения, IOMeter работает в чисто синтетической среде. Однако именно синтетическая природа этого теста обуславливает его гибкость и настраиваемость на конкретные цели и задачи.
Возможности, которые открывает перед нами эта программа, выходят далеко за рамки обычного тестирования на одной платформе, к чему мы уже привыкли здесь, на StorageReview. Эта утилита позволяет тестировать многопроцессорные конфигурации, равно как и конфигурации с несколькими жесткими дисками и даже сети из нескольких укомплектованных систем. В настоящей статье мы остановимся на тестировании индивидуальной системы, построенной на одном жестком диске.
IOMeter может создавать несколько рабочих программ (Intel рекомендует использовать одну программу для тестирования системы с одним процессором). Каждая программа работает либо с неразбитым на разделы “физическим диском”, либо с разделом (ами) в пределах одного диска. Также, каждой программе приписывается определенная “модель доступа”, представляющая собой набор параметров, которые обуславливают доступ программы к тестируемому элементу.

Переменные, составляющие модель доступа, включают:

Размер запроса на передачу данных. Это минимальная единица, с которой работает программа. Поскольку данные передаются последовательно, это значение будет удваиваться, утраиваться, и т.п.

Случайное/последовательное распределение (в %). Эта переменная означает, какой процент запросов носит случайный характер. Если запрос не случаен, то, соответственно, он относится к разряду последовательных.

Распределение операций чтения/записи (в %). Эта переменная означает, какой процент операций приходится на чтение (относительно количества операций, приходящихся на запись).Эти три основные категории могут быть объединены в общий процент (Percentage of Access Specification), который вместе с остальными параметрами составит совокупную модель доступа, подходящую для любого случая.

И наконец последний параметр, о котором хотелось бы сказать несколько слов, это количество отдельных операций ввода/вывода, то есть такой параметр, который может быть приписан каждой рабочей программе, что тем самым позволит моделировать уникальную нагрузку на тестируемый элемент в каждом конкретном случае.Что, запутались? Действительно, все это несколько сложно объяснить на пальцах. Но, поверьте, сама программа совсем не такая сложная, как может показаться. Однако один факт наверняка сомнений не вызывает. Учитывая исключительную настраиваемость утилиты невольно встает вопрос: что же показывает на самом деле модель доступа и нагрузка?

Тестирование


Попытаемся оценить производительность различных жестких дисков в условиях работы в серверах и рабочих станциях. Первый случай довольно прост для реализации, поскольку IOMeter комплектуется уже составленной моделью обращения к данным. Что же касается второго пункта, рабочих станций, то тут, как это ни странно, ни Intel, ни производители жестких дисков, к которым мы обращались, не согласились предоставить необходимые данные для моделирования этих условий тестирования.
В общем, вполне очевидно, что в случае рабочей станции преобладает случайное (не последовательное) обращение к данным (именно поэтому ThreadMark и был отвергнут, как тест). Даже результаты, полученные в WinBench, подтверждают эту мысль. Вопрос: насколько велик должен быть процент случайных обращений?
Хотя сначала загрузка exe-файлов, DLL и других библиотек представляет собой последовательный процесс, все последующие обращения носят случайный характер. Даже несмотря на то, что файлы могут быть достаточно большого размера, части файлов постоянно посылаются в файл подкачки (swapfile) и изымаются из него. Сильно фрагментированные обращения к этому файлу случайны. Exe-файлы вызывают другие важные файлы с графическими изображениями, звуком, и т.п. Хотя сами по себе эти файлы могут представлять собой крупные цепочки данных, обращение к которым происходит последовательно, совокупный процент все равно будет меньше процента случайных обращений и обмена данными между системными файлами. А если ещё и учесть то, что, к сожалению, существует такое досадное явление, как фрагментация файлов на винчестере, то принятая нами модель кажется нам самой близкой к реальности.
Также под вопросом и соотношение операций чтения и записи. В большинстве систем в режимах ввода/вывода доминируют операции чтения. Операции записи имеют место в случае установки приложений, при записи файлов данных, и, что особенно важно, при записи файлов подкачки (swapfiles). Только в случае записи больших объемов данных в режиме реального времени (A/V) операции записи могут стать преобладающими.

Модели платформ


StorageReview.com работал со следующими моделями доступа:

Паттерны IOMeter от StorageReview
 % of Access Specification Transfer Size Request % Reads % Random
 File Server Access Pattern*   
 10% 0.5 KB 80% 100%
 5% 1 KB 80% 100%
 5% 2 KB 80% 100%
 60% 4 KB 80% 100%
 2% 8 KB 80% 100%
 4% 16 KB 80% 100%
 4% 32 KB 80% 100%
 10% 64 KB 80% 100%
 Workstation Access Pattern**   
 100% 8 KB 80% 80%
 Database Access Pattern***   
 100 8 KB 67% 100%

* - Рекомендовано Intel.
** - Определено StorageReview.com
*** - Определено Intel&StorageReview.com

Модель рабочей станции наверняка вызовет весьма противоречивую реакцию у наших читателей. Давайте посмотрим, что даст нам 8Кбайт +80% случайных обращений:

Анализ модели Workstation
 Workstation Access Pattern - Analysis  
 % of total I/Os Transfer Size
 80% 8 KB
 16% 16 KB
 3.2% 24 KB
 0.64% 32 KB
 0.128% 40 KB
 0.0256% 48 KB
 0.00512% 56 KB
 0.00128% 64 KB или больше

В основном, модель обращений допускает господство случайных обращений в 8Кбайтовом кластере равно как и появляющиеся время от времени последовательные обращения, которым удается избежать попадания в файл подкачки (swapfile) и/или естественной фрагментации. Модель также предполагает, что в основном будут иметь место операции чтения, тогда как операции записи будут в большинстве своем приходиться на запись в файл подкачки (swapfile). Это именно та модель, к которой мы обращаемся каждый раз, говоря об оценке производительности рабочей станции при помощи IOMeter’а.
Модель обращения к базе данных называется именно так ("Database" Access Pattern), потому что модель установленная в IOMeter по умолчанию описывается как “модель типичной нагрузки при работе с базами данных” за исключением размера блоков данных (2Кбайта). Обращения к 8Кбайтовым блокам теоретически подразумевают очень большие задержки, однако, на практике, разница во времени, которое необходимо для передачи 8Кбайт по сравнению с 2Кбайтами (при скорости передачи равной 20Мбайт в секунду), просто ничтожна. Намного больше времени уходит на перемещение привода винчестера в нужное место на пластине и на считывание данных с пластины или запись на нее. Несмотря на то, что мы назвали эту модель именно так, многие сочтут, что она наиболее удачно представляет функционирование типичной рабочей станции именно благодаря тому, что в ней преобладают случайные обращения к данным.

Количество изолированных операций ввода/вывода – загрузки IOMeter’а


Некоторое количество изолированных операций ввода/вывода, работающих параллельно, безусловно оказывают влияние на совокупную загрузку тестируемого жесткого диска. В случае всего одного обращения мы получаем линейную нагрузку, которая при 100% случайности обращений дает нам возможность измерить среднее время случайного доступа при работе с моделью базы данных. Однако такой случай нельзя назвать репрезентативным для всех видов доступа к данным. Возьмем, например, 4 обращения, работающие параллельно. В этом случае мы получаем модель элементарных операций, таких, как например, запуск калькулятора в Windows. При помощи файла Win2k perfmon.exe мы смогли зафиксировать всплески в интервале от 30 до 50 операций ввода/вывода, работающих параллельно при запуске некоторых приложений. Всплески свыше 100 операций ввода/вывода имеют место в случае повышенной интенсивности обращений к жесткому диску, например, при его дефрагментации.
В результате, мы решили протестировать каждую из трех перечисленных выше моделей доступа с 5-ю вариантами нагрузки:

Варианты загрузки
 Loads 
 Linear 1 Outstanding I/O
 Very Light 4 Outstanding I/Os
 Light 16 Outstanding I/Os
 Moderate 64 Outstanding I/Os
 Heavy 256 Outstanding I/Os

Другие параметры


Если никаких соответствующих изменений параметров не проводилось, то IOMeter будет работать до тех пор, пока пользователь в ручную не прервет программу. Мы установили время выполнения каждого теста равное 10 минутам. А всего было проведено 15 тестов (3 модели, по 5 раз для каждой). Обратите внимание, что первые тридцать секунд каждого теста отводились на так называемый “разгон” и результаты на этом временном отрезке не учитывались. Таким образом мы попытались избежать существенного разброса значений и влияния начальных непоказательных результатов на общую картину.

В ходе тестирования мы обнаружили, что IOMeter оказывается крайне невосприимчив к влиянию внешних параметров системы. Кроме очевидной устойчивости к влиянию, оказываемому загрузкой процессора и сопряженных с этим параметров, IOMeter поразительно терпим к различиям между системами, что дает возможность сравнивать результаты, полученные для разных систем. StorageReview.com, конечно же, сохранит свою тестовую платформу неизменной. Однако, мы не будем осуждать тех пользователей, которые захотят сравнить свои результаты, полученные при помощи утилиты IOMeter, с нашими. Другое преимущество такого постоянства заключается в том, что при тестировании не возникает необходимости перезагружать систему, а для нас также нет необходимости и заново форматировать винчестер после каждого теста, поскольку мы тестируем строго в соответствии с рекомендациями, т.е. при использовании жесткого диска, не разбитого на разделы.
StorageReview.com использует бета-версию утилиты IOMeter, вышедшую 20 октября 1999. Она включает некоторые дополнительные опции. Поскольку, как мы уже сказали, не нужно перезагружать систему, мы скомпоновали все тестирование (15 раз) в один бенчмарк продолжительностью 2 часа 37 минут и 30 секунд. Результаты, которые мы получаем схожи с результатами, выдаваемыми новой (сегодняшней) версией теста.

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

Общее количество операций ввода/вывода в секунду. Это наиболее значимый результат. Он показывает сколько обращений было выполнено за 1 секунду. Разумеется, каждое обращение состоит из нескольких действий, выполненных последовательно: перемещение привода, вращение диска, считывание или запись 8Кбайтового блока для рабочей станции/базы данных или блока размером от 0.5 до 64Кбайт в случае модели сервера.

Общее количество переданных мегабайт в секунду. Это не что иное как экстраполяция предыдущего параметра. В случае для модели рабочей станции или базы данных значение этого параметра равно: [количество операций ввода/вывода в секунду] x 8KB / 1024. Для модели файлового сервера значение получается несколько сложнее из-за передаваемого размера переменной.

Среднее время реакции системы на каждую операцию ввода/вывода. На линейном уровне (1 отдельная операция) это значение просто иначе отображает количество операций ввода/вывода в секунду. Проще говоря, количество операций ввода/вывода в секунду это 1000миллисекунд делённые на среднее время реакции системы на каждую операцию ввода/вывода. С ростом количества отдельных операций, осуществляемых параллельно, вычисления усложняются. Среднее время реакции системы на каждую операцию ввода/вывода возрастает, но не линейно по отношению к росту количества операций ввода/вывода. Этим мы обязаны оптимизации firmware, поддерживаемого интерфейса/шины, а также оптимизации процедуры доступа к диску.

Загрузка процессора. В большинстве случаев мы не приводим это значение в наших базах данных. Это не что иное, как процент процессорных тактов, вовлеченных в обработку обращений. Это число очень небольшое для 700МГц процессора. Это число также небольшое для 266МГц процессора. В любом случае, намного важнее…

Количество операций ввода/вывода на определенный процент загрузки процессора. Это так называемая “эффективность процессора” по IOMeter’у. Значение получается в результате деления количества операций ввода/вывода в секунду на коэффициент загрузки процессора (что в большинстве случаев составляет мене 1%, что приводит к росту производительности). Сравнение результатов по этому параметру для нескольких дисков является более правильным, чем сравнение непосредственно коэффициентов загрузки процессоров.