Levi Tamasi bd8404feff Do not schedule memtable trimming if there is no history (#6177)
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. Part of the issue
is that trimming can potentially be scheduled even if there is no memtable
history. The patch adds a check that fixes this.

See also https://github.com/facebook/rocksdb/pull/6169.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6177

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. There is a significant reduction for the call chain
`rocksdb::DBImpl::TrimMemtableHistory` -> `rocksdb::ColumnFamilyData::InstallSuperVersion` ->
`rocksdb::ThreadLocalPtr::StaticMeta::Scrape` even without https://github.com/facebook/rocksdb/pull/6169.

Differential Revision: D19057445

Pulled By: ltamasi

fbshipit-source-id: dff81882d7b280e17eda7d9b072a2d4882c50f79
2019-12-13 19:11:19 -08:00
..
2019-12-11 17:19:43 -08:00
2017-07-15 16:11:23 -07:00
2019-05-31 15:24:43 -07:00
2018-10-04 20:46:50 -07:00
2017-07-15 16:11:23 -07:00
2018-08-24 18:13:20 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2019-05-31 15:24:43 -07:00
2019-05-31 11:57:01 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00
2017-07-15 16:11:23 -07:00