recycle_log_file_num 復(fù)用wal文件信息， 優(yōu)化wal文件的空間分配，減少pagecache中文件元信息的更新開銷。

為同事提供了一組rocksdb寫優(yōu)化參數(shù)之后有一個疑惑的現(xiàn)象被問到，發(fā)現(xiàn)之前的一些代碼細節(jié)有遺忘情況，同時也發(fā)現(xiàn)了這個參數(shù)的一些小優(yōu)化，這里做個總結(jié)。

在參數(shù)：

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

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

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

Rocksdb的WAL創(chuàng)建

如果不設(shè)置disable_memtable=true，不設(shè)置enable_pipelined_write=1，不disableWAL=1的話，基本的寫入調(diào)用棧如下：

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

DBImpl::PreprocessWriteDBImpl::SwitchWALDBImpl::SwitchMemtableDBImpl::CreateWAL // 創(chuàng)建wal文件

在CreateWal文件的時候，Rocksdb會為這個wal創(chuàng)建一個PosixEnv下的文件句柄，以及文件名，并創(chuàng)建一個文件writer，用來后續(xù)的數(shù)據(jù)寫入。

如下代碼：

// 其中recycle_log_number 為當(dāng)前想要復(fù)用的wal log文件名
// new_log 為需要在該函數(shù)中創(chuàng)建的writer，最后傳出來
// log_file_num 是創(chuàng)建的新的文件名，如果可回收的文件為0，則直接用新的就可以了。
IOStatus DBImpl::CreateWAL(uint64_t log_file_num, uint64_t recycle_log_number,size_t preallocate_block_size,log::Writer** new_log) {......// 根據(jù)文件num，創(chuàng)建新的文件名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()) {......// 創(chuàng)建一個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函數(shù)和NewWritableFile函數(shù)內(nèi)部分別打開的是一個存在和不存在的文件，如果我們能夠reuse log文件名，則在ReuseWritableFile函數(shù)中通過open系統(tǒng)調(diào)用打開已存在文件的時候不需要創(chuàng)建新的dentry和inode，且不需要將這一些元數(shù)據(jù)更新到各自dcache/inode-cache中的相應(yīng)hash表中，所以重用文件名這里的優(yōu)化就體現(xiàn)在內(nèi)核對文件的一些操作邏輯上。

關(guān)于open系統(tǒng)調(diào)用的內(nèi)核邏輯，可以參考從unlink系統(tǒng)調(diào)用來看操作系統(tǒng)文件系統(tǒng)原理。

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

recycle_log_number 如何復(fù)用log

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

Status DBImpl::SwitchMemtable(ColumnFamilyData* cfd, WriteContext* context) {......// 從log_recycle_files_ 的頭端取出一個元素作為當(dāng)前可回收的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函數(shù)中需要清理一些過期文件(log, sst, blob等)，針對一些過期的log進行回收，并添加到log_recycle_files_ 雙端隊列中。

其中recycle_log_file_num 表示能夠回收的log個數(shù)

  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中取出沒有接受寫入數(shù)據(jù)的log，將這一部分log進行重用// min_log_number表示當(dāng)前這個log 還在被持續(xù)更新。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);

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

在FindOnsoleteFiles函數(shù)中，構(gòu)造好的job_context傳出即可。

清理WAL的調(diào)用棧如下（如果當(dāng)前l(fā)og被reuse,那就不會被清理了）

DBImpl::MaybeScheduleFlushOrCompaction // 調(diào)度compaction/flushDBImpl::BGWorkFlush // 從線程池調(diào)度flushDBImpl::BackgroundCallFlush DBImpl::FindObsoleteFiles // 構(gòu)造好我們的job_context,其中包括需要清理的sst/blob/logDBImpl::PurgeObsoleteFiles // 執(zhí)行清理

在清理函數(shù)中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;

如果發(fā)現(xiàn)log在log_recycle_files_set 我們之前回收的log列表中，則需要keep，也就不會執(zhí)行后續(xù)的log文件刪除了。

總結(jié)

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的Rocksdb 利用recycle_log_file_num 重用wal-log文件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。