bcachefs
patreon
Doing some pure btree performance tests
🕑 Added 2018-01-24 20:07:19 +0000 UTC I should have done this ages ago...bcachefs: btree_perf_test() doing 10.0M rand_insert:
bcachefs: btree_perf_test() done in 27 sec, 2587 nsec per iter, 377k per sec
bcachefs: btree_perf_test() doing 10.0M rand_lookup:
bcachefs: btree_perf_test() done in 10 sec, 1001 nsec per iter, 974k per sec
bcachefs: btree_perf_test() doing 10.0M seq_lookup:
bcachefs: btree_perf_test() done in 0 sec, 24 nsec per iter, 39.7M per sec
Comments
Kent Overstreet
This run was purely in memory (it was running in a VM with disks backed by a tmpfs). I've also run the same benchmarks using an older high end SSD (micron p320h) and the numbers were about the same. With slower devices, at some point either journal writes or btree writes will end up being a bottleneck - I'm not sure when though, I haven't tried tried it on slower devices yet.
Sorry if this is the wrong place to ask this, but I couldn't find a better one. Do you do most of your filesystem testing/benchmarking on an SSD? If so, which one do you use, and do you/will you do benchmarking/testing on a rotating rust drive too?
Kent Overstreet
These aren't hitting the SSD, since the data set is small enough to fit in memory. This doesn't translate to 1 million IOPS, since there's more work involved in a read request than just the btree lookup - but the btree lookup is the majority of the work. These numbers would be more comparable to benchmarking something like berkeleydb or leveldb or rocksdb - other key value store.
Sorry to noob out here, but I'm not quite sure how to interpret these benchmarks. Assuming they are actually hitting the ssd (and not a measure of the in-memory mechanics), does this mean 1 million IOPS? ... is there even an SSD capable of that? ... then these must be in-memory, no?
Kent Overstreet
bcachefs: btree_perf_test() doing 10.0M seq_insert: bcachefs: btree_perf_test() done in 11 sec, 1085 nsec per iter, 899k per sec
Curious about seq_insert...
