recycle_log_file_num 復用wal文件信息， 優化wal文件的空間分配，減少pagecache中文件元信息的更新開銷。

為同事提供了一組rocksdb寫優化參數之后有一個疑惑的現象被問到，發現之前的一些代碼細節有遺忘情況，同時也發現了這個參數的一些小優化，這里做個總結。

在參數：

opts.recycle_log_file_num = 10;
opts.max_write_buffer_number = 16;
opts.write_buffer_size = 128 << 20;

大壓力寫下 出現了多個.log文件同時存在的現象，想要看看為什么會有這個現象。

在描述這個現象產生的原因之前我們先看看Rocksdb的wal創建以及清理過程，其中recycle_log_file_num是如何reuse log的

Rocksdb的WAL創建

如果不設置disable_memtable=true，不設置enable_pipelined_write=1，不disableWAL=1的話，基本的寫入調用棧如下：

JoinBatchGroup的邏輯這里暫不提及，從大體的寫入過程中各個文件的創建過程如下：

DBImpl::PreprocessWriteDBImpl::SwitchWALDBImpl::SwitchMemtableDBImpl::CreateWAL // 創建wal文件

在CreateWal文件的時候，Rocksdb會為這個wal創建一個PosixEnv下的文件句柄，以及文件名，并創建一個文件writer，用來后續的數據寫入。

如下代碼：

// 其中recycle_log_number 為當前想要復用的wal log文件名
// new_log 為需要在該函數中創建的writer，最后傳出來
// log_file_num 是創建的新的文件名，如果可回收的文件為0，則直接用新的就可以了。
IOStatus DBImpl::CreateWAL(uint64_t log_file_num, uint64_t recycle_log_number,size_t preallocate_block_size,log::Writer** new_log) {......// 根據文件num，創建新的文件名std::string log_fname =LogFileName(immutable_db_options_.wal_dir, log_file_num);// 如果有可回收的numer，則reuseif (recycle_log_number) {ROCKS_LOG_INFO(immutable_db_options_.info_log,"reusing log %" PRIu64 " from recycle list\n",recycle_log_number);std::string old_log_fname =LogFileName(immutable_db_options_.wal_dir, recycle_log_number);TEST_SYNC_POINT("DBImpl::CreateWAL:BeforeReuseWritableFile1");TEST_SYNC_POINT("DBImpl::CreateWAL:BeforeReuseWritableFile2");io_s = fs_->ReuseWritableFile(log_fname, old_log_fname, opt_file_options,&lfile, /*dbg=*/nullptr);} else {io_s = NewWritableFile(fs_.get(), log_fname, &lfile, opt_file_options);}if (io_s.ok()) {......// 創建一個file writerstd::unique_ptr<WritableFileWriter> file_writer(new WritableFileWriter(std::move(lfile), log_fname, opt_file_options,immutable_db_options_.clock, io_tracer_, nullptr /* stats */, listeners,nullptr, tmp_set.Contains(FileType::kWalFile)));*new_log = new log::Writer(std::move(file_writer), log_file_num,immutable_db_options_.recycle_log_file_num > 0,immutable_db_options_.manual_wal_flush);}return io_s;
}

其中ReuseWritableFile函數和NewWritableFile函數內部分別打開的是一個存在和不存在的文件，如果我們能夠reuse log文件名，則在ReuseWritableFile函數中通過open系統調用打開已存在文件的時候不需要創建新的dentry和inode，且不需要將這一些元數據更新到各自dcache/inode-cache中的相應hash表中，所以重用文件名這里的優化就體現在內核對文件的一些操作邏輯上。

關于open系統調用的內核邏輯，可以參考從unlink系統調用來看操作系統文件系統原理。

CreateWAL這個函數僅僅是用到了recycle_log_number，什么時候給recycle_log_number 賦值呢，可以由下向上遞推。

recycle_log_number 如何復用log

向上遞推 ，可以看到CreateWAL函數是在SwitchMemtable中被調用，recycle_log_number數值是從一個log_recycle_files_的deque中取出來的。

Status DBImpl::SwitchMemtable(ColumnFamilyData* cfd, WriteContext* context) {......// 從log_recycle_files_ 的頭端取出一個元素作為當前可回收的log numberuint64_t recycle_log_number = 0;if (creating_new_log && immutable_db_options_.recycle_log_file_num &&!log_recycle_files_.empty()) {recycle_log_number = log_recycle_files_.front();}......if (creating_new_log) {// TODO: Write buffer size passed in should be max of all CF's instead// of mutable_cf_options.write_buffer_size.io_s = CreateWAL(new_log_number, recycle_log_number, preallocate_block_size,&new_log);if (s.ok()) {s = io_s;}}

而log_recycle_files_ 這個deque則是在從活躍log deque alive_log_files_ 中取的。

在FindOnsoleteFiles函數中需要清理一些過期文件(log, sst, blob等)，針對一些過期的log進行回收，并添加到log_recycle_files_ 雙端隊列中。

其中recycle_log_file_num 表示能夠回收的log個數

  if (!alive_log_files_.empty() && !logs_.empty()) {uint64_t min_log_number = job_context->log_number;size_t num_alive_log_files = alive_log_files_.size();// find newly obsoleted log files// 從活躍log中取出沒有接受寫入數據的log，將這一部分log進行重用// min_log_number表示當前這個log 還在被持續更新。while (alive_log_files_.begin()->number < min_log_number) {auto& earliest = *alive_log_files_.begin();if (immutable_db_options_.recycle_log_file_num >log_recycle_files_.size()) {ROCKS_LOG_INFO(immutable_db_options_.info_log,"adding log %" PRIu64 " to recycle list\n",earliest.number);log_recycle_files_.push_back(earliest.number);} else {job_context->log_delete_files.push_back(earliest.number);

關于alive_log_files_這個變量的元素更新是在 打開db 和 SwitchMemtable 過程中進行更新的，這兩個部分會創建wal

在FindOnsoleteFiles函數中，構造好的job_context傳出即可。

清理WAL的調用棧如下（如果當前log被reuse,那就不會被清理了）

DBImpl::MaybeScheduleFlushOrCompaction // 調度compaction/flushDBImpl::BGWorkFlush // 從線程池調度flushDBImpl::BackgroundCallFlush DBImpl::FindObsoleteFiles // 構造好我們的job_context,其中包括需要清理的sst/blob/logDBImpl::PurgeObsoleteFiles // 執行清理

在清理函數中PurgeObsoleteFiles會決定是否需要keep log

    bool keep = true;switch (type) {case kWalFile:keep = ((number >= state.log_number) ||(number == state.prev_log_number) ||(log_recycle_files_set.find(number) !=log_recycle_files_set.end()));break;

如果發現log在log_recycle_files_set 我們之前回收的log列表中，則需要keep，也就不會執行后續的log文件刪除了。

總結

到此，我們就知道參數opts.recycle_log_file_num的完整作用了，回到開頭提到的現象，在開頭的配置下大并發寫rocksdb 會發現部分log文件可能存在的時間較長，且同時存在多個log 數目。

對于第一個問題 log存在的時間較長，即是由recycle_log_file_num 參數控制，它會不斷得復用一些過期(不接受寫入)的log，并且這一些log不會被回收。這個參數能夠提升log文件的復用，減少對文件元數據的操作，加速SwitchMemtable的過程。

對于第二個問題 log存在多個，則是由于max_write_buffer_number參數的問題，它允許同時存在多個memtable，如果寫入量較大，則imm 排隊flush，則這個過程中的imm 對應的log文件是不會清理的，而recycle_log_file_num 則會回收一些log_num，且讓這一些log不會被清理，所以會同時出先多個log_num。

需要注意的是recycle_log_file_num 這個參數回收的log不會被清理。

總結

以上是默认站点為你收集整理的Rocksdb 利用recycle_log_file_num 重用wal-log文件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得默认站点網站內容還不錯，歡迎將默认站点推薦給好友。