Изменения

Нюанс № 2: В Бывает, что в момент compaction-а RocksDB часто требуется целиком переписать уровень целиком(не всегда, но бывает). Если при этом на SSD нет запаса места в размере этого уровня, то он, опять-таки, утечёт на HDD и так там и останется, ибо перемещать после compaction-а его обратно она не умеет. При этом одновременно могут компактиться как минимум первый и последний уровни.

Из этого следует, что, по идее, в идеале на разделе БД нужен ещё и запас в размере первого + последнего уровня БД. То есть примерно 30 ГБ превращаются в примерно 60.

Но что делать, если сами вам надо выделить под базы у вас размером, скажем, по 30 ГБ? Выделять на Делать SSD раздел разделы по 550 ГБ как-то уж очень жирно, но и спилловеров иметь не хочется. В этом случае можно поменять базовый размер уровня RocksDB (max_bytes_for_level_base). multiplier менять не будем, оставим по умолчанию 10 — его значение влияет на итоговое количество уровней RocksDB, а это уже более тонкая материя. Теоретически, меньшее число уровней снижает read и space amplification, но замедляет compaction и из-за этого может сильно повысить итоговый write amplification. Также есть тема с уменьшением размера отдельных memtable и кратным увеличением общего их числа, то есть, например, установки 32*32 МБ вместо дефолтных 4*256 МБ и min_write_buffer_to_merge=8, но эффект от этого тоже не совсем понятен (возможно, немного экономится CPU при compaction-е), так что это тоже пока лучше не трогать.