Изменения

* Блюстор На HDD — блюстор всё время «едет на ручнике» из-за совершенно идиотской проблемы, которую я не далее чем вчера зарепортил сюда https://tracker.ceph.com/issues/38559 - при каждой записи в журнал RocksDB происходит дополнительная «ненужная» транзакция записи в журнал BlueFS, сводящаяся к обновлению размера лог-файла RocksDB. Теоретически это не нужно, так как RocksDB настроена с wal_recovery_mode=kTolerateCorruptedTailRecords и recycle_log_number=4. Но практически — видимов коде баг, гдеиз-то есть баг и это нужно, так как иначе за которого журнал при падении OSD его rocksdb ломаетсяэтом не sync-ается.** На HDD ускорение случайной записи при отключении этого поведения достигает 1глубине очереди 1 — двукратное.5-2 разПри глубине очереди 128 — почти нулевое.* Для серверных SSD число коммитов не важно, но важен WA — чем больше WA, тем больше работы приходится выполнять. А откуда WA?** Во-первых, тот же коммит BlueFS добавляет 4кб на каждую операцию.** Во-вторых, min_alloc_size на SSD по умолчанию — 16кб. Всё, что меньше, заполняется нулями — нулевые блоки добавляются к WA.** …а также min_alloc_size приводит к тому, что на SSD на самом деле тоже работает отложенная запись. Всё, что меньше min_alloc_size, сначала пишется На SSD — блюстор жёстко упирается в RocksDB, как CPU и на HDD. Отложенная запись порождает примерно 3x WA: блок+метаданные первый раз (размер блока WAL — 4кб) + блок второй раз.** Сами по себе метаданные толстоваты. Extent-ы хранятся не отдельными ключами, а списками размерами по умолчанию до 1200 байт. Правда, с учётом дефолтных min_alloc_size и max_blob_size на SSD (64K), на самом деле они меньше. Но это порождает обратную проблему — по идее, 4 Мб на SSD запишутся как 64*64Кб + 64 записи в RocksDBблокировки.