This has benchmark results for RocksDB using a big (48-core) server. I ran tests to document the impact of the the block cache type (LRU vs hyperclock) and a few other configuration choices for a CPU-bound workload. A previous post with great results for the hyperclock block cache is here.
tl;dr
- read QPS is up to ~3X better with auto_hyper_clock_cache vs LRU
- read QPS is up to ~1.3X better with the per-level fanout set to 32 vs 8
- read QPS drops by ~15% as the background write rate increases from 2 to 32 M/s
Software
I used RocksDB 9.6, compiled with gcc 11.4.0.
Hardware
The server is an ax162-s from Hetzner with an AMD EPYC 9454P processor, 48 cores, AMD SMT disabled and 128G RAM. The OS is Ubuntu 22.04. Storage is 2 NVMe devices with SW RAID 1 and ext4.
Benchmark
Overviews on how I use db_bench are here and here.
All of my tests here use a CPU-bound workload with a database that is cached by RocksDB and are repeated for 1, 10, 20 and 40 threads.
I focus on the readwhilewriting benchmark where performance is reported for the reads (point queries) while there is a fixed rate for writes done in the background. I prefer to measure read performance when there are concurrent writes because read-only benchmarks with an LSM suffer from non-determinism as the state (shape) of the LSM tree has a large impact on CPU overhead and throughput.
To save time I did not run the fwdrangewhilewriting benchmark. Were I to repeat this work I would include it because the results from it would be interesting for a few of the configuration options I compared.
I did tests to understand the following:
- LRU vs auto_hyper_clock_cache for the block cache implementation
- LRU is the original implementation. The code was simple, which is nice. The implementation for LRU is sharded with a mutex per shard and that mutex can become a hot spot. The hyperclock implementation is much better at avoiding hot spots.
- per level fanout (8 vs 32)
- By per level fanout I mean the value of --max_bytes_for_level_multiplier which determines the target size difference between adjacent levels. By default I use 8, while 10 is also a common choice. Here I compare 8 vs 32. When the fanout is larger the LSM tree has fewer levels -- meaning there are fewer places to check for data which should reduce CPU overhead and increase QPS.
- background write rate
- I repeated tests with the background write rate (--benchmark_write_rate_limit) set to 2, 8 and 32 MB/s. With a higher write rate there is more chance for interference between reads and writes. The interference might be from mutex contention, compaction threads using more CPU, more L0 files to check or more data in levels L1 and larger.
- target size for L0
- By target size I mean the number of files in the L0 that trigger compaction. The db_bench option for this is --level0_file_num_compaction_trigger. When the value is larger there will be more L0 files on average that a query might have to check and that means there is more CPU overhead. Unfortunately, I configured RocksDB incorrectly so I don't have results to share. The issue is that when the L0 is configured to be larger, the L1 should be configured to be at least as large as the L0 (L1 target size should be >= sizeof(SST) * num(L0 files). If not, then L0->L1 compaction will happen sooner than expected.
Results: LRU vs auto_hyper_clock_cache
These graphs have QPS from the readwhilewriting benchmark for the LRU and AHCC block cache implementations where LRU is the original version with a sharded hash table and a mutex per shard while AHCC is the hyper clock cache (--cache_type=auto_hyper_clock_cache).
Summary:
- QPS is much better with AHCC than LRU (~3.3X faster at 40 threads)
- QPS with AHCC scales linearly with the thread count
- QPS with LRU does not scale linearly and suffers from mutex contention
- There are some odd effects in the results for 1 thread
With a 2M/s background write rate AHCC is ~1.1X faster at 1 thread and ~3.3X faster at 40 threads relative to LRU.
With an 8M/s background write rate AHCC is ~1.1X faster at 1 thread and ~3.3X faster at 40 threads relative to LRU.
With a 32M/s background write rate AHCC is ~1.1X faster at 1 thread and ~2.9X faster at 40 threads relative to LRU.
Results: per level fanout
These graphs have QPS from the readwhilewriting benchmark to compare results with per-level fanout set to 8 and 32.
Summary
- QPS is often 1.1X to 1.3X larger with fanout=32 vs fanout=8
With an 8M/s background write rate and LRU, fanout=8 is faster at 1 thread but then fanout=32 is from 1.1X to 1.3X faster at 10 to 40 threads.
With an 8M/s background write rate and AHCC, fanout=8 is faster at 1 thread but then fanout=32 is ~1.1X faster at 10 to 40 threads.
With a 32M/s background write rate and LRU, fanout=8 is ~2X faster at 1 thread but then fanout=32 is from 1.1X to 1.2X faster at 10 to 40 threads.
With a 32M/s background write rate and AHCC, fanout=8 is ~2X faster at 1 thread but then fanout=32 is ~1.1X faster at 10 to 40 threads.
Results: background write rate
Summary:
- With LRU
- QPS drops by up to ~15% as the background write rate grows from 2M/s to 32M/s
- QPS does not scale linearly and suffers from mutex contention
- With AHCC
- QPS drops by up to 13% as the background write rate grows from 2M/s to 32M/s
- QPS scales linearly with the thread count
- There are some odd effects in the results for 1 thread
Results with LRU show that per-thread QPS doesn't scale linearly
Results with AHCC show that per-thread QPS scales linearly ignoring the odd results for 1 thread
by Mark Callaghan (noreply@blogger.com)
.png){kind=link}
%20(1).png){kind=link}
.png){kind=link}
%20(1).png){kind=link}
.png){kind=link}
%20(1).png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}
=4.png){kind=link}