bench-disks.rst

Бенчмаркинг дисков

SSD диски всегда дают лучшие результаты от разумной параллельности. Поэтому все тесты здесь для SSD имеет смысл провести с --iodepth=.... Возможно, вместо этого (или вместе с) добавить к fio опцию --jobs=.... Здесь важно с помощью настроек эмулировать нагрузку соответствующую настройкам Ceph, а не просто запредельную. Каноничная статья про IOPS: https://habr.com/post/154235

При тестах нужно учесть, что HBA может иметь собственный кеш, искажающий результаты. Не стоит отключать кеш на самом диске. Есть мнение, что он позволяет диску производить оптимизации при записи.

Некоторые производители дисков применяют свои инновационные технологии, поэтому тесты могут выдавать завышенные результаты (особенно если тесты не длятся достаточно долго). Для магнитных дисков хочется отдельно отметить HGST Media Cache Architecture: http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html

Тестировать лучше всего весь диск (/dev/sdX). Можно раздел или linear LVM (говорят, для NVME он таки тормозит), но точно не файл на ФС.

Перед каждым тестом SSD для получения воспроизводимых результатов лучше выполнить команду

blkdiscard /dev/YOUR_DEVICE

HDD или SSD под FullFlash

Линейное чтение/запись

fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \
--bs=4M --rw=read

fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \
--bs=4M --rw=write --sync=1

С HDD разница может быть значительной (в 2 раза?) в зависимости от того, в начале диска происходит тест или в конце. Скорость также зависит от плотности записи и количества оборотов в секунду. Плотность записи зависит от размера блинов и количества используемых плоскостей (количества головок).

Тест показывает максимально возможную скорость (смотреть МБ/сек). Запускать несколько потоков для HDD смысла нет. Во избежание влияния кеша диска (и расстояния от начала) при повторных запусках, возможно, стоит поменять на --rw=randread / --rw=randwrite. При этом результат тестов должен быть примерно тот же. TODO: убедиться, что в rand-режиме смещение выравнено по размеру блока.

Случайное чтение/запись

fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \
--bs=4k --rw=randread

fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \
--bs=4k --rw=randwrite --sync

Тест показывает максимальную скорость в самых худших для диска условиях (Смотреть IOPS).

Чтение

Для моделирования реальной нагрузки стоит запустить в несколько потоков. TODO: посмотреть какой опции в Ceph это соответствует. Для SATA технология NCQ даст ускорение для этого теста в многопоточном режиме. По моим экспериментам ускорение всего в 1.5 раза всего (но это не точно). Для типичного SATA контроллера, NCQ включается только в режиме AHCI.

Запись

При записи в основное хранилище (после записи в журнал) OSD запускает в параллель много операций записи, а потом один sync. В этом случае, диск имеет возможность (за счёт переставления порядка записи секторов, а также за счёт слияния смежных IO в один) произвести оптимизации. Я не знаю как в fio сэмулировать подобное поведение. Придумал две методики:

# Тестировать случайную запись в один поток с ожиданием синка -- это покажет

самый худший (но не реалистичный) случай.

# Тестировать без sync, но долго. Этим самым мы проверим возможности диска по

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

SSD под журнал

Линейная запись мелкими блоками в один поток. Журнал в системах хранилища использует именно такой паттерн (см. filestore_wal_).

fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \
--bs=4k --rw=write --sync

На типичном HDD 7200 об/мин. этот тест покажет 7200 / 60 = 120 оп./сек. На SSD результаты могут очень сильно отличаться -- от 200 IOPS до 250000 IOPS (NVME). TODO: примеры по конкретным моделям.

Для FileStore, в журнал пишется весь объём данных, так что размер блока в реальности будет случайным, нужно попробовать разные размеры блока (от 4k до 4 MB) чтобы понять производительность журнала на различных операциях.

Неразобранное

SSD с (супер)конденсаторами позволяют успеть сбросить кэш во флеш-память при потере питания -- и просто игнорировать запросы fsync. Конденсаторы в описаниях обычно называются "enhanced/advanced power loss protection". Этой характеристикой часто обладают "серверные" SSD. Например, в Intel DC S3100 конденсаторов нет, а в Intel DC S4600 есть. Лучше SATA SSD с конденсаторами, чем NVMe без. Обычная NVMe будет точно так же тормозить при синхронизации.

hdparm, blkdiscard, smartctl (sata mode), CPU idlemode TODO: написать как интерпретировать результат. выставить шедулер диска. узнать юзает ли цеф пейджкеш (директ или нет) fsync vs fdatasync vs sync