Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
Измерялся FCoE и iSCSI по 10G Ethernet.
Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.
На днях EMC выкатило на тесты SPECmark (тесты производительности NAS enterprise-уровня), впервые с 2007 года, свой “суперболид” на базе симметрикса и “всех порвала!!!11″.
Впрочем, как выяснилось довольно скоро, не то чтобы совсем порвала, а так, понадрывала по краю ;)
По этому поводу блоггеры NetApp вовсю ехидничают.
Судите сами:
EMC Symmetrix V-MAX, 4x V-engines, 264GB cache total
96 штук 400GB EFD flash drives (это EMC-шные SSD) в двух RAID-1
3 штуки (2 active + 1 passive) Celerra NS-G8 Datamovers в качестве NAS Gateway, 8GB cache в каждой.
24-портовый коммутатор FC, чтобы всю эту кухню пересоединять между собой Наддув, впрыскивание закиси азота, ксеноновые фары и брызговики Sparco.
И все это счастье сисадмина, стоимостью не менее чем 6 миллионов долларов в ценах американского лиспрайса набирает аж 110621 спекмарковских попугаев по SPECsfs2008 в NFS (и 118463 в CIFS, которые никто почти и не меряет из участников).
Круто типа.
Но при этом еще в прошлом году NetApp публиковал результаты FAS6080, с ценой проекта едва ли вполовину EMC-шной, на обычных дисках (не SSD), и даже без Performance Accelerator, показавшей 120011 спекмарковских попугаев.
А результат в районе 60 тысяч, то есть вполовину EMC-шного “устройства для завоевания превосходства в датацентре” показывает довольно таки средненькая midrange FAS3160, причем при использовании PAM делает она это на всего лишь 96 дисках SATA (!)
Я уж не говорю, что по абсолютной величине их обгоняет, например система производства Huawei Symantec ;)
В блогах MSDN найден любопытный документ тестирования iSCSI на 10G Ethernet, с использованием MS Windows Server 2008, Hyper-V, и системы хранения NetApp FAS3070.
Даже несмотря на то, что использовался довольно старенький сторадж (3070 это топовая модель предыдущей midrange-линейки, в настоящий момент уже не выпускаемая, вся серия 3000 уже целиком заменена на 3100), и чисто “софтверный” iSCSI, результаты могут показаться любопытными тем, кто еще раздумывает “А насколько быстр на самом деле этот непонятный iSCSI?”
Следует отметить, что карты 10G Ethernet, например рассматриваемая в этом тестировании двупортовая Intel 10 Gigabit AF DA dual port Server Adapter по ценам Price.ru стоит ~770$, а вообще 10G адаптеры начинаются уже от 500$.
В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.
Нашлась вот такая картинка, с графиками тестирования различных типов дисков.
Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"
Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"
Однако вполне возможна и реальна ситуация, когда использование дедупликации значительно повышает общую производительность системы хранения!
Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин. Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах). Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90% места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).
Такой результат означает, что практически все содержимое наших системных разделов виртуальных машин поместится в кэш системы хранения (16GB), что в разы поднимет ее результирующее быстродействие после проведения дедупликации.
Даже если такой результат и не будет достигнут в конкретно вашем случае, все равно, уменьшение объемов хранения приводит к тому, что бОльшие объемы хранимых данных будут попадать в кэш, что чаще всего положительно сказывается на общей производительности.
Вопрос: Почему вы считаете, что кэш в данном случае не сможет точно также эффективно закэшировать одинаковые блоки, даже если они лежат в разных местах?
Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они их видит только “по номеру”. В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один. Ситуацию пояснят рисунки:
Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"
Сайзинг под базы Oracle есть критически важный параметр для создания системы хранения достаточной производительности. Сбор данных perfstat* и Oracle STATSPACK позволит выбрать правильно сконфигурированную систему хранения NetApp, как в плане размера, так и производительности.
Важно помнить несколько вещей, когда вы собираете статистику системы:
Собирайте данные, когда система под большой нагрузкой
Собирайте данные со всех хостов инфраструктуры
Собирайте данные в perfstat и STATSPACK за один период времени
Установка Oracle STATSPACK.
STATSPACK это утилита диагностики произвдительности СУБД, которая доступна начиная с Oracle8i. STATSPACK это дальнейшее развитие утилит BSTAT и ESTAT. Рекомендуется установить timed_statistics в true. Для установки STATSPACK выполните следующие шаги:
1. Создайте PERFSTAT Tablespace:
SQL> CREATE TABLESPACE statspack
DATAFILE ‘/path_to_file.dbf’ SIZE 200M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K
SEGMENT SPACE MANAGEMENT AUTO
PERMANENT
ONLINE;
2. Запустите catdbsyn.sql и dbmspool.sql как SYS из SQLPLUS
$ sqlplus "/ as sysdba"
SQL> @?/rdbms/admin/catdbsyn.sql
SQL> @?/rdbms/admin/dbmspool.sql
3. Запустите скрипт
$ sqlplus "/ as sysdba"
SQL> @?/rdbms/admin/spcreate
Можете начинать пользоваться Oracle STATSPACK.
Сбор Oracle Statspack с помощью Perfstat с хоста Unix.
Как я могу собирать данные Oracle Statspack и Perfstat одновременно?
Для Perfstat версии 6.28 или позднее мы можем собирать данные Oracle Statspack из Perfstat используя единую команду Perfstat. Это работает для версии perfstat под unix, и не работает для версии perfstat под Windows.
Небольшая выжимка их манов к Perfstat:
Требования:
1. Perfstat может собирать данные Oracle STATSPACK только с одного хоста.
2. Инстанс Oracle должен быть запущен до того, как будет вызван Perfstat.
3. Используйте флаг -o чтобы передать специфические опции statspack в perfstat.
-oracle_host - умолчание для localhost, может быть одним из хостов, определенных с помощью -h из команд perfstat
-sqlplus - может быть использован для того, чтобы определить абсолтный путь к команде ’sqlplus’
-runas - может использоваться для запуска sqlplus от имени другого пользователя (то есть пользователь Unix, где установлен Oracle, обычно не root.)
-sysdba - может использоваться для подключения к oracle как sysdba, игнорируя параметр oracle_login. Ключ sysdba вводит следующие команды в логин к sqlplus:
a. sqlplus /nolog
b. connect / as sysdba.
Примеры:
perfstat.sh -a oracle
perfstat.sh -h host1 -a oracle -o oracle_host=host1
perfstat.sh -h host1 -a oracle -o oracle_host=host1,sqlplus=/oracle/bin/sqlplus/
perfstat.sh -a oracle -o oracle_login=user/pass
perfstat.sh -a oracle -o runas=oracle,sysdba=true
Note: Для того, чтобы собирать статистику самого файлера вместе с данными статистики Oracle, должен быть использован ключ -f.
Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:
Несомненно одна из “горячих тем” 2008-09 года это SSD - Solid State Disks - “твердотельные” диски на технологии Flash. Они появились повсеместно, от недорогих нетбуков “до 300$” до дорогих серверных систем. В прошлом году использование SSD в системах хранения данных было анонсировано EMC для их линейки Symmetrix.
Часто приходится отвечать на вопросы: “А что же NetApp не реагирует, и не поддержит свое реноме передовой инновационной инженерной компании? Где же у NetApp SSD?”
А NetApp, как всегда, движется своим путем.
Что есть SSD? SSD это flash, знакомый нам уже много лет, но организованный таким образом, чтобы “обманывать” прочие устройства, чтобы те думали, что они работают с обычным HDD.
Этакий аппаратный “эмулятор HDD”. Кроме этого чем SSD отличается от знакомых нам, уже сто лет как, USB-”брелков”? Да по сути ничем. Ну да, SATA это в принципе более производительная шина, чем USB2.0. Да, в современных контроллерах Flash используется чередование и wear-leveling, но все то же самое используется и в современных высокоскоростных USB-”флешках”.
То есть в чем инновационность SSD? Только в том, что мы можем ставить его в те, ранее выпущенные устройства, которые знают и умеют работать только с жесткими дисками.
Некая аналогия с . Мы можем поставить их там, где софт умеет работать только с ленточными библиотеками, как, например, какние-нибудь запрограммированные на Коболе мэйнфреймы 70-80-х годов. И при этом нам не надо ничего менять на стороне остальной системы.
Но в том случае, когда нас не заботит “обратная совместимость” с прежним оборудованием, если мы можем создать IT-систему с нуля, тогда нам, скорее всего, незачем эмулировать поведение ленточных библиотек, мы можем поддерживать диски нативно.
По моему наблюдению, именно это причина плохих продаж VTL в России, по сравнению со всем миром, где VTL совершенно явные фавориты, выпускаемые многими вендорами дисковых систем.
В России просто незначительна проблема “унаследованного оборудования” и “унаследованных решений” (legacy solutions), и проблема совместимости для “начисто” создаваемой IT-инфраструктуры минимальна.
Конечно конкретно NetApp VTL это не только эмуляция, но также множество других, зачастую уникальных фич, таких как Direct Tape Creation и дедупликация, но в основном все так.
Таким образом, EMC решило эту задачу минимально затратным и наименее “умным” способом, просто сэмулировав на высокоскоростных Flash-устройствах обычные диски, подобно тому, как VTL эмулирует “ленточные библиотеки” на дисковых массивах.
Если здоровый человек хорошо размахнется и ударит отбойным молотком, то, конечно, сможет использовать его в качестве обычной кувалды, но нативное его применение может быть гораздо эффективнее.
Возможен ли другой путь? Очевидно, что да.
Эмуляция дисков не единственный способ использования flash-памяти.
Вот, что у себя в блоге уже знакомый вам инженер-разработчик NetApp Костадис Руссос:
“Существует три возможных варианта ситуации с доступом к датасету:
1. Низкий уровень IOPS, малая нагрузка
2. Высокая нагрузка по IOPS, когда датасет помещается в кэш
3. Высокая нагрузка по IOPS, когда датасет НЕ помещается в кэш
Очевидно, что из этих трех сценариев только третий - кандидат на использование Flash-дисков.”
Однако NetApp выбрал иной путь, создав , модуль расширения кэша. Своеобразный “SSD”, но не в виде эмуляции дисков, как принято сейчас делать, а на уровне архитектуры системы в целом.
:
Практика показывает, что большинство данных это так называемые “холодные данные” (то есть данные, уровень обращений к которым невысок). Таким образом платить за высокую производительность для “холодных данных” есть очень дорогостоящее решение. Но если система хранения обеспечивает высокую производительность работы для “горячих” данных, даже если они при этом лежат на медленном хранилище, то цена Flash, как среды хранения данных, в таком случае значительно уменьшается.
Другими словами, да, жесткие диски 15KRPM не обеспечивают исключительно высокой производительности, но они обеспечивают достаточный уровень, для достаточного объема данных, оставляя для SSD Flash нишу.
Я довольно давно собираюсь развернуто написать про PAM и его устройство, те, кто был в этом году на NetApp Innovation 2009 наверняка слышал рассказ специалиста московского отделения компании, Романа Ройфмана, о Performance Acceleration Module.
Надеюсь в скором времени и я напишу подробный рассказ про PAM для читателей этого блога.
Команда консоли sysstat похожа на vmstat и iostat свернутые в одну команду. Она сообщает данные производительности систем хранения, такие как CPU utilization, размеры дискового трафика, объемы ввода-вывода, как сетевого, так и по FC, а также трафик передачи данных на ленту, если она используется. При запуске без опций, sysstat печатает новую строку каждые 15 секунд, с базовым набором информации. Вы можете прервать вывод нажав control-C (^c) или установить при запуске определенный интервал работы (-c count ) для автоматической остановки через заданное время.
Список ключей команды:
-f статистика FCP -i статистика iSCSI -b расширенная статистика SAN (’blocks’) -u расширенная статистика загрузки системы (’utilization’) -x расширенный (’extended’) формат вывода. Включает в себя все доступные поля вывода.
Обратите внимание, что вывод производится в формате шире чем 80 символов, и предназначен скорее для “off-line” анализа, чем для непосредственного чтения с экрана.
-m отображает статистику по загрузке CPU на многопроцессорных системах. Применимо только на многопроцессорных системах, не работает на однопроцессорных.
Описания некоторых колонок вывода команды sysstat.
Cache age : возраст в минутах старейшего read-only блока в кэше. Значение в этой колонке показывает, насколько быстро операции чтения проходят через память системы; когда система читает очень большие файлы, значение buffer cache age будет низким. Кроме этого, если чтение преимущественно случайное, то cache age также будет низок. Если вы столкнулись с проблемой низкой производительности на чтении, то значение этого поля сможет помочь определить что вам нужно больше кэша, или нужно проанализировать работу приложения, чтобы снизить уровень “случайности” его запросов.
Cache hit : Величина в процентах для WAFL cache hit rate. Показывает, в скольки процентах читаемых с WAFL блоков они оказывались при этом уже в кэше. Прочерк в этой колонке, означает, что в измеряемый период данные не читались.
CP Ty : Тип (’type’) Consistency Point (CP). Показывает, что было причиной создания CP в рассматриваемом интервале. Тип CP может быть:
- не было CP в заданный интервал (не было записей на диск в указанный период времени)
(число) число CP, созданных в заданном интервале
B : Back to back CPs (CP generated CP) (система настолько загружена, что она начинает писать новую CP сразу за окончанием записи предыдущей)
b : задержанные back to back CPs (CP generated CP) (условия, вызвавшие состояние back to back стали хуже)
F : CP вызван заполнением NVLog (половина nvram log была заполнена, и он был сброшен на диск)
H : CP вызван high water mark (редко встречается. Система полностью заполнила одну половину nvram logs, и решила сбросить данные на диск).
L : CP вызван low water mark
S : CP вызван операцией создания snapshot
T : CP вызван таймером (каждые 10 секунд система хранения сбрасывает данные кэша на диск (flush))
U : CP вызван сбросом данных на диск (flush)
: продолжение CP с предыдущего интервала (означает, что CP все еще создается, например во время 1-секундного интервала)
Символ, следующий далее, показывает проходящую фазу создания CP на момент окончания интервала замера. Если CP завершился полностью во время интервала измерения, то второй символ будет пустой. Фазы могут быть следующие:
0 Инициализация n обработка обычных файлов s обработка специальных файлов f сброс измененных данных на диск v сброс измененного суперблока на диск
Большинство перечисленных выше значений можно увидеть только в случае предельно малых интервалов замеров, или на сильно загруженных системах, так как сброс CP происходит очень быстро. Обычно в поле CP ty вы будете видеть ‘T’, штатный сброс Consistency Point по таймеру.
Давайте разберем пример.
sysstat.txt (для более удобного вида отключите в нотепаде word wrap и расширьте окно)
Что мы можем сказать о данной системе?
Это малозагруженная, практичеси находящаяся в покое система (параметры CPU, Disk Usage и Total), использующая CIFS и FCP (небольшие ненулевые значения показывают фоновые операции по этим протоколам). Большиство операций в этой покоящейся системе совершается в виде чтения содержимого кэша (значение Cache hit). Кэш практически пуст, на что указывает монотонное возрастание значения Cache age, данные лежат, и ничто их не вытесняет. Consistency Points создаются исключительно сбросом по таймеру, что нормальное поведение для незагруженной системы.
Довольно высокие значения Disk read write при малой загрузке CPU, практически нулевом сетевом траффике и операциях ввода-вывода по блочным протоколам указывает на работу процесса Disk Scrubbing, фонового процесса контроля целостности данных и дисков, при котором система перечитывает и перезаписывает данные на дисках, возможно также что работает дедупликация, хотя она обычно дает повыше чем 1-3% загрузку, также, возможно, это признак работы дефрагментации WAFL (wafl reallocate).
Так выглядит типичный вывод sysstat малонагруженной типовой системы NetApp FAS.
А вот так выглядит система под рабочей нагрузкой: sysstat3.txt
Как видите, уже заметно нагружен процессор (это FAS6070, поэтому запас еще весьма существеннен ;), около 20%. Так как система используется как SAN, то весь трафик идет по колонке FCP. Несмотря на заметную нагрузку, ниже приведенный отчет по utilization показывает производительность около 15000 IOPS, и около 23 MB/s чтения с дисков ( и 70-90MB/s по интерфейсам FC), это не перегрузило систему. Большой объем кэша на чтение позволяет 90% операций читаться из кэша, а не с дисков.
Возраст самого старого блока в кэше составляет примерно 10-12 минут, то есть кэш еще далек от заполнения.
Здесь уже периодически проскакивают символы, показывающие фазу сброса CP, и само время записи CP увеличилось, так как вырос объем записи, хотя он и составляет всего около 1/10 от объемов чтения.
Таким образом, используя даже штатные средства контроля и анализа системы, имеющиеся в административной консоли, можно увидеть много интересного.
Оригинал тут:
А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.
Любопытный отчет о тестировании систем NetApp с помощью iometer.
Подробно рассмотрены некоторые важные аспекты процесса, в том числе приведен паттерн, на которых проводилось тестирование (симулировалась загрузка типа производимой Exchange 2003).
В целом все довольно схоже с моими результатами, которые я делал в прошлом году, да и выбранная методика в целом похожа.
Тестировались FAS3070 и FAS2050.
Обратите внимание, что автор специально готовил фрагментированные разделы, чтобы приблизить результаты к реальным условиям эксплуатации.
Измерены и приведены результаты для различных показателей фрагментации.
Одним из наиболее популярных т.н. “синтетических” тестов является программа IOmeter. Изначально эту программу разработали в Intel, но когда процесс разработки остановился, то были открыты исходные коды и в настоящий момент тест поддерживается энтузиастами OpenSource. Изредка программа обновляется. В настоящий момент основные вебсайты программы это www.iometer.org и страница разработки на SourceForge.
К сожалению каких-либо материалов начального уровня, позволяющих сразу разобраться в работе 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 (/n ), будет показано в GUI.
Указывается имя (ip-адрес) компьютера “менеджера” для коммуникации с ним по сети. (/m )
Указывается номер порта для связи 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. Операции при тестировании будут проводиться с ним. ВНИМАНИЕ: по умолчанию этот файл будет занимать все свободное место на диске!
Это может занять продолжительное время при первом запуске. Ожидайте. По завершении создания файла начнется тест. При необходимости тестовый файл может быть обычным образом скопирован на другие разделы, чтобы не создавать его там заново.
Для того, чтобы ограничить размер тестирования введите размер файла в 512b-блоках в поле Maximum Disk Size. Например: “16777216″ sectors (8GiB).
Starting disk Sector, Outstanding IOs и Test Connection rate оставляем в состоянии по умолчанию.
В закладке Access Specifications в правой панели перечислены импортированные из конфигурационного файла преконфигурированные паттерны.
Выбираем worker у менеджера и добавляем для него из правой в левую панель необходимый паттерн.
Патернов одновременно может быть назначено несколько.
Каждый worker может иметь свои паттерны.
В конкретном случае добавляем только один только одному worker-у.
На закладке Results Display будем наблюдать ход теста.
Варианты вывода: Start of test - накопительный, или Last Update - последний замер. Период замера показывает движок Update Frequency (от 1 секунды до “бесконечности”). В случае “бесконечности” результаты отображаться не будут. ВНИМАНИЕ: это влияет только на отображение результатов, само тестирование непрерывно и в записанном результате будет показано наивысшее значение.
В группе Display назначены по умолчанию 6 индикаторов (от Total I/O per second до Interrupts per second). Индикаторы могут быть изменены нажатием на кнопку их имени. Оставим по умолчанию.
В закладке Test Setup указываем имя теста в поле Test Description (это будет занесено в лог тестирования для опознания результатов). Например ‘fc dbpattern’.
Поле Run Time - время исполнения теста. Если тест состоит из нескольких запусков, то это длительность ОДНОГО запуска. Устанавливаем 1 минута.
Поле Ramp Up Time это время “разгона” системы перед началом замера. Устанавливаем 15 секунд.
Остальные поля оставляем по умолчанию.
В Cycling Option выбираем из выпадающего списка “Cycle # Outstanding IOs — …” Это установит тестирование с прогрессивно увеличивающимся количеством потоков выполнения (Outstanding IOs).
В поле # of Outstanding IOs указываем Start:1 End:256 Power:2 Exponential Stepping.
При этом количество потоков будет увеличиваться экспоненциально: 1,2,4 … 128,256.
Значение Outstanding IOs от 1 до 8 относится к очень “легким” программам, 128 и 256 - очень “тяжелым”. Целиком тест покажет нагрузочную способность в зависимости от интенсивности ввода-вывода от сервера.
Также можно увеличивать количество параллельно работающих workers, не забудьте предварительно их создать и назначить им паттерны нагрузки!
При выборе соответствующих вариантов тестирования становятся доступны поля ввода значений для этих режимов.
Каждый из таких потоков будет исполняться 1 минуту, итого 9 минут (+15 секунд ramp up на каждый тест) на полный тест паттерна.
Все готово.
Нажимаем на Start Tests (зеленый флажок в тулбаре). Если тестовый файл не был создан, то ожидаем, пока он будет создан, после чего начнется тестирование. Будет запрошено имя и раcположение файла результатов (по умолчанию results.csv). Желательно дать имя соответствующее профилю тестирования, например ‘fc dbpattern.csv’ для упрощения дальнейшего разбора.
Запустив тест пожно пойти посмотреть текущие результаты на “градусниках” в закладке Results Display.
В statusbar внизу программы отображается прогресс выполнения группы тестов.
По завершению тестирования одного паттерна перейти в Access Specifications и поменять паттерн. Изменить описание теста в Test Setup и запустить новый цикл.
