Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Testing | about NetApp

Posts tagged ‘testing’

Производительность в Cluster-mode: опубликованы результаты

Мы уже весь этот год понемногу говорим о новой для пользователей NetApp “классической”, 7-mode архитектуры, схеме Cluster-mode. В отрасли все еще довлеет определенный груз недоверия, Cluster-mode считается, во-первых,  дорогим (но о цене и спецпредложении двухузловой cluster-mode по цене HA-пары 7-mode, и о “Cisco Nexus за 1$” мы уже говорили ранее), сложным в развертывании и установке (но рекомендую сделать поиск по Techlibrary по слову “cluster-mode”) и имеющим значительный оверхед по производительности, в сравнении с системой 7-mode. ? вот об этом последнем мы поговорим сегодня.

К моему глубокому сожалению некоторые такие предрассудки о производительности системы в Cluster-mode  разделяли и отдельные знакомые мне специалисты самого NetApp.

Поэтому так интересно было посмотреть на официально опубликованный отчет по измерению и сравнению производительности системы Cluster-mode и 7-mode.

Была протестирована производительность работы системы хранения FAS6240 под задачи четырехнодового Oracle RAC на OLTP нагрузке, под всеми поддерживаемыми протоколами, в конфигурации хранилища как 7-mode, так и Cluster-mode, в максимально идентичной конфигурации OS, базы, настроек оборудования. Для затравки вам картинка, остальное по ссылке на полный отчет с описанием методики тестирования.

image

Как вы видите, согласно этому тесту производительность Cluster-mode ниже аналогичной системы 7-mode не более чем на 7% в наихудшем случае, при, безусловно, значительно большем количестве возможностей, “фич” и перспективах масштабирования решения Cluster-mode.

Еще о тестировании Cluster-mode в SPC-1

Я не первый раз рубликую тут переводы постов инженера NetApp – Dimitris Krekoukias, ведущего автономный, и крайне интересный блог http://recoverymonkey.org/ (другие мои переводы его постов вы можете найти в рубрике “переводы”)

После долгого молчания, Dimitris опубликовал пост, вызванный публикацией отличных результатов кластера FAS6240 в Data ONTAP 8.1.1 Cluster-mode в бенчмарке блочного (FC) доступа – SPC-1, о котором я уже написал в понедельник. Однако вопросу почему он так хорош, и насколько именно он хорош – посвящен сегодняшний перевод.

NetApp опубликовал великолепные результаты тестирования Cluster-Mode в бенчмарке SPC-1

Опубликовано June 20, 2012

Мы тут в NetApp были довольно сильно заняты… заняты совершенствованием единственной в отрасли масштабируемой платформы хранения с универсальным доступом к данным, даже не считая множества разных других имеющихся в ней полезных штук.

Мы недавно выпустили ONTAP 8.1, которая, в Cluster-Mode, позволяет создать 24-узловой кластер (каждый узел которого может иметь до 8TB кэша) для задач NAS, и 4-узловой кластер для блочного доступа (FC и iSCSI).

А с выпуском ONTAP 8.1.1 (выпущенного 14 июня), мы увеличили лимит узлов для блочного доступа до 6, плюс добавили ряд дополнительных оптимизаций и возможностей. Между прочим, число узлов в кластере это пока только условный лимит официальной поддержки, это не жестко заданное ограничение.

После публикации нашего рекордного результата в бенчмарке NFS, люди спрашивали, как обстоит дело с производительностью блочного ввода-вывода в ONTAP Cluster-Mode, поэтому мы провели тестирование и опубликовали результаты бенчмарка SPC-1, используя часть той же системы, что уже была протестирована на SPEC sfs2008 NFS.

Для тех кто до сих пор думает, что NetApp не подходит для блочного доступа (это типичный FUD наших конкурентов): Это, на сегодня, лучший результат SPC-1 среди всех дисковых систем хранения, из расчета на уровень latency при достигнутом уровне IOPS (то есть возможно получить даже более высокие показатели IOPS на бОльших лимитах по latency, как я покажу далее в этом посте).

Вот ссылка на результаты и еще одна ссылка, на полную версию со всей доступной информацией.

В этом блоге я уже говорил о том, что представляет собой бенчмарк SPC-1 . Вкратце: Бенчмарк SPC-1 это общепринятый в индустрии, аудируемый, бенчмарк блочного доступа к системе хранения (по Fiber Channel) который проводит стресс-тестирование дисковой подсистемы большим объемом записей, перезаписей, локальных "хотспотов" и смешанной произвольно/последовательной, чтение-после-записи, запись-после-чтения нагрузкой. Около 60% рабочей нагрузки это операции записи. Размеры используемых в бенчмарке операций ввода-вывода различны, от маленьких до больших (таким образом IOPS в бенчмарке SPC-1 не идентичны и не могут быть сравнены напрямую с классическим тестом IOPS в full random блоками 4KB).

Если сторадж успешно работает на нагрузке SPC-1,, он, обычно, также крайне производительно работает на сложной, чувствительной к показателям latency, динамично изменяющейся нагрузке типа баз данных, в особенности OLTP. Полная спецификация для смертельно любопытных может быть найдена здесь.

Трюк с бенчмарками обычно состоит в интерпретации результатов. Сама по себе величина достигнутых IOPS, хотя и полезна, но не показывает всей картины, и того, как данный результат соотносится с реальной жзнью и реальными приложениями. Мы попытаемся помочь расшифровать результаты в этом посте.

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

  1. В тестах NetApp не используется диски "с коротких ходом" (short-stroking), так часто любимые многими вендорами, проводящими тестирование, при котором используется только внешняя, наиболее быстродействующая часть диска, где сочетается максимальная линейная скорость и малый разбег механики коромысла жесткого диска, на чем можно показать наилучшие результаты. Вместо этого мы используем настройку параметров системы , чтобы использовать всю поверхность дисков, и не зависеть от того, насколько заполнены данными диски. Смотрите полный отчет здесь, страница 61. Для любителей распространять FUD: это эффективно "старит" состояние WAFL, приближая его к реальному состоянию реально эксплуатируемой системы. Мы также не используем оптимизацию размещения блоков путем их реаллокации.
  2. Падения производительности в ходе продолжительного тестирования не наблюдалось.
  3. Средняя величина latency (“All ASUs” в результатах) была плоской и оставалась ниже уровня 5ms на протяжении нескольких итераций теста, включая sustainability test в течение 10 часов (страница 28 полного отчета).
  4. Не использовался дополнительный кэш, кроме того, который поставляется в базовой поставке FAS6240 (Контроллеры 6240 поставляются с Flash Cache емкостью 512GB, при максимальной возможной емкости данной модели 3TB на ноду (контроллер), то есть для работы с большими нагрузками есть еще значительный запас).
  5. Это не "звездолет", построенный исключительно для завовевания победы и установления рекорда в бенчмарке. Мы использовали сравнительно немного дисков, в сравнении с конфигурациями других вендоров, и это не самая быстрая наша модель контроллера (еще есть 6280).

Анализ

Когда мы смотрим на результаты бенчмарка, следует сфокусироваться на следующих моментах:

  1. Высокий уровень установившейся производительности в IOPS (нестабильность показателей показывает на наличие проблем).
  2. IOPS/диск (это показатель эффективности – 500 IOPS/drive это вдвое лучше и эффективнее, чем 250 IOPS/drive, что, как следствие, означает меньше необходимых дисков в системе, снижает ее стоимость, уменьшает физический занимаемые в датацентре объем, и так далее.)
  3. Стабильно низкая latency (пики показывают наличие проблем).
  4. IOPS связан и зависит от latency (Получили ли вы высокие показатели IOPS вместе с высокой latency на максимуме? Это практически используемо?)
  5. Какой тип RAID использовался (RAID6? RAID10? RAID6 обеспечивает значительно лучшую защиту данных и лучшие результаты эффективности использования дискового пространства, чем зеркалирование, что ведет к снижению стоимость даже более надежного хранилища данных).
  6. Какие диски использовались? Хотите ли вы покупать такие диски?
  7. ?спользовался ли autotiering? Если нет, то почему нет? Разве он не помог бы в такой сложной ситуации?
  8. Какое оборудование потребовалось, чтобы получить стабильную производительность (сколько дисков и контроллеров потребовалось для построения системы? Означает ли это более сложную и дорогую систему? Как это все будет управляться?)
  9. Цена (некоторые вендоры указывают цену уже с учетом дисконта, в то время как другие публикуют цену в list price, так что будьте тут внимательнее).
  10. Цена/IOPS (наиболее полезная метрика – но следует сравнивать цену list price с list price).

SPC-1 это бенчмарк НЕ для измерения максимума потока данных; для измерения чистого GB/s смотрите другие бенчмарки. Большинство систем не дает больше 4GB/s в этом бенчмарке, так как много операций в нем рандомные (и 4GB/s это довольно много для рандомного ввода-вывода).

Сравнение систем

В этой части мы сравним дисковые системы хранения. Предсказуемо "чистые SSD" (или RAM) системы хранения имеют, конечно, очень высокие показатели производительности, и могут подойти, если ваша задача - обеспечивать работу с небольшим объемом данных очень быстро.

Но мы сосредоточимся на задачах высоконадежных систем общего применения, которые обеспечивают одновременно и высокую производительность, и низкую latency, и большую емкость, за разумную цену, а также, одновременно, большое количество функциональных фич(снэпшоты, репликация, кэширование в flash (megacaching), thin provisioning, дедупликация, компрессия, многопротокольность, включая NAS, и так далее). Опа – оказывается никто из конкурентов не может сделать сразу все что умеет делать NetApp.

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

Также есть несколько других дисковых систем хранения, со значительными результатами по IOPS, но если мы посмотрим на их результаты sustained latency (“Sustainability – Average Response Time (ms) Distribution Data” в любом из полных отчетов) мы увидим, что общие показатели latency чересчур высоки и наблюдается значительная неравномерность, в особенности в начальной фазе, с пиками до 30ms (что крайне много), поэтому мы не взяли их в расчет.

Вот краткий перечень систем и их параметров, отсортированных в соответствии с latency. Кроме этого показана и их стоимость в ценах list price (это можно найти в полном отчете о тестировании) плюс стоимость операции $/IOPS, посчитанная исходя из list price (многие вендоры приводят в отчетах цену с уже введенной скидкой, чтобы цена выглядела пониже):

 

image

…но ведь тут показано, что некоторые системы быстрее NetApp… Как так?

Это зависит от того, насколько важен для вас показатель latency и его низкая величина (и от того, принимаете ли вы в расчет используемый тип RAID). Для подавляющего большинства нагрузок типа баз данных, низкая latency операций ввода-вывода гораздо предпочтительнее высоких показателей latency.

Вот как это увидеть:

  1. Выберите один из приведенных выше линков на полные отчеты Допустим это будет 3Par, так как он показывает одновременно и высокие показатели производительности, и высокие значения latency.
  2. Найдем в отчете главу под названием "Response Time – Throughput Curve". Например это страница 13 в отчете по системе 3Par.
  3. Проследим, как latency резко растет при повышении загрузки системы.

Например посмотрим на кривую 3Par:

image

Заметьте то, как latency резко растет после некоей точки.

Теперь сравним с результатом NetApp (страница 13):

image

Отметьте, что результат NetApp не просто имеет хорошие показатели latency, но, что еще более важно, latency остается хорошей и растет исключительно медленно по мере увеличения нагрузки на систему.

Вот почему колонка“SPC-1 IOPS around 3ms” была добавлена в таблицу. Фактически это ответ на вопрос что бы было, если бы уровень latency был в тесте одинаков для всех протестированных систем?

Когда вы примете эту позицию, вы увидите, что система 3Par фактически медленнее, чем NetApp, если сравнить их на одинаково низком желаемом уровне latency.

Вы можете взять точные показатели latency из графика на странице 13, у NetApp таблица выглядит так (озаглавлено "Response Time – Throughput Data"):

image

Действительно, при сравнении результатов мы видим, что только IBM SVC (с кучей стораджей V7000 за ним) оказывается быстрее NetApp при столь же хороших показателях latency. Что плавно подводит нас к следующей главе…

Сколько железа обеспечивает такую производительность?

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

  • 8 SVC контроллеров (virtualization engines) плюс…
  • …16 отдельных систем V7000…
  • …каждая состоящая из еще 2 контроллеров SVC и 2 контроллеров RAID
  • 1920 дисков 146GB 15K RPM (не так-то просто такие купить нынче, не так ли?)
  • ?того 40 контроллеров SVC (8 больших и 32 поменьше), 32 RAID-контроллера, и все это битком наполнено дисками.

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

Сравним эту кухню с вариантом конфигурации NetApp:

  • 6 контроллеров в одном кластере
  • 432 диска 450GB 15K RPM (самый распространенный и массовый наш диск по состоянию на июнь 2012).

Вопросы (с удовольствие увижу ответы на них от других вендоров):

  1. Что произойдет при использовании RAID6 у других вендоров? NetApp всегда тестирует системы с использованием своей версии RAID6 (RAID-DP). RAID6 значительно надежнее, чем зеркалирование, особенно в больших пулах (не говоря уже о более эффективном использовании пространства дисков). Большинство клиентов не хотят покупать большую систему в конфигурации только-RAID10… (пользователи - задавайте вопросы вашим вендорам. Тут нет никакого волшебства – ручаюсь, у них есть внутренние результаты для RAID6, попросите показать их вам).
  2. Autotiering это одна из самых раскрученных сегодня фич, с признаками того, что это достижение, превосходящее изобретение пенициллина, или даже колеса, а может даже и огня… Однако никто из дисковых массивов не рассматривает использование SSD для autotiering (IBM опубликовала однажды результат – не впечатляет, делайте выводы). Это при том, что бенчмарк, по своей спецификации активно создающий "горячие точки" (hotspots) нагрузки, должен бы быть здесь идеальным кандидатом для демонстрации эффективности…
  3. Почему EMC и Dell не желают публиковать результаты SPC-1? (Они оба, кстати, члены SPC, Storage Performance Council). Только два этих вендора, из крупных игроков на рынке, кто еще не опубликовали свои результаты. EMC ранее говорила, что SPC-1 это нереалистичный тест – ну, типа только ваше приложение с вашими данными на вашем сторадже может показать по-настоящему реальные результаты. Это так, однако SPC-1 это общепринятый индустрией стандартный бенчмарк для блочного доступа произвольного характера, и отличная "лакмусовая бумажка".
  4. Для системы, которая регулярно позиционируется для нагрузки Tier-1, IBM XIV, результаты бенчмарков, увы, отсутствуют также, даже для самой новой ее Gen3. Неужели IBM стесняется показать свои результаты SPC-1 для этой системы?
  5. Наконец – некоторые наши конкуренты продолжают утверждать, что NetApp, дескать, это "не настоящий SAN", что это, якобы "эмуляция SAN", и так далее. Что бы это все ни значило на самом деле – может быть подход NetApp, с такой "эмуляцией" оказывается, по факту, лучше?… Максимальная write latency в этом тесте составила 1.91ms для в основном записываемой нагрузки!

?тоговые мысли

В накануне опубликованном результате бенчмарка SPC-1, NetApp показала вновь, что Data ONTAP в Cluster-Mode это высокопроизводительная и масштабируемая система, одинаково подходящая как для SAN, так и для NAS задач. Суммируя все вышесказанное, можно сказать, что ONTAP Cluster-Mode:

  • Позволяет строить высокопроизводительные и динамически-масштабируемые кластеры хранения для FC, iSCSI, NFS и CIFS.
  • Демонстрирует низкую latency при высокой производительности.
  • Предлагает исключительно хорошее соотношение price/performance.
  • Позволяет доступ к данным одной ноды с любых других нод.
  • Перемещает данные между нодами, не прерывая работы с ними (включая CIFS, что ранее не было практически невозможно).
  • Поддерживает традиционные для NetApp возможности (оптимизацию процессов записи, взаимодействие с приложениями, снэпшоты, дедупликацию, компрессию, репликацию, thin provisioning, и кэширование во flash (megacaching).
  • Может работать на в точности тех же самых контроллерах FAS, что и в 7-mode, что защищает инвестиции.
  • Может виртуализовывать системы хранения, расположенные за ними.

?сточник <http://recoverymonkey.org/2012/06/20/netapp-posts-great-cluster-mode-spc-1-result/>

Тестирование FCoE и iSCSI на FAS3170

Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
?змерялся FCoE и iSCSI по 10G Ethernet.

Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
http://www.netapp.com/us/library/research-papers/rp-unified-networking-evaluation.html

Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.

IOmeter file access patterns

Here a basic sample patterns for IOmeter testing evaluation.
Database and Fileserver patterns taken from Intel’s IOmeter distribution (prior it’s opensourse development), Workstation – from StorageReview.com website, Webserver – it’s an “empirical” pattern from some real webserver load.
Up-to-date IOmeter can be downloaded from SourceForge website (not from iometer.org, which still give you outdated “2006” version, latest (currently) is a 2008-rc2 for Windows32-64/IA64/Linux, with many improvements).

 

Database pattern (Intel/StorageReview.com)

Block size

% of size

% of read

% of random

8192b

100

67

100

 

Fileserver pattern (Intel)

Block size

% of size

% of read

% of random

512

10

80

100

1024

5

80

100

2048

5

80

100

4096

60

80

100

8192

2

80

100

16384

4

80

100

32768

4

80

100

65535

10

80

100

 

Workstation pattern (StorageReview.com)

Block size

% of size

% of read

% of random

8192

100

80

80

 

Webserver pattern

Block size

% of size

% of read

% of random

512

22

100

100

1024

15

100

100

2048

8

100

100

4096

23

100

100

8192

15

100

100

16384

2

100

100

32768

6

100

100

65535

7

100

100

131072

1

100

100

524288

1

100

100

Ready to use iometer settings file is here: iometer.icf

UPD: Slightly extended list of workloads in iometer settings file is here: iometer2.icf
Thanks to: Tony Voyellm, and http://vmind.ru/

(Моим русскоязычным читателям: пост сделан по просьбе некоторых “нерусскоязычных” людей, которые приходят сюда по ссылкам с поисковиков, на статью о тестировании с помощью IOmeter. К сожалению, параметры тестовых паттернов для IOmeter часто приходится искать по интернету отдельно, в существующем дистрибутиве они не включены, поэтому выложил их сюда).

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

Одним из наиболее популярных т.н. “синтетических” тестов является программа 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 и запустить новый цикл.

20/0.133

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.