Doing some pure btree performance tests
Added 2018-01-24 20:07:19 +0000 UTCI 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
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.
Kent Overstreet
2018-02-08 22:32:10 +0000 UTCSorry 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?
2018-02-08 21:24:05 +0000 UTCThese 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.
Kent Overstreet
2018-01-25 16:58:54 +0000 UTCSorry 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?
2018-01-25 07:34:03 +0000 UTCbcachefs: btree_perf_test() doing 10.0M seq_insert: bcachefs: btree_perf_test() done in 11 sec, 1085 nsec per iter, 899k per sec
Kent Overstreet
2018-01-24 22:50:24 +0000 UTC
