При этом 4 ГБ — слишком мало, 286 ГБ — слишком много. Так что, по сути, правильно делать block.db размером хотя бы 30 ГБ для всех OSD.
'''Нюанс № 2:''' Бывает, Но что в момент compactionделать, если у вас разделы другого размера? Например, 80 ГБ, и вы по каким-а RocksDB требуется переписать уровень целиком (то причинам не всегдахотите делать bcache, но бывает)хотите использовать эти 80 ГБ по максимуму. Если при В этом случае можно поменять базовый размер уровня RocksDB (max_bytes_for_level_base). multiplier менять не будем, оставим по умолчанию 10 — его значение влияет на SSD нет запаса места в размере итоговое количество уровней RocksDB, а это уже более тонкая материя. Теоретически, меньшее число уровней снижает read и space amplification, но замедляет compaction и из-за этого уровняможет сильно повысить итоговый write amplification. Также есть тема с уменьшением размера отдельных memtable и кратным увеличением общего их числа, то онесть, опять-такинапример, утечёт на HDD и так там установки 32*32 МБ вместо дефолтных 4*256 МБ и останетсяmin_write_buffer_to_merge=8, ибо перемещать после но эффект от этого тоже не совсем понятен (возможно, немного экономится CPU при compaction-а его обратно она е), так что это тоже пока лучше не умеет. При этом одновременно могут компактиться как минимум первый и последний уровнитрогать.
Из этого следует, что Так как каждый уровень отличается от предыдущего в идеале на разделе 10 раз, общий размер раздела БД нужен ещё должен быть равен k*X, где k — коэффициенты из ряда: 1, 11, 111, 1111 и т. п. (по числу уровней RocksDB). Значит, мы можем взять размер нашего block.db, вычесть из него 1 ГБ WAL (лучше даже вычесть с запасом 2 ГБ) и делить его последовательно на каждую из цифр до тех пор, пока не получим значение, близкое к 256 МБ … 1 ГБ. Это значение округлить вниз, принять за базовый размер уровня RocksDB и запас прописать в размере конфиг как max_bytes_for_level_base. База компактится по 256 МБ за раз, так что меньше 256 МБ размер первого + последнего уровня БДставить точно смысла нет. То есть примерно 30 Например, для 80 ГБ превращаются раздела это будет 719 МБ, только не забываем считать всё в примерно 60двоичных мегабайтах — MiB. Остаётся прописать это значение в конфигурацию (bluestore_rocksdb_options = …,max_bytes_for_level_base=719MB), перезапустить OSD и сделать ручной compaction (можно дважды).
Но что делать, если вам надо выделить под базы, например, по 50 ГБ? Делать SSD разделы по 550 ГБ как'''Нюанс № 2:''' При ручном compaction-то уж очень жирно, но и спилловеров иметь не хочетсяе RocksDB переписывает уровни целиком. В Если при этом случае можно поменять базовый размер уровня RocksDB (max_bytes_for_level_base). multiplier менять не будем, оставим по умолчанию 10 — его значение влияет на итоговое количество уровней RocksDB, а это уже более тонкая материя. Теоретически, меньшее число уровней снижает read и space amplification, но замедляет compaction и из-за SSD нет запаса места в размере этого может сильно повысить итоговый write amplification. Также есть тема с уменьшением размера отдельных memtable и кратным увеличением общего их числауровня, то естьуровень, напримеропять-таки, установки 32*32 МБ вместо дефолтных 4*256 МБ утечёт на HDD и min_write_buffer_to_merge=8так там и останется, но эффект от этого тоже не совсем понятен (возможно, немного экономится CPU при ибо перемещать после compaction-е), так что это тоже пока лучше а его обратно она не трогатьумеет. ИтакТеоретически, помня про необходимость запаса под первый и последний уровни выводимесли после этого сделать compaction ещё раз, что общий размер раздела БД то уровень должен быть равен k*X, где X — размер первого уровня, а k — коэффициенты из ряда: 2 вернуться на SSD (1 уровеньпоэтому выше дана рекомендация делать ручной compaction дважды), 22 (2 уровня), 212 (под 3 уровня), 2112 (под 4 уровня) и т. п. СоответственноОднако по сведениям из чата якобы бывает так, берём целевой максимальный размер нашей БД: 50 ГБчто один-два файла *. Это будет размер последнего уровняsst на SSD не возвращается. Делим его Чтобы это побороть на 10 до тех пор100 %, пока значение не приблизится гдеможно предусмотреть на SSD-то к гигабайту разделе ещё и принимаем это за размер запас в размере первого уровня. Компактится база по 256 МБ за раз, так что меньше 256 МБ размер первого уровня ставить точно смысла нет. После этого число делений+1 принимаем за число уровней, домножаем размер первого последнего уровня на соответствующий коэффициент, накидываем +1 ГБ для WAL, округляем чуть вверх и получаем необходимый размер раздела SSDБД. В этом случае с 50 ГБ — размер первого уровня будет 500 МБ, число уровней 3 и требуемый размер SSD раздела — около 106 ГБ. Прописываем это коэффициенты вместо 1-11-111-1111 превращаются в конфигурацию (bluestore_rocksdb_options = …,max_bytes_for_level_base=500MB), деплоим OSD и радуемся жизни2-22-212-2112 и т. п. Ну, почти радуемся, так как 50 % этого раздела у нас используется только в момент компакшена, а остальное время простаивает…
== Снапшоты ==
