Изменения

Сама запись на устройство При этом оптимизацией транзакций там, похоже, вообще никто нормально не занимался и репликация с других поэтому при работе OSD происходит отложенно и асинхронноsync-ов не то что столько же, но какая разница — она все равно создаёт дополнительную нагрузку на устройства и притормаживает последующие запросысколько запросов записи — их даже БОЛЬШЕ (смешно, да). В таких условиях «deferred» операции превращаются не в deferred, а непонятно во что, поэтому понятия «асинхронности» там фактически никакого нет.

Всё это приводит к тому, что типичная настольная SSD-шка в Ceph выдаёт '''неприлично низкие IOPS-ы''' — обычно от 500 до 2000. И это при том, что при обычном тестировании почти любая SSD выдаёт > 20000 iops. Даже самый паршивый китайский noname выдаёт не менее 10000 iops. NVMe легко выжимает 150000 и больше. Но стоит начать использовать fsync… и та же NVMe выдаёт 600 iops (на 2.5 порядка меньше).

{{Box|1={{Note}} Старый FileStore на плохих дисках быстрее BlueStore где-то в 1.5 раза. На хороших FileStore менее латентный; хорошие он лучше утилизирует в один поток, то есть, даёт больше iops в один поток (у него меньше задержки). Но это не значит, что его надо использовать — по остальным параметрам FileStore устарел. Например, снапшоты там работают со скоростью снапшотов LVM (очень медленно), нет частичной перезаписи объектов в EC-пулах, нет контрольных сумм (вследствие чего вообще нельзя использовать size=2). Также CPU filestore жрёт сильнее и пиковые параллельные IOPS-ы у него хуже bluestore.}}

В общем, чтобы понять, сколько у вас будет IOPS-ов на запись в Ceph, диски под него нужно тестировать с опцией fio '''fsyncfdatasync=1'''. Или fdatasyncЛибо можно fsync=1, если тестируете но в файле поверх ФС. Или будут различия, либо можно sync=1 iodepth=1, эффект обычно 1 — почти тот то жесамое, что от fsync=1но чуть с другого бока. Разница между опциями (см. man fio):