Iometer как пользоваться под windows

Обновлено: 04.07.2024

Перевод и публикация этой статьи выполнены с любезного разрешения 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) операции записи могут стать преобладающими.

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

% 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%

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Мбайт в секунду), просто ничтожна. Намного больше времени уходит на перемещение привода винчестера в нужное место на пластине и на считывание данных с пластины или запись на нее. Несмотря на то, что мы назвали эту модель именно так, многие сочтут, что она наиболее удачно представляет функционирование типичной рабочей станции именно благодаря тому, что в ней преобладают случайные обращения к данным.

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Запись опубликована about NetApp.Пожалуйста, оставляйте коментарии там.

К сожалению каких-либо материалов начального уровня, позволяющих сразу разобраться в работе IOmeter, в сети не найдено, поэтому пришлось сделать это самому, а на будущее написать шпаргалку. В значительной мере эта шпаргалка является описанием конкретно моего случая тестирования, поэтому она опускает некоторые возможности, которыми я не пользовался.
Думаю освоив то, что описано здесь, можно разобраться и с остальным.

Описания методики тестирования системы хранения с помощью программы IOmeter (версия 2006.07.27)

Программа состоит из GUI-фронтенда iometer.exe (есть только под windows) и генератора нагрузки dynamo.exe (бывает под windows, linux, solaris, netware), управляемого из GUI по сети.

Запускаем на сервере, к которому подключен тестируемый раздел на системе хранения, программу dynamo из комплекта поставки iometer, она будет осуществлять нагрузку для тестирования.
dynamo бывает под windows, linux, может быть собрана под solaris.

Ключи запуска выводятся по /?

Указывается компьютер (имя или ip), на котором установлен GUI frontend IOmeter. (/i )

Указывается номер порта для связи dynamo и GUI, если не указан, то будет взят по умолчанию 1066. Должен быть свободно пропущен через межсетевые экраны и файрволлы для обеспечения взаимодействия dynamo и IOmeter GUI.

Если небходимо, можно назначить исполнение на конкретном CPU (см. подсказку по /?).

Пример:

dynamo /i testadmin /m 192.168.0.10 /n generator001

testadmin - имя (или ip-адрес) компьютера где будет работать iometer
192.168.0.1 - адрес (можно dns-имя) сервера нагрузки (где исполняется dynamo)
generator001 - произвольное имя генератора нагрузки, показываемое в iometer GUI.

Если dynamo уже запущен, то при старте Iometer тот найдет присутствующие в сети Managers, покажет их и разрешит использование. При отсутствии удаленных dynamo будет запущен локальный dynamo, для тестирования локальных ресурсов.

Каждый процессор менеджера тестирования с запущенным dynamo представлен отдельным worker. На каждый worker можно назначить свой тест.
Worker это процесс, который будет исполнять тест. По умолчанию количество workers равно количеству процессоров (ядер, HyperThreading pseudo-CPUs). Но можно создать дополнительные workers кнопкой на тулбаре.
Дополнительно могут быть добавлены workers для тестирования интерфейсов локальной сети (см. тулбар).
Сброс workers и реконнект к менеджерам там же, на тулбаре.

В Iometer открываем конфигурационный файл, отключаем в параметрах открытия Managers and Workers, чтобы не искало чужих managers, настроенных в конфигурационном файле. В дальнейшем, если записать конфигурационный файл на своей тестировочной инфраструктуре, можно открывать и с настройками workers.

Выбираем нужного нам manager и его worker
В закладке Disk Targets выбираем объект, например смонтированный LUN системы хранения.
Желтым цветом показаны логические дисковые разделы с файловой системой, ДОСТУПНЫЕ НА ЗАПИСЬ.
Голубым - физические разделы без партиции на них.
Перечеркнутый значок означает, что на диске не найден тестовый файл.
Отмечаем нужный крестиком слева. На данном LUNе (в случае использования файловой системы) будет при первом запуске создан тестовый файл iobw.tst. Операции при тестировании будут проводиться с ним.
ВНИМАНИЕ: по умолчанию этот файл будет занимать все свободное место на диске!
Это может занять продолжительное время при первом запуске. Ожидайте. По завершении создания файла начнется тест. При необходимости тестовый файл может быть обычным образом скопирован на другие разделы, чтобы не создавать его там заново.

Starting disk Sector, Outstanding IOs и Test Connection rate оставляем в состоянии по умолчанию.

В закладке Access Specifications в правой панели перечислены импортированные из конфигурационного файла преконфигурированные паттерны.
Выбираем worker у менеджера и добавляем для него из правой в левую панель необходимый паттерн.
Патернов одновременно может быть назначено несколько.
Каждый worker может иметь свои паттерны.
В конкретном случае добавляем только один только одному worker-у.

В группе Display назначены по умолчанию 6 индикаторов (от Total I/O per second до Interrupts per second). Индикаторы могут быть изменены нажатием на кнопку их имени. Оставим по умолчанию.

По завершению тестирования одного паттерна перейти в Access Specifications и поменять паттерн. Изменить описание теста в Test Setup и запустить новый цикл.

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

Нам нужно протестировать систему, которая в дальнейшем будет использоваться как сервер 1C или сервер базы данных.

Для этой цели лучше всего использовать программу Iometer. Она хоть и давно не обновляется, но цели свои выполняет хорошо.

Настроек у этой программы много, поэтому мы разберем только те, которые нужны нам.

Этот параметр важен для некоторых RAID контроллеров. Чтобы получить максимально корректные данные, лучше всегда использовать режим Full random.

Настройки теста можно задавать несколькими способами:

Индивидуально для каждого worker. Для этого нужно становиться на каждого worker в секции 1 и задавать нужные параметры. Удобно когда хочется задать разные параметры для разных worker.
Одинаковые для всех worker. Для этого нужно стать на manager в 1 секции (HarleyLaptop на скриншоте) и задать нужные параметры. При этом важно учитывать что тестируемые диски в секции 2 нужно все равно задавать индивидуально для каждого worker.
Третий способ тоже для все worker, но более удобный чем второй. Нужно удалить все worker кроме одного, задать настройки для одного worker и потом скопировать его чтобы worker было столько же сколько и физических ядер.

На странице Access specifications выбираем Database pattern. По умолчанию его в программе нет. Загрузить можно из файла настроек.

На странице настроек теста указываем только Run time - продолжительность теста. Чем больше значение тем точнее будет результат.

Запускается тест нажатием на кнопку с зеленым флажком.

На странице результатов есть две настройки отображения

Results since. Способ подсчета результатов.
- Start of test. Выводит усредненные результаты с начала теста.
- Last Update. Выводит результаты последней операции.
Update frequency. Частота с которой будут обновляться результаты.

В секции Results Display выводятся результаты теста.

В каждом показателе можно щелкнуть на кнопку с названием результата и выбрать произвольный параметр. В нашем тесте мы используем такие показатели

Total I/O per second. Количество IOPS в секунду. Ключевой показатель при работе с базами данных, поскольку базы генерируют большое количество операций над небольшими порциями данных. В среднем одному пользователю базы данных требуется 500-700 IOPS.
Total MBs per Second (Decimal). Количество мегабайт в секунду. Не самый информативный показатель. Может сбивать с толку тем, что на SSD указана намного большая сокрость. Однако обычно производители и тесты показывают скорость линейного чтения, которое не имеет никакого отношения к работе базы данных.
Average I/O Response Time (ms). Среднее время выполнения операции в милисекундах. Чем меньше этот показатель, тем лучше. В случае базы данных может быть довольно критично, поскольку задержка одной операции, которая выполняется в рамках транзакции, может задержать все остальные операции в других транзакциях. IOmeter не может воспроизвести такие ситуации, поэтому важно следить за этим параметром при выборе конфигурации дисковой подсистемы.
Maximum I/O Response Time (ms). Максимальное время выполнения операции в милисекундах.
% CPU utilization. Процент загрузки процессоров.
Total Error count. Количество ошибок произошедшее во время выполнения операций. Должно равняться 0.

В настройках есть разделение показателей на операции чтения и записи, однако в данном случае нет смысла их выводить, поскольку в Database pattern задано 67/33 соотношение операций чтения и записи, соответственно результаты будут получаться в таком же соотношении.

Идея этой статьи в том, что пока я не нашел адекватной инструкции по пользованию такой классической программой как IOmeter. Также, не нашел готовых профилей для нагрузки, в зависимости от типа задач, это тоже отдельный вопрос. Постараюсь рассказать максимально просто про IOPS, с картинками и с неким углублением в VDI (виртуализицию рабочих столов) на ОС Windows 10.
Сама инструкция будет во второй статье, сначала начнем с теории, будет много текста.

Windows, изначально, был спроектирован для использования локальных дисков и требует постоянный доступ к дисковой подсистеме, даже в момент простоя. В дополнение к этому, Windows будет использовать столько операций ввода-вывода или пропускной способности диска, насколько это возможно. Это означает, что ВМ (виртуальная машина) при использовании общего хранилища, пытается перетянуть одеяло доступных IOPS на себя. В результате, когда вы виртуализируете много рабочих станций, и у вас общее хранилище данных (SAN или NAS), все они конкурируют за использование максимально возможного дискового ввода-вывода, чтобы максимизировать свою производительность (без знания потребностей других ВМ которые используют тот же аппаратный ресурс). Если ОС не будет получать достаточно требуемого кол-ва операций ввода-вывода, производительность рабочего стола снизится, и пользователи увидят его в виде длительного времени загрузки / входа в систему, медленного запуска приложений и в целом, низкой производительности рабочего стола.

Значения в поле Value следует читать до запятой, т.е. ниже, на скриншот, это 475 IOPS.

На картинке ниже, у нас все плохо, очередь скопилась, что вызвало увеличение времени отклика (response time, оно же latency).

Глянем поближе

Нас интересуют вот эти показатели (можно обновлять результаты по нажатию кнопки 2):

Как же, в итоге, тестировать нашу инфраструктуру? Продолжим это во второй статье.

Читайте также: