Записи с меткой «iozone»

ЭВМ/ Как измерить IOPSы

12.01.2011

Для измерения скорости произвольного доступа хранилища данных, тех самых пресловутых IOPS, я использую утилиту IOzone. Вообще, это чрезвычайно мощный инструмент, способный в умелых руках протестировать подробнейшим образом работу как физических носителей, так и файловых систем. Со всеми возможностями iozone можно познакомиться, прочитав объемную документацию. Установить программу можно либо с помощью штатного пакетного менеджера (если такой пакет есть для вашей ОС), либо собрав ее из исходников.

Для быстрой оценки производительности «на каждый день» я использую примерно такую команду:

iozone -O -i0 -i2 -s4g -r4k

Параметр -O задает вывод результата в IOPS, вместо KB/s. Параметр -i0 запускает тест линейной записи. Вообще, нам этот тест не нужен, но обойтись без него нельзя, так как с его помощью iozone создает рабочий файл для дальнейших тестов. Параметр -i2 запускает собственно тестирование произвольного чтения и записи. Параметр -s задает размер рабочего файла, в данном случае 4 GB; поддерживаются суффиксы: k (килобайты), m (мегабайты) и т. д. И, наконец, параметр -r задает размер блока данных, которые пишутся или читаются за одну операцию. Рассмотрим подробнее каждый из параметров на примере тестирования диска виртуальной машины в облаке.

Перед тестированием нужно создать на физическом носителе файловую систему и смонтировать ее (все происходит на Linux).

# mkfs.ext3 /dev/sda3
# mount /dev/sda3 /mnt
# cd /mnt

Здесь имя sda3 означает не третий раздел диска sda, а отдельный третий виртуальный диск, такая вот нумерация. Как видно, я размечаю файловую систему прямо по всему носителю, без создания таблицы разделов. Linux к этому относится спокойно, правда, для настоящих дисков выдает предупреждение:

/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n)

Наверное, выбор файловой системы слегка влияет на результат, но не думаю, что значительно. Поэтому для всех тестов я использую старую добрую EXT3.

Если нужно протестировать не физический носитель (диск или RAID массив), а, скажем, кластерную файловую систему (например GPFS), то достаточно просто перейти в открытую на запись директорию, в которую смонтирована тестируемая ФС.

В принципе, можно тестировать и без ФС, непосредственно физический носитель. Для этого достаточно с помощью ключа -f установить в качестве рабочего файла файл блочного устройства, например /dev/sda. Но при этом смысл результатов будет неясным, ведь использовать в дальнейшем диск мы все равно будем в связке с файловой системой.

С параметром -O все ясно. По умолчанию iozone выдает результат в виде скорости чтения или записи, и для получения количества операций в секунду эту скорость нужно делить на размер блока. С -O получаем сразу нужный результат. Параметр -i также не вызывает вопросов.

Размер файла следует выбирать не менее объема физической памяти, чтобы избежать влияния кэша ОС. На тестируемой машине 4 GB ОЗУ, поэтому размер файла нужно взять тоже 4 GB. Можно и больше, но это увеличит время теста. Влияние кэша легко увидеть, задав меньший объем файла и посмотрев на результаты повторной записи и чтения.

# iozone -i0 -i1 -s1g -r64k

     KB  reclen   write rewrite    read    reread
1048576      64  780190 1783292  4519722  5242880

Тесты i0 и i1, помимо записи и чтения, делают еще и повторные запись и чтение (rewrite и reread). Видно, что повторная запись проходит в 2 раза быстрее изначальной, а чтение выдает вообще космическую скорость — 5 GB/s. Все это — результат работы кэша. Теперь увеличим размер файла до 4 GB.

# iozone -i0 -i1 -s4g -r64k

     KB  reclen   write rewrite    read    reread
4194304      64  104857   79715    61255    53635

Вот теперь результаты похожи на правду. Повторная запись даже слегка медленней первоначальной, а скорость чтения в районе 50-60 MB/s.

Если тестируется кластерная файловая система, то при выборе размера файла следует также принимать во внимание размер кэша на нодах кластера. Допустим, на каждой ноде есть по 10 GB кэша, тогда и размер файла должен быть не менее 10 GB, а лучше еще больше.

Определившись с размером файла, переходим к размеру блока. Так как мы меряем количество операций ввода-вывода в секунду, то чем меньше размер блока, тем выше будет результат, так как блоки большего размера требуют больше времени для передачи. Реальные приложения оперируют блоками от 4 до 64 KB. Для получения максимально возможного для данного носителя результата, необходимо брать блок размером 4, а то и 2 или 1 KB. Но тут есть одно «но». Подобный тест может занять значительное время, так как файл должен быть полностью покрыт блоками. Допустим, мы тестируем SATA диск, и надеемся получить от него около 100 IOPS. Тогда для файла размером 4 GB и блока 4 KB время теста составит 4 * 1024 * 1024 / (4 * 100) = 10485 секунд, то есть около трех часов. Часто результат нужно получить быстро, пусть и не очень точно. В таком случае нужно либо уменьшать размер файла, что крайне нежелательно, либо увеличивать размер блока. С блоком в 64 KB прогнозируемое время теста будет в 16 раз меньше, то есть около 10 минут, что уже вполне приемлемо. Полученный результат будет не сильно отличаться от максимально возможного, и на это можно будет сделать небольшую поправку.

Для начала я запускаю тест с минимальный блоком в 4 KB.

# iozone -O -i0 -i2 -s4g -r4k

После этого в другом терминале выполняю команду iostat 1, чтобы контролировать, что происходит. В начале создается файл линейной записью, и iostat показывает примерно такую картину.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.26    4.21    0.00   95.53

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1              0.00         0.00         0.00          0          0
sda2              0.00         0.00         0.00          0          0
sda3            786.00         0.00     68528.00          0      68528

Контролировать скорость создания файла можно его периодическим просмотром.

# ls -lh /mnt
total 1.5G
-rw-r----- 1 root root 1.5G 2011-01-11 16:19 iozone.tmp
drwx------ 2 root root  16K 2011-01-11 15:20 lost+found

Если уже на этом этапе видно, что файл создается очень медленно, а результат нужно получить быстро, увеличиваем размер блока.

Когда параметр Blk_wrtn/s станет 0, это значит, что запись файла закончена, и начался тест случайного чтения. Параметр Blk_read/s при этом станет отличным от нуля.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00   14.16    0.00   85.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1              0.00         0.00         0.00          0          0
sda2              0.00         0.00         0.00          0          0
sda3            540.91      4355.29         0.00        880          0

Теперь нужно посмотреть на параметр tps и определить его среднее значение. Это будет текущая скорость чтения в IOPS. На основании нее по вышеприведенной формуле можно прикинуть, сколько времени займет тест; и если оно слишком велико, увеличить размер блока.

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

Собственно, для тестируемого диска блок в 4 KB оказался слишком маленьким, и я перезапустил тест с блоком в 64 K; через некоторое время результаты были готовы.

                                                   random  random
     KB  reclen   write rewrite    read    reread    read   write
4194304      64    1961    2795                       554     663

550 IOPS на чтение и 660 на запись. Блоками по 4 KB было бы еще больше.

В редких случаях одного потока не хватает, чтобы полностью нагрузить дисковый массив или кластерную файловую систему. Для таких случаев есть ключ -t, задающий количество одновременно работающих потоков. Количество потоков следует подобрать экспериментально, контролируя с помощью iostat рост IOPS с ростом числа потоков.

,