You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I run db_bench --benchmarks=fillseq --num_multi_db=X then I want it to run as fast as possible, which means it should minimize the time when IO is not in progress. But today, the DoWrite method does this:
Select an id from 0 to (num_multi_db-1)
Use the key generator for that the db with that id
The problem with this is that the write buffers for all databases become full around the same point in time, they will then flush around the same point in time and there will be IO stalls. One way to avoid that is to first load all keys for the db with id 1, then id 2 and so on.
From one example with 256M write buffer and num_multi_db=150 there is no IO for 8 minutes then there is ~30G of IO in a burst, repeat.
The text was updated successfully, but these errors were encountered:
A minor issue related to this, after running fillseq with --num_multi_db it is unlikely that all databases get --num keys. Some will have more, some will have less. This can be a source of confusion when you run a test like readrandom and expect all lookups to return a value.
mdcallag
added a commit
to mdcallag/rocksdb-1
that referenced
this issue
Mar 18, 2022
…in order
Summary:
This fixesfacebook#9650
For db_bench --benchmarks=fillseq --num_multi_db=X it loads databases in sequence
rather than randomly choosing a database per Put. The benefits are:
1) avoids long delays between flushing memtables
2) avoids flushing memtables for all of them at the same point in time
3) puts same number of keys per database so that query tests will find keys as expected
Test Plan:
Using db_bench.1 without the change and db_bench.2 with the change:
for i in 1 2; do rm -rf /data/m/rx/* ; time ./db_bench.$i --db=/data/m/rx --benchmarks=fillseq --num_multi_db=4 --num=10000000; du -hs /data/m/rx ; done
--- without the change
fillseq : 3.188 micros/op 313682 ops/sec; 34.7 MB/s
real 2m7.787s
user 1m52.776s
sys 0m46.549s
2.7G /data/m/rx
--- with the change
fillseq : 3.149 micros/op 317563 ops/sec; 35.1 MB/s
real 2m6.196s
user 1m51.482s
sys 0m46.003s
2.7G /data/m/rx
Also, temporarily added a printf to confirm that the code switches to the next database at the right time
ZZ switch to db 1 at 10000000
ZZ switch to db 2 at 20000000
ZZ switch to db 3 at 30000000
for i in 1 2; do rm -rf /data/m/rx/* ; time ./db_bench.$i --db=/data/m/rx --benchmarks=fillseq,readrandom --num_multi_db=4 --num=100000; du -hs /data/m/rx ; done
--- without the change, smaller database, note that not all keys are found by readrandom because databases have < and > --num keys
fillseq : 3.176 micros/op 314805 ops/sec; 34.8 MB/s
readrandom : 1.913 micros/op 522616 ops/sec; 57.7 MB/s (99873 of 100000 found)
--- with the change, smaller database, note that all keys are found by readrandom
fillseq : 3.110 micros/op 321566 ops/sec; 35.6 MB/s
readrandom : 1.714 micros/op 583257 ops/sec; 64.5 MB/s (100000 of 100000 found)
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
When I run db_bench --benchmarks=fillseq --num_multi_db=X then I want it to run as fast as possible, which means it should minimize the time when IO is not in progress. But today, the DoWrite method does this:
Much of the code is here.
The problem with this is that the write buffers for all databases become full around the same point in time, they will then flush around the same point in time and there will be IO stalls. One way to avoid that is to first load all keys for the db with id 1, then id 2 and so on.
From one example with 256M write buffer and num_multi_db=150 there is no IO for 8 minutes then there is ~30G of IO in a burst, repeat.
The text was updated successfully, but these errors were encountered: