Тестирование с помощью программы IOmeter

Когда я, еще в 2007 году писал небольшой обзор программы IOmeter, которой как раз незадолго до этого измерял показатели производительности некоторых моделей систем хранения NetApp, я не предполагал, что эта небольшая заметка станет с той поры “бестселлером” блога. Неожиданно для себя я обнаружил, что подробного описания работы с таким популярным средством тестирования и измерения на русском языке просто нет. Не так давно коллега track написал гораздо более подробное описание настройки и работы с IOmeter, и c его любезного согласия, я публикую этот текст у себя в блоге.

Программа IOmeter - это популярный тест для тестирования производительности дисковой подсистемы и локальной сети. Тест является “100% синтетикой”.
К сожалению, некоторая неочевидность процесса тестирования в нем, устаревший внешний вид, отсутствие полноценного онлайн-хелпа, и документации, а также русскоязычного описания, часто вызывают затруднения при попытках его использовать. Также в интернете практически отсутствует подробное описание методики работы с ним, и описание используемых терминов и фич.

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

При неоспоримых преимуществах таких “реальных” тестов им присущ и серьезный недостаток, например сложно или практически невозможно создать тест, выходящий за рамки некоторых типовых действий, например офисной работы.
Во-вторых, часто трудно проинтерпретировать результаты, так как методика измерения довольно темна и запутана внутри используемых в имитационном тестировании приложений.

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

Популярный тест IOmeter относится ко второй категории, “синтетических” тестов.

Эта программа изначально была разработана в компании Intel, и впоследствии, когда ее развитие в Intel остановилось, была передана в “опенсорс”, сообщество которого и продолжает ее постепенное развитие.
Несмотря на то, что у программы есть свой вебсайт, я рекомендую скачивать ее со странички проекта на Sourceforge.
Дело в том, что по ссылке Download с офсайта отдается последний Stable, который давно (2006.07.27) застыл, тогда как на Sourceforge последний - Devel 2008.06.22 rc2, котором сделано довольно много существенных изменений и улучшений, поэтому рекомендую пользоваться именно им.

Для этой версии на Sourceforge собраны следующие бинарники:
X86_64, IA64 (native Itanium), Win32 и Linux x86_64. Из сорцов можно (попробовать) собрать Dynamo под нужную платформу, так, после небольшой рихтовки и шаманства он собрался под нужный мне Solaris 10/SPARC.

Интересное начнется с самого начала. После установки вы обнаружите в папке программы два исполняемых файла: iometer.exe и Dynamo.exe. Дело в том, что IOmeter построен по “двухкомпонентной” схеме, позволяющей не только отделить тестируемую систему от управляющей, но и управлять сразу множеством тестируемых компьютеров. Iometer.exe это управляющая программа с GUI, а Dynamo.exe - командлайновая утилита под соответствующую платформу.

Такое разделение очень удобно, например, для меня, когда моя тестируемая система находится в датацентре в соседнем здании, где находиться, прямо скажем, не слишком комфортно (шумно, холодно, дует, да и тривиально даже сесть не на что). С помощью такой двухкомпонентной системы тестирования я могу запустить Load Generator (Dynamo.exe) на тестируемых серверах в датацентре, уйти в офис, и уже оттуда подключиться к ним по локальной сети и управлять всеми ими удаленно, получая результаты на свой ноут.

Однако, если у вас не стоит задача делать “распределенное” тестирование, то можно всем этим не заморачиваться, и просто запустить iometer.exe. При этом вы увидите экран GUI-менеджера, и следом запустится локально Dynamo.

И Dynamo, и IOmeter можно запустить с ключом /? При этом, ожидаемо, вы получите список некоторых полезных ключей запуска.

IOmeter:
Iometer config_file [result_file [timeout_value]]
Iometer [/c config_file][/r result_file][/t timeout_vaue][/p port][/m 1]

Config_file - файл конфига. Должен существовать и быть валидным icf.
Result_file - файл результатов (в формате CSV), дополняется, если не существует - создается.
Timeout_value - число секунд, которые ждем участников для логина.
Port_number - порт, который слушаем для логина.
/m - показать большой gauge при тестировании.

Если заданы и config_file и results_file, то Iometer пытается запуститься в пакетном режиме, без участия человека, запустить и остановить тесты, если запуск определен в Test Setup tab загруженного config_file, записать результаты в result_file, и по окончании работы закрыть iometer.

Возможность пакетного запуска очень удобна и полезна, так как тесты могут в совокупности занимать по многу часов.

Dynamo:
dynamo [/i iometer_computer_name /m manager_computer_name] [/n manager_name] [/c cpu_affinity] [/p login_port_number]

iometer_computer_name - это имя или IP-адрес компьютера с запущенным Iometer, к которому мы будем из Dynamo логиниться. Без этого параметра Dynamo будет искать его на localhost.
manager_name - это имя компьютера с Dynamo, в терминах IOmeter он называется “manager”. По умолчанию это имя хоста. Важно если вы используете его в конфиге IOmeter, например назначаете конкретно ему какую-то задачу в предварительно записанном конфиге.
manager_computer_name - это имя или IP компьютера с Dynamo, с помощью которого будет коммуницировать GUI с этим Dynamo. По умолчанию используется IP-адрес первой сетевой карты
login_port_number - это порт, на котором будет происходить login между Dynamo и GUI. По умолчанию - 1066. Не забудьте его открыть, в случае файрволлов.
cpu_affinity - это номер конкретного CPU, на котором будет исполняться Dynamo в случае многопроцессорной системы. Если не определен, то на первом же CPU.

Таким образом, строка для запуска может быть
track@unixbox> ./dynamo /i 192.168.1.100 /m 192.168.1.10 /n LG1

При этом мы запустим экземпляр Dynamo на машине с IP 192.168.1.10, которая появится в GUI, расположенном по адресу 192.168.1.100 и будет в нем называться LG1

Еще один ключ, не указанный в выводе /? это ключ /force_raw. Этот ключ говорит игнорировать обнаруженные на диске файловые системы, и тестировать его как raw-устройство. БУДЬТЕ ОСТОРОЖНЫ с его использованием, так как с ним сформатированный файловой системой диск будет испорчен при тестировании.

При запуске по сети, процесс логина от удаленных Dynamo занимает несколько секунд, в случае локального запуска все происходит моментально.

Одно из ключевых понятий в IOmeter это “worker”.
Worker это объект, выполняющий задачу тестирования. Именно ему назначается то или иное действие.
По умолчанию Dynamo (в терминах IOmeter - “manager”, что немного неожиданно, логичнее называть в этой паре менеджером именно GUI, IOmeter.exe) создает Worker-ов в количестве, равном обнаруженным на системе процессорным ядрам. Имейте ввиду, что в случае наличия Hyperthreading они будут распознаны как два ядра, что может быть не вполне хорошо для запуска на каждом из них интенсивного нагрузочного приложения.
Использовать можно любое количество воркеров из имеющихся, можно, конечно, назначить тест и только на одного.

Итак, запустили IOmeter.

Слева в колонку Topology у нас залогинятся наши Dynamo, на локальной или удаленных машинах.
На моем ноуте Asus 901Go на процессоре Atom N270 нашлось, как вы видите, два ядра и создалось два worker.

Первая закладка называется Disk Targets.
При первом запуске вы увидите в колонке Targets для выбранного слева manager и его worker все те диски, которые он у себя видит (в случае, если вы запускаете Dynamo на удаленной машине, это будут диски, которые он видит там, у себя, на удаленной машине). Желтым цветом будут окрашены диски, имеющие на себе распознанную файловую систему, голубым - raw-партиции, неотформатированные или имеющие нераспознанную данной OS файловую систему.

Сначала все диски будут перечеркнуты красной линией. Это означает, что на них не найден тестовый файл, необходимый для тестирования на файловой системе (в случае raw-partition это не нужно, и “голубые” диски сразу готовы к тестированию).
Выбрать диск для тестирования можно поставив в чекбоксе крестик.
Тестовый файл iobw.tst создается в корне соответствущего диска при первом запуске, и, ВНИМАНИЕ, по умолчанию занимает весь свободный объем диска! Это может быть и долго, и… э-э… неожиданно ;) для приложений или OS, если вы, например, экспериментируете на рабочем компьютере.
Для того, чтобы ограничить его размер, можно задать его размер в поле Maximum disk size, размер указывается в СЕКТОРАХ, размером 512 байт!
Например, 65535 секторов - 32MB.
Starting disk sector может задать стартовый сектор в случае raw-partition.
# of Outstanding IOs это важный параметр, стоящий подробного описания.

Каждая задача, каждая программа, исполняемая на компьютере обычно осуществляет ввод/вывод на диск. Как правило, они делают это не одним потоком, а одновременно записывают и считывают с диска несколько параллельных процессов.
Принято считать, что 4-8 потоков ввода/вывода порождают совсем простые приложения, типа notepad.exe и calc.exe. Крупные программы, уровня MS Word - 32-64 параллельны потока, максимумом можно считать 256, соответствующего крупной enterprise-базе данных типа Oracle, под хорошей нагрузкой.
Количество одновременных потоков ввода/вывода это и есть “# of Outstanding IOs”.
Для того, чтобы протестировать систему на нагрузке, приближенной к боевой, этот параметр нужно активно использовать.
Но сейчас, тут, на этом месте, мы этот параметр трогать не станем, мы зададим работу с ним отдельно позже.

Перейдем на вкладку Network Targets.

С помощью IOmeter можно также тестировать и производительность локальной сети, но я этим никогда не занимался, поэтому тут могу только сказать, что добавить Network Worker-а можно нажав на кнопку на тулбаре, выделив нужного “менеджера” слева.

Следующая вкладка, Access Specification - важная. Именно на ней создается и задается “тестовый паттерн”, тот профиль тестовой нагрузки который будет нагружать нашу систему.

Выбрав Worker слева, выбираем один из имеющихся у нас профилей нагрузки, и добавляем его кнопкой Add в левую панель. Таким образом мы назначаем тестировочную задачу имеющемуся worker-у. Если у нас планируется запустить параллельно (или последовательно) несколько worker-ов, также добавляем им паттерн нагрузки.
Если слева мы выберем не один конкретный worker, а элемент, включающий их в себя, то назначенный паттерн назначится всем worker-ам ниже по иерархии.
Добавить можно и не один паттерн на воркер.

Паттерны можно создавать самому, а можно воспользоваться уже заданным набором. Когда-то, когда IOmeter еще производился компанией Intel, с ним в комплекте шло несколько разработанных Intel тестировочных паттернов.
Вот тут: iometer2.icf можно скачать конфигурационный файл для IOmeter, с видимым на скриншоте набором тестировочных паттернов нагрузки, с большим или меньшим успехом имитирующих те или иные типовые нагрузки.
Также можно поправить, или даже нарисовать свой собственный. Нажмите New или выберите паттерн и нажмите Edit (или Edit Copy), и откроется окно задания параметров.

Рисуя паттерн мы задаем блоки, которыми будет обращаться тест к системе хранения (или сети, если мы тестируем сетевой интерфейс).
Размер блоков это левая верхняя панель: Transfer Request Size.
Относительное количество таких блоков: Percent of Access Specification. Если вы задаете сложный паттерн, то суммарное количество всех должно равняться 100%.
Крайняя левая - Percent Read/Write Distribution - определяет каково будет соотношение записей и чтений по данному паттерну. Так, например, для File Server задано 80% read и 20% write, а для вебсервера, с которого, обычно, только читают, задано 100% read.
Четвертый важный параметр Percent Random/Sequental Distribution- характер доступа, выбирается между Random и Sequental, случайным и последовательным доступом к тестовому файлу.
Остальные параметры используются редко.

Предпоследняя вкладка - Result Display.
На ней мы будем видеть то, как идет наше тестирование, его результаты по выбранным параметрам.

Два важных контрола на этой вкладке - переключатель Result Since и движок Update Frequency.
Первый определяет то, какие будут выводиться результаты на “градусники” ниже - суммарный с начала теста (Start of Test) или мгновенный, текущий (Last Update).
Регулятор определяет частоту смены показаний на экране.
Обратите внимание, что все это влияет только на отображение в программе, в файл результатов будет записано максимальное достигнутое за время тестов значение.

Для отображения по умолчанию выбрано 6 показателей. Их можно сменить, нажав на “кнопку” с параметром и выбрав в меню нужный для отображения параметр. Это также влияет только на отображение в программе, в результирующий файл будут записаны они все.

И, наконец, перейдем к настройке процесса тестирования, закладке Test Setup

Для выбранного worker, напоминаю снова, что все действия производятся и назначаются на конкретный объект worker, запишем Test Description, чтобы потом разобраться что за результаты у нас в общем CSV-файле результатов.
Зададим время выполнения теста: Run Time
И установим “время разгона”, предварительного периода для “прогрева”: Ramp Up Time.

Этим можно было бы и ограничиться, если мы хотели провести один тест. Но, как правило, интересно сделать сразу несколькоd в прием, а не тыкать в кнопочки, дожидаясь окончания каждого. Для этого IOmeter оснащен богатыми возможностями.
В выпадающем списке Cycling Options можно задать условия последовательного выполнения тестов соответствии с определенными условиями и изменениями параметров.

Например, как я уже говорил выше, я предлагаю не устанавливать параметр # of Outstanding IOs, а запустить тесты последовательно, с постепенным увеличением его, с тем, чтобы увидеть в результате, динамику реакции системы хранения на нагрузку ввода/вывода.

Впрочем вариантов выполнения Cycling Options 8 штук, попробуйте разобраться по образцу.

Выбрав указанный на скриншоте вариант, можно установить поля от скольки (1) и до скольки (256) увеличивать количество потоков. В качестве характера прироста рекомендую Exponential Sepping и Power: 2. При этом прирост будет удвоением: 1 - 2 - 4 - 8 - 16…Такой шаг прироста достаточен для оценки нагрузочной способности подсистемы ввода/вывода.

Итак, мы добрались до момента старта.
Нажимаем на тулбаре кнопку с зеленым флажком.
Нам предлагается сохранить результаты в файл CSV (Comma Separated Value) с именем по умолчанию results.CSV. Если этот файл уже существует, то он будет ДОПИСАН, в начале новых данных будет указано имя теста, заданное нами в Test Setup.
В дальнейшем можно будет этот CSV импортировать в Excel и настроить по его данным красивых графиков.

В первый запуск долгое время ничего видимого не происходит так как для первого запуска создается тестовый файл. Об этом говорит сообщение внизу: Preparing Drives. Когда файл создан, то в Disk Targets исчезает красная зачеркивающая линия. В дальнейших запусках файл не пересоздается, и тест запускается сразу.

В левом нижнем углу отображается название идущего теста.
В правом, сообщение Ramp remaining говорит, что идет процесс “прогрева” перед тестом, а Run 1 of 6, что запущен первый из 6 назначенных в Cycling options тестов.

Для того, чтобы остановить текущий тест (и перейти к следующему) можно нажать кнопку Stop на тулбаре, а чтобы прервать всю последовательность тестов - Stop All.

Теперь перейдем на закладку Test Results.

“Градусники” показывают текущее значение тестов, а цифра посередине него - текущее значение выбранного параметра.
Run remainings: оставшееся время текущего теста.
Суммарное время будет составлять (при ранее указанных параметрах): (30 секунд ramp + 10 минут теста) * 6 тестов.

Во время теста ход его отображается в окне утилиты Dynamo.

По окончании тестов, в файле CSV с именем, который вы выбрали (по умолчанию results.CSV) собираются результаты, которые можно импортировать в Excel и настроить в нем необходимой аналитики.

4 комментария

  1. Возможно ли с помощью IOmeter имитировать высокую фрагментацию, может быть есть готовые профили?
    Не силен в английском чтобы поискать методики в англоязычном интерте.

  2. > Возможно ли с помощью IOmeter имитировать высокую фрагментацию

    Вопрос с фрагментацией на самом деле непростой. На этот счет существют два разных мнения, и я пока не присоединился ни к одному из них.
    Например Alex McDonald (http://blog.aboutnetapp.ru/archives/455) разумно утверждает, что величина фрагментированности не играет существенной роли в случае random-доступа.
    Независимо от того, лежит ли ваш файл цельно и последовательно, или разбросан по диску, если считывание с него будет производиться случайным образом (а именно random access нас в первую очередь должен интересовать, задачи последовательного чтения-записи это довольно узкочастные на сегодня области применения, типа считывания-записи логов БД или видео-аудио запись), то random-доступ “помноженный” на random-размещение файла (фрагментация) не дает “рандом в квадрате”, он остается все тем же случайным доступом.
    Теоретически, результат random access к фрагментированному файлу не должен сильно отличаться от такого же random access к нефрагментированному.

  3. То есть если мы будем проводить тест на random-доступ на одном и том же носителе результат все время будет одним и тем же?, но по мере увеличения фрагментации в результате неоднократного копирования перемещения и удаления файлов, работы приложений, на данном носителе реальная производительность с реально размещенными на носителе данными понизится т.е время доступа увеличится.
    А тест на случайный доступ будет по прежнему показывать то же значение?
    Если я хочу сравнить между собой поведение нескольких разных носителей в условиях увеличения фрагментации, просто по показателям времени случайного доступа смогу ли я прогнозировать поведение их при реальной фрагментации?
    И задача измерить скорость доступа к конкретным данным при реальной фрагментации неосуществима?

  4. > То есть если мы будем проводить тест на random-доступ на одном и том же носителе результат все время будет одним и тем же?, но по мере увеличения фрагментации в результате неоднократного копирования перемещения и удаления файлов, работы приложений, на данном носителе реальная производительность с реально размещенными на носителе данными понизится т.е время доступа увеличится.

    Нет.
    Принято считать, что для современных многозадачных OS и распространненых приложений, таких как OLTP-базы, характер дисковой нагрузки сегодня является преимущественно рандомным.
    “Есть мнение”, что в случае рандомного доступа несущественно то, насколько последовательно расположены на диске данные, если читают и пишут их все равно в случайном порядке. “Случайное расположение помноженное на случайный порядок чтения-записи не дает “случайное в квадрате”, оно по прежнему остается просто случайным”
    Отсутствие фрагментации улучшает характеристики доступа в основном для данных, которые читаются и пишутся последовательно, а это относительно малораспространенный набор задач.
    Более того, и об этом я уже тоже писал, в ряде случаев, на современных OS и современных производительных системах хранения с большим и “умным” кэшем, фрагментация даже в условиях последовательного доступа мало влияет на характеристики производительности.

    Так это или нет - существуют разные мнения. Задача, поверьте, совсем не так проста, как кажется.
    Но это все, увы, пока только чужие мнения. Лично своего, основанного на каких-то моих собствнных экспериментах я пока не сложил.
    Главная сложность - в методологии тестирования. Я пока такую, чтобы она устраивала и меня и точность, не разработал.

Оставить комментарий

20/0.147

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.