Существует большое количество программных продуктов, нацеленных на тестирование производительности дисковой подсистемы: iozone, bonnie, iometer, vdbench, filebench. И у каждого из них есть свои достоинства. Например, номер предыдущей актуальной версии iozone (3.396), будучи умноженным на 1000, без остатка делился на 283. Но в данной статье речь пойдет о возможности vdbench'а воспроизводить дисковую нагрузку, снятую с реальной работающей системы.
Это чрезвычайчно удобный инструмент, помогающий спрогнозировать поведение приложения при изменениях дисковой подсистемы. Типичный пример: жила была база данных на внутренних дисках и ее задумали переселить на дисковый массив. Достаточно ли будет RAID5 или надо использовать RAID10? Справятся ли с задачей диски на 7200RPM?
Конечно проще всего намерить тестовыми пакетами синтетических IOPS'ов на доступных конфигурациях. Но в реальной ситуации непонятно куда девать все эти измеренные цифры. Одна система может выигрывать на последовательных операциях, другая на произвольных. Более того, синтетические приложения, как правило генерируют поток дисковых операций согласно определенному закону распределения с заданным соотношением чтения/записи, произвольных/последовательных операций. Но реальной нагрузке присуща нестационарность со спадами и пиками интенсивности запросов, каждая реальная нагрузка имеет свою локальность, определяемую уникальной последовательностью адресов по которым происходит обращение. А от этого напрямую зависит процент попадания в кэш.
Используя vdbench можно воспроизводить дисковую активность реального приложения без необходимости разворачивать тестовое окружение с таким же приложением и нагрузчиком, имитирующем пользователей. Не вдаваясь в лишние подробности, работает это все следующим образом: на реальной системе запускается программа swat (Sun StorageTek Workload Analysis Tool), создающая trace dump со всеми обращениями к диску за интересующий нас период времени. Поддерживаются ОС Solaris и Windows. Далее на любой системе, запускается vdbench, воспроизводящий нагрузку с использованием полученного файла. Здесь важно отметить, что записываются, а следовательно и воспроизводится будут операции на уровне блочный устройств (для выбранных блочных устройств сохраняются метка времени, тип операции, адрес и размер блока данных). Т.е. проверить влияние параметров файловой системы не удастся. Так же, если на системе хранения используется дедупликация, то результаты конечного тестирования будут, мягко говоря, неточными.
На практике, полученные при помощи swat'а данные, перед использованием в vdbench необходимо еще немножко обработать.
Рассмотрим конкретный пример, с воспроизведением нагрузки диска c0t0d0.
1. Запись дампа
Создать дамп можно из интуитивно понятного GUI, запускаемого командой #swat -t.
Однако в случае использования Solaris'а достаточно скинуть на исследуемую систему скрипт tnfe.sh из каталога swat/solaris или swat/solx86 в зависимости от используемой архитектуры. Через ключи -e и -o можно задать продолжительность записи в секундах и каталог для сохранения дампа.
Usage: tnfe.sh [-e <seconds>] # number of seconds trace time, default 1800
[-o <trace_dir>] # output directory, default /tmp/tnfe_103011_2128
Естественно trace_dir должен располагаться на устройстве, отличном от нагружаемого. Так же надо учитывать, что при высокой интенсивности ввода-вывода dump может получиться довольно большой по размеру (можно расчитывать на 512Mb за час и более).
bash-3.00# ./tnfe.sh -e 120 -o /tmp/dump
Sun Oct 30 21:12:46 MSK 2011 Creating directories and removing possible old files
Sun Oct 30 21:12:46 MSK 2011 Current working directory: /tmp/dump
Sun Oct 30 21:12:46 MSK 2011 Checking for required patches ...
....
Sun Oct 30 21:12:52 MSK 2011 ktrace on at Sun Oct 30 21:12:52 MSK 2011
Sun Oct 30 21:12:58 MSK 2011 Waiting until the 120 second trace completes
Sun Oct 30 21:15:00 MSK 2011 trace completed after 120 seconds
Sun Oct 30 21:15:00 MSK 2011 Disabling kernel tracing
...
Sun Oct 30 21:15:50 MSK 2011 Extraction kernel trace buffer to tnf.raw1 completed
Sun Oct 30 21:15:50 MSK 2011 Total raw file size created: 128 mb, kept: 128 mb
...
2. Обработка полученных данных
Дальнейшие манипуляции можно проводить уже на другой системе. Нам понадобится содержимое каталога с дампом. Для получения файла, пригодного для воспроизведения в vdbench, необходимо выполнить еще две команды. Опять же, можно использовать GUI (Выбрать в File->SetTraceDirectory нужную папку, далее вкладки extract и analyze), а можно:
bash-3.00# ./swat -x /tmp/dump/tnf.raw*
21:51:45.408 swat execution parameter: '-x'
21:51:45.411 swat positional parameter: '/tmp/dump/tnf.raw1'
21:51:45.435
21:51:45.437 Tool will expire on: Fri Feb 14 00:45:12 MSK 2014
21:51:45.439
21:51:46.533 execute(): /usr/jdk/instances/jdk1.5.0/jre/bin/java -Xmx128m -cp ./:./classes:./swat.jar:./javachart.jar:./swing-layout-1.0.3.jar Swt.TnfeDump /tmp/dump/tnf.raw1
21:51:47.147 TNF trace started at: Sun Oct 30 21:12:52 MSK 2011
21:51:47.154 TNF trace ended at: Sun Oct 30 21:15:00 MSK 2011
21:51:47.169 File to be extracted: /tmp/dump/tnf.raw1
21:51:48.769 execute(): /usr/sbin/psrinfo -v
21:51:49.825 Online processor count: 1 ; avg speed: 2041 mhz
21:51:49.827 Running Extraction using maximum 1 TnfeDump threads. (Maximum 4; #processors / 2)
21:51:49.830 Starting dump for /tmp/dump/tnf.raw1
21:51:49.859 execute(): /root/s/solx86/tnfedump /tmp/dump/tnf.raw1 | /root/s/swat atobin - /var/tmp/tnfedump8394873101955327749.bin
21:51:49.897 Processing file /tmp/dump/tnf.raw1
21:51:50.720 swat positional parameter: 'atobin'
21:51:50.724 swat positional parameter: '-'
21:51:50.728 swat positional parameter: '/var/tmp/tnfedump8394873101955327749.bin'
21:52:04.958 Start of table sort: 4567 entries
21:52:04.961 End of table sort. Starting output generation.
21:52:05.432 Ending dump for /tmp/dump/tnf.raw1
21:52:06.695 Records written after completion of /tmp/dump/tnf.raw1: 4567
В результате имеем файл tnf.bin.gz, на который надо натравить swat -ar:
bash-3.00# ./swat -ar /tmp/dump/tnf.bin.gz
21:57:12.684 swat execution parameter: '-a'
21:57:12.689 swat execution parameter: '-r /tmp/dump/tnf.bin.gz'
21:57:12.711
21:57:12.712 Tool will expire on: Fri Feb 14 00:45:12 MSK 2014
21:57:12.714
21:57:12.725 execute(): /usr/jdk/instances/jdk1.5.0/jre/bin/java -Xmx1024m -Xms256m -cp ./:./classes:./swat.jar:./javachart.jar:./swing-layout-1.0.3.jar Swt.Batch -r /tmp/dump/tnf.bin.gz
21:57:13.091 Batch execution parameter: '-r'
21:57:13.093 Batch positional parameter: '/tmp/dump/tnf.bin.gz'
21:57:13.244 Swat Version: swat302
21:57:15.441 TNF trace started at: Sun Oct 30 21:12:52 MSK 2011
21:57:15.444 TNF trace ended at: Sun Oct 30 21:15:00 MSK 2011
21:57:16.545 Swat version: swat302
21:57:16.664 Base timestamp for all trace data: 0 usecs
21:57:16.977 Last second: 0; lines: 4568 ( 1171/sec); Tables: 4464; 1904; 101; Heap: 18.33 MB;
21:57:16.979 Table entries before final flush: 4464
21:57:17.269 Unused entries purged during final flush: 0
21:57:17.277 Swat runtime in minutes before reporting: .0701
21:57:17.279 Creating Swat reports.
21:57:34.930 highest_second: 125
21:57:34.972 Swat completed: Runtime in minutes = .3650
Теперь мы получили файл flatfile.tar.gz, который уже можно скормить vdbench'у. В этом файле присутствет информация обо всех дисковых устройствах исходной системы, коих может быть великое множество, но нас интересует только c0t0d0. Поэтому необходимо узнать номер этого устройства в файле flatfile.tar.gz. Можно заглянуть в каталог /tmp/dump/output, где будут находится html файлы отчета swat и найти в них искомую цифирь, но проще провернуть все через GUI. Для этого в File->SetTraceDirectory выбираем папку с дампом, переходим во вкладку Reporter и жмякаем File->LoadTraceDate. Тут можно поанализировать нагрузку и полюбоваться на безумные графики. А что еще приятней можно сгенерировать шаблон для описания теста vdbench. Для этого в панели devices выбираем интересующий нас диск, тыркаем Ok, и выбираем в меню File->CreateReplayParameterFile. После чего програмный продукт усладит взора пользователя набором букв, примерно следующего содержания:
rg=rg1,device=(438086664192) * c0d0s0 ios: 1270 max lba: 5GB cum size: 5GB
sd=default,replay=rg1
sd=sd1,lun=/dev/rdsk/cxtxdxsx
sd=sd2,lun=/dev/rdsk/cxtxdxsx
sd=.. Specify enough SDs to allow for the cumulative size above
wd=wd1,sd=sd*
rd=run1,wd=wd1,elapsed=9999,interval=10,replay=/tmp/dump/flatfile.bin.gz
Здесь:
device=(438086664192) - именно та искомая цифирь устройства c0d0s0.
elapsed=9999 - время теста в секундах
interval=10 - интервал снятия статистики
replay=/tmp/dump/flatfile.bin.gz - путь до flatfile-а
