Как стать автором
Обновить

Комментарии 4

Предположим, что спрашиваю для друга, который недавно тестировал CEPH, который 3х кратное резервирование делает для нагрузки, специфичной для баз данных, которые работают поверх файловых систем, например PG, которые ждут подтверждения записи на запись в разных вариантах, lvm, mbraid, даже bcache и сравнивал с nvme over tcp

друг спрашивает, а на каких таких параметрах для fio были достигнуты такие гарантированные IOPS

друг понимает, что разные производители NVME за фасадом CEPH могут давать разброс в пару раз по этим самым IOPS, но чтобы просто так взять и гарантировать...

гарантировать что?

Добрый день! Указанные значения — это лимиты по производительности, которые установлены для разных типов сетевых дисков. Подробнее они перечислены в таблице.

Конфигурации для fio, включая размер блока и глубину очереди, которые используются для тестирования производительности, перечислены в документации.

Гугление показывает что в конфигах глуюина записи сильно больше 1.

[writetest]
size=2000M
blocksize=4k
filename=/dev/sdb
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32

А согласно табличкам моего друга

параметр глубины - сильно оказывает влияние на полученые иопсы

Примерн так (нелинейно, но близко)

randwrite

1

Depth: 1 - Device: /dev/md0

write: IOPS=549, BW=4397KiB/s (4503kB/s)(1288MiB/300001msec); 0 zone resets

16

Depth: 16 - Device: /dev/md0

write: IOPS=8026, BW=62.7MiB/s (65.8MB/s)(18.4GiB/300007msec); 0 zone resets

Может быть я и не ту табличку нашел, но в статье методики измерений не было

Добрый день! Как всегда бывает при измерении производительности дисковой системы, важно понимать что мы измеряем и для чего. При глубине очереди равной единице, мы фактически отключаем любой параллелизм в сторону СХД, операции выполняются последовательно, а на результат очень сильно будут влиять сетевые задержки. Достигнуть насыщения, нащупать предел производительности сетевого диска и использовать QD=1 это, пожалуй, не самая интересная комбинация.

IOPS будут отличаться при разной глубине очереди. Сравнивать только IOPS при разных вводных (целевой latency, размер блока, соотношение read/write) тоже не имеет практического смысла. А так как со стороны прикладных приложений нагрузка тоже категорически различается, то приходим к выводу о том вариативность тестов и возможных результатов стремится к бесконечности.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий