6d54eb3dc2
Summary: We have observed an increase in CPU load caused by frequent calls to `ColumnFamilyData::InstallSuperVersion` from `DBImpl::TrimMemtableHistory` when using `max_write_buffer_size_to_maintain` to limit the amount of memtable history maintained for transaction conflict checking. As it turns out, this is caused by the code creating and installing a new `SuperVersion` even if no memtables were actually trimmed. The patch adds a check to avoid this. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6169 Test Plan: Compared `perf` output for ``` ./db_bench -benchmarks=randomtransaction -optimistic_transaction_db=1 -statistics -stats_interval_seconds=1 -duration=90 -num=500000 --max_write_buffer_size_to_maintain=16000000 --transaction_set_snapshot=1 --threads=32 ``` before and after the change. With the fix, the call chain `rocksdb::DBImpl::TrimMemtableHistory` -> `rocksdb::ColumnFamilyData::InstallSuperVersion` -> `rocksdb::ThreadLocalPtr::StaticMeta::Scrape` no longer registers in the `perf` report. Differential Revision: D19031509 Pulled By: ltamasi fbshipit-source-id: 02686fce594e5b50eba0710e4b28a9b808c8aa20 |
||
|---|---|---|
| .. | ||
| db_impl_compaction_flush.cc | ||
| db_impl_debug.cc | ||
| db_impl_experimental.cc | ||
| db_impl_files.cc | ||
| db_impl_open.cc | ||
| db_impl_readonly.cc | ||
| db_impl_readonly.h | ||
| db_impl_secondary.cc | ||
| db_impl_secondary.h | ||
| db_impl_write.cc | ||
| db_impl.cc | ||
| db_impl.h | ||
| db_secondary_test.cc | ||