便捷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 绘图脚本系列简单记录进行曲线绘图。