Это может произойти в двух случаях:
1) Rocksdb сохраняет данные в памяти через файлы WAL и удаляется при сбросе памяти.Если у вас есть несколько семейств столбцов, где некоторые из них имеют более высокую скорость вставки (заполняемая память быстрее), а другие имеют более низкую скорость, .log files (файлы WALDSD-файлов) не могут быть удалены.Это связано с тем, что файлы wal содержат транзакции из всех семейств столбцов и не могут быть удалены до тех пор, пока все семейства столбцов не будут сохранены с помощью сброса.Это может привести к застойным файлам .log, что приведет к проблемам с дисковым пространством.
2) Предположим, что размер записываемого файла настроен на 1 ГБ, а количество записываемых файлов для слияния равно 3, вы фактически ждете 3 заполняемых памятных стола.и тогда срабатывает сброс.Даже если вы настроили целевой размер файла (так как вы упомянули, что ваши SST-файлы составляют около 40 МБ) на 50 МБ, вы сгенерируете 185 SST-файлов каждый размером 50 МБ общим объемом 3 ГБ.Но у вас есть место около 650 МБ, что может быть проблемой.
Существуют различные параметры, которые влияют на поведение сброса в rocksdb.Вы можете взглянуть на,
write_buffer_size - Размер каждой записываемой таблицы.
min_write_buffer_number_to_merge - Количество записываемых записей, которые нужно объединить во время сброса или, другими словами, когда количество неизменяемых памятных записейстановится равным этому значению, выполните сброс на диск.
target_file_size_base - размер результирующих SST из-за сжатия или сброса.
target_file_size_multiplier - определяет размер SST на каждом уровне.
Вы также можете взглянуть на методы сжатия SST.Дайте мне знать, если это поможет.