Microsoft Way

Зависимость результатов fio от производительности процессора и архитектуры СХД

Утилита создает нагрузку на дисковую систему согласно указанного шаблона. При этом нагрузка формируется самой утилитой, то есть в данной задаче напрямую задействован процессор.
Кроме того, при ряде сценариев тестирования также возникает дополнительная нагрузка, не связанная напрямую с непосредствено нагрузкой на блочное устройства, но влияющая на итоговые замеры.

Если кратко:
— При использовании различных scaling_governor фиксируется различная относительная нагрузка процесса тестирования на вычислительное ядро. Что объясняется простой логикой.
— Тестирование сырого блочного устройства имеет меньше накладных расходов чем тестирование сырого lvm тома на нем. Тут тоже все ожидаемо.
— Тестирование сырого lvm тома имеет меньше накладных расходов, чем тестирование через файл на файловой системе. Да и тут все ожидаемо.
— Первый проход тестирования через файл на ФС имеет повышенные накладные расходы, второе и последующие имеют существенно меньшие и схожие между собой.
— При высокой производительности тестируемого устройства и при его тестировании через файл на ФС, из-за повышенных накладных расходов на первом проходе тестирования, фиксируется существенные различия замеров при использовании различных scaling_governor
— При тестировании только записи на сыром lvm томе, подключенном по FC к полноценной СХД, могут наблюдаться ошибочные существенно завышенные результаты.
— Результаты тестирования по шаблону только записи изнутри виртуальной машины, при условии ее размещения на подключенному по FC томе с полноценной СХД, могут давать завышенные результаты. В свойствах ВМ для ее диска формата RAW указано не использовать кэширование. Ситуация очень похожа на упомянутую выше про тестирование сырого тома с СХД.

Производим перезагрузку хоста.
Запускаем тестирование на локальном магнитном диске
Параметры fio -name iops -rw=randwrite -bs=64K -iodepth 8 -size 5G -ioengine=libaio -direct=1 -group_reporting
(1) [w=20.0MiB/s][w=320 IOPS]
Удаляем iops.0.0
(2) [w=19.7MiB/s][w=315 IOPS]
(3) [w=27.3MiB/s][w=436 IOPS]
Производим запуск внутри виртуальной машины диск которой также располагается локально
(1) [w=44.4MiB/s][w=709 IOPS]
(2) [w=64.5MiB/s][w=1032 IOPS]

Здесь можно было бы объяснить тем, что хотя в свойствах ВМ и указано не кэшировать io внутри, диск ВМ представляет собой qcow2 файл.

Производим перезагрузку хоста.
Запускаем тестирование на локальном магнитном диске
Параметры fio -name iops -rw=randwrite -bs=32K -iodepth 256 -size 5G -ioengine=libaio -direct=1 -group_reporting
(1) [w=13.5MiB/s][w=433 IOPS]
(2) [w=21.0MiB/s][w=671 IOPS]
(3) [w=14.5MiB/s][w=465 IOPS]
(4) [w=15.5MiB/s][w=497 IOPS]
(5) [w=11.9MiB/s][w=381 IOPS]
Перезагрузим гипервизор
(1) [w=11.4MiB/s][w=363 IOPS]
(2) [w=9.94MiB/s][w=318 IOPS]
(3) [w=15.5MiB/s][w=494 IOPS]
(4) [w=15.7MiB/s][w=501 IOPS]
Изменим scaling_governor на performance
(1) [w=18.2MiB/s][w=583 IOPS]
(2) [w=11.4MiB/s][w=365 IOPS]
(3) [w=13.4MiB/s][w=429 IOPS]
(4) [w=19.5MiB/s][w=623 IOPS]

Другая нода, сначала без изменение scaling_governor
Запускаем тестирование на локальном магнитном диске
Параметры fio -name iops -rw=randwrite -bs=128K -iodepth 32 -size 5G -ioengine=libaio -direct=1 -group_reporting
(1) [w=20.1MiB/s][w=161 IOPS]
(2) [w=37.6MiB/s][w=301 IOPS]
(3) [w=46.6MiB/s][w=373 IOPS]
(4) [w=66.2MiB/s][w=530 IOPS]
(5) [w=26.2MiB/s][w=209 IOPS]
(6) [w=51.6MiB/s][w=412 IOPS]
(7) [w=50.4MiB/s][w=403 IOPS]
Изменим scaling_governor на performance
(1) [w=47.4MiB/s][w=379 IOPS]
(2) [w=18.6MiB/s][w=149 IOPS]
(3) [w=44.4MiB/s][w=355 IOPS]
(4) [w=15.8MiB/s][w=126 IOPS]

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

Перезагрузим ноду
Текущий scaling_governor установлен в conservative
Тестирование производится удаленного скоростного диска, подключенного по iscsi
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/sdb -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46700msec); 0 zone resets
cpu : usr=11.26%, sys=30.90%, ctx=118026, majf=0, minf=12
(2) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46639msec); 0 zone resets
cpu : usr=10.53%, sys=31.89%, ctx=242505, majf=0, minf=286
(3) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46721msec); 0 zone resets
cpu : usr=10.73%, sys=31.07%, ctx=122057, majf=0, minf=28

Перезагрузим ноду и посторим все замеры
Текущий scaling_governor установлен в conservative
Тестирование производится удаленного скоростного диска, подключенного по iscsi
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/sdb -ioengine=libaio -direct=1 -group_reporting
(1)b write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46626msec); 0 zone resets
cpu : usr=9.98%, sys=33.01%, ctx=250365, majf=0, minf=93
(2) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46710msec); 0 zone resets
cpu : usr=10.39%, sys=31.69%, ctx=234150, majf=0, minf=221

Изменим scaling_governor на performance
Тестирование производится удаленного скоростного диска, подключенного по iscsi
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/sdb -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=28.0k, BW=110MiB/s (115MB/s)(5120MiB/46745msec); 0 zone resets
cpu : usr=10.07%, sys=26.44%, ctx=125599, majf=0, minf=139
(2) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46701msec); 0 zone resets
cpu : usr=9.37%, sys=26.94%, ctx=127950, majf=0, minf=93

Изменим scaling_governor на powersave
Тестирование производится удаленного скоростного диска, подключенного по iscsi
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/sdb -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46669msec); 0 zone resets
cpu : usr=10.69%, sys=30.96%, ctx=254887, majf=0, minf=152
(2) write: IOPS=28.0k, BW=110MiB/s (115MB/s)(5120MiB/46745msec); 0 zone resets
cpu : usr=11.59%, sys=32.90%, ctx=120241, majf=0, minf=151

Изменим scaling_governor на performance
Тестирование производится удаленного скоростного диска, подключенного по iscsi
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/sdb -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46669msec); 0 zone resets
cpu : usr=8.90%, sys=27.05%, ctx=251261, majf=0, minf=152
(2) write: IOPS=28.0k, BW=109MiB/s (115MB/s)(5120MiB/46767msec); 0 zone resets
cpu : usr=9.68%, sys=26.55%, ctx=131558, majf=0, minf=30
(3) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(5120MiB/46660msec); 0 zone resets
cpu : usr=8.99%, sys=27.03%, ctx=199174, majf=0, minf=80

То есть, выше установлено, что прослеживается зависимость отображаемой загрузки процессора утилитой тестирования от установленного scaling_governor. Что вполне закономерно: чем ниже предоставленная производительность, тем выше нагрузка от одной и той же операции.

Создадим LVM структуру на томе
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -filename=/dev/testvg01/lvol0 -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=28.0k, BW=110MiB/s (115MB/s)(5116MiB/46700msec); 0 zone resets
cpu : usr=9.82%, sys=31.19%, ctx=111286, majf=0, minf=22
(2) write: IOPS=28.0k, BW=110MiB/s (115MB/s)(5116MiB/46709msec); 0 zone resets
cpu : usr=9.33%, sys=29.62%, ctx=236376, majf=0, minf=95

Существенных изменений не выявлено. За исключением небольшого роста нагрузки на CPU от обработки вызовов уровня ядра.

Создадим файловую систему mkfs.ext4 /dev/testvg01/lvol0
Произведем монтирования ФС mount /dev/testvg01/lvol0 /mnt/001
Перейдем в каталог /mnt/001
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -size=4G -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=25.9k, BW=101MiB/s (106MB/s)(4096MiB/40436msec); 0 zone resets
cpu : usr=10.11%, sys=66.07%, ctx=128346, majf=0, minf=143
(2) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(4096MiB/37369msec); 0 zone resets
cpu : usr=11.08%, sys=35.31%, ctx=83003, majf=0, minf=17
(3) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(4096MiB/37352msec); 0 zone resets
cpu : usr=10.20%, sys=35.71%, ctx=82183, majf=0, minf=16

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

Удалим файл rm -f iops.0.0 в каталоге /mnt/001
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -size=4G -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=23.4k, BW=91.4MiB/s (95.9MB/s)(4096MiB/44806msec); 0 zone resets
cpu : usr=10.11%, sys=62.55%, ctx=299813, majf=0, minf=87
(2) Загрузка снова уменьшилась

Гипотеза подтверждена

Изменим scaling_governor на powersave
Удалим файл rm -f iops.0.0 в каталоге /mnt/001
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -size=4G -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=18.8k, BW=73.4MiB/s (77.0MB/s)(4096MiB/55766msec); 0 zone resets
cpu : usr=9.57%, sys=64.94%, ctx=343009, majf=0, minf=335
(2) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(4096MiB/37363msec); 0 zone resets
cpu : usr=12.49%, sys=40.26%, ctx=84170, majf=0, minf=181
(3) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(4096MiB/37380msec); 0 zone resets
cpu : usr=12.19%, sys=40.70%, ctx=87422, majf=0, minf=186

Снова изменим scaling_governor на performance
Удалим файл rm -f iops.0.0 в каталоге /mnt/001
Параметры fio -name iops -rw=randwrite -bs=4K -iodepth=64 -size=4G -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=22.7k, BW=88.8MiB/s (93.1MB/s)(4096MiB/46122msec); 0 zone resets
cpu : usr=9.62%, sys=61.84%, ctx=315697, majf=0, minf=198
(2) write: IOPS=27.9k, BW=109MiB/s (114MB/s)(4096MiB/37601msec); 0 zone resets
cpu : usr=11.29%, sys=38.62%, ctx=90862, majf=0, minf=24
(3) write: IOPS=28.1k, BW=110MiB/s (115MB/s)(4096MiB/37340msec); 0 zone resets
cpu : usr=10.16%, sys=35.49%, ctx=97771, majf=0, minf=90

Как можно убедиться выше, при использовании scaling_governor = powersave увеличенная нагрузка при первом в серии тестировании оказывает существенное влияние на полученный тестированием показатель производительности блочного устройства. То есть, фактически, при этом утилита тестирования занижает реальные показатели аппаратного обеспечения.

Проведем тестирование удаленного общего блочного устройства с СХД, подключенного по FC с multipath
Проверим, что scaling_governor установлен на performance
Перейдем в папку хранилища конфигураций виртуальных машин /vms-shares/storage_9 являющуюся lvm томом целевого блочного устройства
Параметры fio -name iops -rw=randwrite -bs=16384K -iodepth=128 -size=4G -ioengine=libaio -direct=1 -group_reporting
Перед каждым тестом будем удалять файл rm -f ./iops.0.0
(1) write: IOPS=11, BW=182MiB/s (191MB/s)(4096MiB/22507msec); 0 zone resets
cpu : usr=0.45%, sys=50.51%, ctx=120757, majf=0, minf=18
(2) write: IOPS=11, BW=181MiB/s (190MB/s)(4096MiB/22650msec); 0 zone resets
cpu : usr=2.20%, sys=48.75%, ctx=117264, majf=0, minf=18
(3) write: IOPS=11, BW=180MiB/s (189MB/s)(4096MiB/22737msec); 0 zone resets
cpu : usr=0.04%, sys=50.40%, ctx=90399, majf=0, minf=18

Изменим scaling_governor на powersave
Перейдем в папку хранилища конфигураций виртуальных машин /vms-shares/storage_9 являющуюся lvm томом целевого блочного устройства
Параметры fio -name iops -rw=randwrite -bs=16384K -iodepth=128 -size=4G -ioengine=libaio -direct=1 -group_reporting
Перед каждым тестом будем удалять файл rm -f ./iops.0.0
(1) write: IOPS=9, BW=158MiB/s (166MB/s)(4096MiB/25854msec); 0 zone resets
cpu : usr=1.90%, sys=55.62%, ctx=123132, majf=0, minf=20
(2) write: IOPS=9, BW=159MiB/s (167MB/s)(4096MiB/25743msec); 0 zone resets
cpu : usr=1.37%, sys=54.63%, ctx=566, majf=0, minf=18
(3) write: IOPS=9, BW=160MiB/s (167MB/s)(4096MiB/25654msec); 0 zone resets
cpu : usr=0.10%, sys=56.70%, ctx=2760, majf=0, minf=18

Снова изменим scaling_governor на performance
Перейдем в папку хранилища конфигураций виртуальных машин /vms-shares/storage_9 являющуюся lvm томом целевого блочного устройства
Параметры fio -name iops -rw=randwrite -bs=16384K -iodepth=128 -size=4G -ioengine=libaio -direct=1 -group_reporting
Перед каждым тестом будем удалять файл rm -f ./iops.0.0
(1) write: IOPS=11, BW=182MiB/s (191MB/s)(4096MiB/22459msec); 0 zone resets
cpu : usr=1.98%, sys=47.68%, ctx=1096, majf=0, minf=18
(2) write: IOPS=11, BW=178MiB/s (187MB/s)(4096MiB/22960msec); 0 zone resets
cpu : usr=1.85%, sys=48.23%, ctx=120651, majf=0, minf=18

Проведем тестирование сырого lvm тома с целевого блочного устройства
Создадим том lvcreate -n test001 -L5G external_storage_9
Параметры fio -name iops -rw=randwrite -bs=16384K -iodepth=32 -filename=/dev/external_storage_9/test001 -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=41, BW=658MiB/s (690MB/s)(20.0GiB/31119msec); 0 zone resets
cpu : usr=4.45%, sys=5.46%, ctx=7306, majf=0, minf=98333
(2) Схожие показатели
(3) Схожие показатели

Это очень занятный результат в свете того, что на стороне СХД всего 2Гб кэша, объем заданного тома 20Гб, а физическое хранилище представляет из себя группу магнитных дисков в raid50.
То есть здесь наблюдается очевидно ошибочные показатели при использовании указанного выше шаблона тестирования и тестирования только записи.

Проверим, что scaling_governor установлен на performance
Запустим ВМ с диском расположенным в виде lvm тома на хранилище, что и lvm том из тестов выше
Параметры fio -name iops -rw=randwrite -bs=16384K -iodepth=128 -size=4G -ioengine=libaio -direct=1 -group_reporting
Перед каждым запуском будем удалять файл rm -f ./iops.0.0
(1) write: IOPS=43, BW=696MiB/s (730MB/s)(4096MiB/5884msec); 0 zone resets
cpu : usr=4.20%, sys=1.56%, ctx=406, majf=0, minf=10
(2) write: IOPS=42, BW=684MiB/s (718MB/s)(4096MiB/5986msec); 0 zone resets
cpu : usr=6.57%, sys=0.00%, ctx=402, majf=0, minf=10

На ВМ также проведем дополнительное тестирование
Изменим параметры fio -name iops -rw=randwrite -bs=64K -iodepth=128 -size=8G -ioengine=libaio -direct=1 -group_reporting
(1) write: IOPS=1460, BW=91.3MiB/s (95.7MB/s)(8192MiB/89756msec); 0 zone resets
cpu : usr=1.74%, sys=5.58%, ctx=36325, majf=0, minf=11

P.S.
Статья изначально написана для внутреннего пользования, но никаких страшных тайн здесь не раскрывается и никакие гипервизоры не указываются. По большому счету, изложенное ниже применимо ко всем kvm based, потому как kvm здесь где-то рядом, а речь в основном даже не о нем. Если вы обнаружили эту статью у себя во внутренней базе знаний, любые совпадения и ФИО автора случайны. Все как обычно.