Системы хранения данных как предмет разговора
Posts tagged ‘performance’
В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков 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, как в плане размера, так и производительности.
Важно помнить несколько вещей, когда вы собираете статистику системы:
Установка 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=`hostname`
sqlplus=”sqlplus”
oracle_login=”perfstat/perfstat”
runas=”"
sysdba=”false”
-oracle_host - умолчание для localhost, может быть одним из хостов, определенных с помощью -h из команд perfstat
-sqlplus - может быть использован для того, чтобы определить абсолтный путь к команде ’sqlplus’
-runas - может использоваться для запуска sqlplus от имени другого пользователя (то есть пользователь Unix, где установлен Oracle, обычно не root.)
-sysdba - может использоваться для подключения к oracle как sysdba, игнорируя параметр oracle_login. Ключ sysdba вводит следующие команды в логин к sqlplus:
Примеры:
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
Более сложные примеры:
perfstat.sh -a oracle -t 5 -i 5 -f filer -o runas=oracle, sysdba=true >/opt/perfstat.out
Note: Для того, чтобы собирать статистику самого файлера вместе с данными статистики Oracle, должен быть использован ключ -f.
Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:
Еще почитать:
http://www.akadia.com/services/ora_statspack_survival_guide.html
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9096
http://www.dba-oracle.com/art_statspack.htm
http://www.datadisk.co.uk/html_docs/oracle/awr.htm
Взято тут:
http://blogs.netapp.com/databases/2009/07/gathering-oracle-statspack-data-for-netapp.html
* perfstat - собственная утилита - shell-script NetApp для сбора статистики, может быть скачана с вебсайта NOW: http://now.netapp.com/NOW/download/tools/perfstat/
Несомненно одна из “горячих тем” 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 и запустить новый цикл.
Тема измерения производительности столь велика и непроста, что стоит отдельной статьи только на эту тему. Однако без элементарных знаний, которые можно попробовать изложить кратко, для понимания рассматриваемой темы эффективной системы хранения не обойтись.
Для начала следует определить два основных общепринятых понятия, используемых для измерения производительности.
Первый из них – Input-Output Operations Per Second – IOPS - показывает количество операций ввода-вывода в секунду, которые способно обработать устройство. Этот параметр прежде всего характеризует скорость обработки коротких запросов, и наиболее часто применим для оценки таких задач, как OLTP-база данных и близких к ней.
Операции базы данных как правило характеризуются обменом относительно небольшими блоками (как правило 4-8KB). Каждая такая операция по считыванию или записи блока является одним IOPS-ом. Таким образом, чем выше показатель производительности в IOPS, тем выше производительность базы данных.
Другим параметром, характеризующим производительность, является Скорость передачи данных, так называемый traffic throughput, измеряемый в MB/s, то есть количеством мегабайт, проходящих по интерфейсу ввода-вывода в секунду.
Этот параметр характеризует скорость обработки в случае больших блоков, классическая задача, для которой критичен именно параметр MB/s, это аудио-видео обработка, резервное копирование и DSS-базы данных.
Какой же из этих параметров более «правильный», какой более важен? Разумеется оба.
Однако следует понимать, что оба этих параметра связаны между собой «обратно пропорционально». Увеличение величины в IOPS вызывает снижение величины в MB/s и наоборот.
Чтобы понять почему так, нужно рассмотреть простой пример и аналогию.
По дороге следует переместить из А в Б большое количество человек. Возможно два варианта: мы можем перевозить их в их личных автомобилях или же усадить в автобусы. Пропускная способность дороги конечно же будет выше в случае перевозки людей автобусами, то есть «большими блоками». Однако методы общественного транспорта обычно вступают в конфликт с индивидуальными целями и маршрутами. Хорошо если в Б у нас огромный завод, на который устремлен основной поток из А. Можно погрузить все «байты» в один большой пакет-автобус на входе, и выгрузить его на остановке у завода, куда собственно и направляются все наши «байты».
Однако если наши байты не едут на завод, а разъезжаются по индивидуальным и независимым делам-«операциям», каждый имея индивидуальный маршрут, то доставка их «автобусом»-большим пакетом приведет напротив к большим потерям времени. В этом случае транспортировка индивидуальными автомобилями будет более выгодна. Однако общий пропускной объем дороги заполненной индивидуальными «пакетами»-авомобилями везущими по нескольку байт каждый, разумеется будет ниже, чем при перевозке большим пакетом-«автобусом».
Таким образом увеличение пропускной способности в MB/s за счет укрупнения пакетов приводит к снижению IOPS, и наоборот, рост операций в секунду «доставленных к цели пассажиров» нашей дороги-интерфейса, запруженной автомобилями, приводит к снижению ее пропускной способности в MB/s. Нельзя одновременно достичь высоких показателей в IOPS и в MB/s просто по физическим свойствам существующего оборудования.
Либо большие пакеты-«автобусы» и их мало («операций в секунду»), либо маленькие индивидуальные пакеты-«автомобили», каждый осуществляющий индивидуальную «операцию» по доставке данных, но заполняющие всю дорогу, и общий human traffic в результате невелик.
Отсюда видно, что широко разрекламированная величина пропускной способности интерфейса SATA-II дисков в 300MB/s далеко не всегда (а чаще и вообще никогда) не будет достижима на практике. Более того, в случае использования таких дисков для операций с базой данных OLTP роль будет играть не столько потоковая производительность интерфейса, сколько гораздо реже публикуемая максмальная величина IOPS диска, в настоящий момент равная для SATA 7200rpm примерно 50 IOPS, и в случае OLTP-нагрузки выиграет не диск с самыми высокими данными по мегабайтам в секунду, а самый быстродействующий по IOPS - параметру, напрямую связанному с рассмотренной выше «латентностью», такой как, например, диск с интерфейсом FC и скоростью вращения 15Krpm, для которого величина IOPS достигает 200. При прочих равных диски SATA всегда проиграют в случае работы с базой данных не только дискам FC, но и традиционным SCSI.
Однако в случае использования дисков на задачах считывания и записи аудио-видеоданных, или резервного копирования, характеризующихся большим и постоянным потоком данных большими блоками, диски SATA вполне могут быть не хуже значительно более дорогостоящих FC или SCSI, легко выигрывая у них за счет цены за хранимый мегабайт.
Как мы видим, точное понимание решаемых задач безусловно необходимое требование при выборе того или иного решения дисковой системы хранения.