便捷Benchmark.sh自动匹配workload（自用）

​

因为db_bench选项太多，而测试纬度很难做到统一（可能一个memtable大小的配置都会导致测试出来的写性能相关的的数据差异很大），所以官方给出了一个benchmark.sh脚本用来对各个workload进行测试。 该脚本能够将db_bench测试结果中的stats信息进行统计汇总打印（qps,），更放方便查看。

这个测试需要将编译好的db_bench二进制文件和./tools/benchmark.sh放到同一个目录下, 直接跑 benchmark.sh 脚本就可以了(具体方式见下面详细命令)，测试项可以参考官方给出的workload，Performance Benchmarks

随机插入 bulkload，制造好数据集 这里的随机插入是指单纯的随机写，且禁掉自动compaction，将当前请求插入完成之后会再进行手动compaction

DB_DIR="./db" NUM_KEYS=900000000 NUM_THREADS=32 CACHE_SIZE=6442450944 benchmark.sh bulkload

总体来说这个随机插入结果相比于默认配置是偏高的，benchmark.sh中的脚本对memtable相关的配置如下：

很明显性能肯定好于默认配置，好处是官方有一个在指定硬件之下的workload测试结果，可以进行对比参考。

随机写，覆盖写 在上一次已有的数据基础上进行测试，会覆盖写9亿条key DB_DIR="./db" NUM_KEYS=900000000 NUM_THREADS=32 CACHE_SIZE=6442450944 DURATION=5400 benchmark.sh overwrite 读时写，9个线程读，一个线程写 这里的读是从已经存在的key中进行读 DB_DIR="./db" NUM_KEYS=900000000 NUM_THREADS=32 CACHE_SIZE=6442450944 DURATION=5400 benchmark.sh readwhilewriting 随机读 DB_DIR="./db" NUM_KEYS=900000000 NUM_THREADS=32 CACHE_SIZE=6442450944 DURATION=5400 benchmark.sh readrandom

1.随机写 单进程 32个线程，32个db，各自的写吞吐会以秒计形态输出到一个report.csv。这里线程数 和 db数可以根据自己环境的cpu核心情况而定，基本不用担心write-stall问题。

./db_bench \ --benchmarks=fillrandom,stats \ --readwritepercent=90 \ --num=3000000000 \ --threads=32 \ --db=./db \ --wal_dir=./db \ --duration=3600 \ -report_interval_seconds=1 \ --key_size=16 \ --value_size=128 \ --max_write_buffer_number=16 \ -max_background_compactions=32 \ -max_background_flushes=16 \ -subcompactions=8 \ -num_multi_db=32 \ -compression_type=none

如果想要支持 direct_io 写，可以打开 –use_direct_io_for_flush_and_compaction=true，这个配置是在写sst时 也就是flush & compaction 生效。 如果想要测试 mmap 写，则可以打开

--mmap_write=true

2 .完全随机读 随机读想要命中所有的key，需要打开 use_existing_db=1 和 use_existing_keys=1。 需要注意的是 use_existing_keys 开启之后不能直接读多db，只能读单个db，因为它会在真正执行读workload 之前从这一个db内scan 所有的key 到一个数组中，同时 配置的 --num 选项是失效的，这里会填充扫描上来的key的个数。 使用这个配置之后 worklaod 不会立即启动，会卡一会扫描完所有的key之后才真正开始随机读（读的过程是生成随机下标来进行访问）。

这个测试是使用默认大小的block_cache (8MB)，以及 开启bloom filter，因为我们是use_existing_keys，那bloom filter基本没什么用。

$DB_BENCH \ --benchmarks=readrandom,stats \ --num=3000000000 \ --threads=40 \ --db=./db \ --wal_dir=./db \ --duration="$DURATION" \ --statistics \ -report_interval_seconds=1 \ --key_size=16 \ --value_size=128 \ -use_existing_db=1 \ -use_existing_keys=1 \ -compression_type=none \

想要测试 direct 读，添加-use_direct_reads=true，那么读就不会用os pagecache了，这里可以搭配-cache_size=1073741824 以及其他block_cache的配置进行测试，来看rocksdb的block_cache 相比于os pagecache的收益。 想要测试 mmap 读，添加-mmap_read=true 即可。 3. 热点读 这里基本是使用之前的配置，主要是增加一个数据倾斜的配置 read_random_exp_range，它会用来产生倾斜的随机下标。 这个值越大，下标的倾斜越严重（可以理解为key-range 越小）。

$DB_BENCH \ --benchmarks=readrandom,stats \ --num=3000000000 \ --threads=40 \ --db=./db \ --wal_dir=./db \ --duration="$DURATION" \ --statistics \ -report_interval_seconds=1 \ --key_size=16 \ --value_size=128 \ -use_existing_db=1 \ -use_existing_keys=1 \ -compression_type=none \ -read_random_exp_range=0.8 \

以上所有的workload 最后的结果 可以通过 tail -f report.csv 查看 吞吐

secs_elapsed,interval_qps 1,3236083 2,2877314 3,2645623 4,2581939 5,2655481 6,2038635 7,2226018 8,2366941 ...

后面可以通过python 绘图脚本系列简单记录进行曲线绘图。