课程名称：课程版本（301）+ 3.7.7 TiKV optimization（TiKV Server 优化）
学习时长：
30分钟
课程收获：
掌握tikv 的读写处理过程和关键配置参数，可以根据监控的场景判断和挑战参数，来优化场景中遇到的问题
课程内容：
tikv架构
读写过程及参数优化
TIKV的模块和分层对应
通过 kv api 进行数据传递
每个模块都有对应的配置，可以进行参数修改，以此达到最佳的性能
数据通过过程参考了 Mysql 对于 redo 和undo log的设计思路，先落地为 Raft Log，然后确认存储到rocksDB 以后，在将数据推送至 apply 线程池，来执行实际的数据存储过程
在此过程中，如果apply失败，可以用过raft log 重新恢复到redo 的状态，重新加载后继续存储
其中有几个关键的配置参数
scheduler-worker-pool-size =4
store-pool-size =2
apply-pool-size = 2
以上的参数和图中描述的位置一致，可以优化并发执行的最大数，需要根据实际的场景进行调整
写过程的场景分析
- IO 和 CPU的性能是互斥的状态
- 提高IO的压缩级别，会增加CPU的消耗，但是会提高读写的速度
- rocksdb 失速了，但是 IO 和 cpu 都没有被占满
- too many level 0 files
- too many memtables
- too many pending bytes
[rocksdb]
how many threads for background jobs
max-backgroud-jobs = 8
thread for compacation of level0
max-sub-compacations = 3
[rocksdb.defaultcf] / [rocksdb.writecf]
compression-per-level = [“no”,“no”,“lz4”,“lz4”,“lz4”,“zstd”,“zstd”]
level0-file-num-compaction-trigger = 4
level0-slowdown-writes-trigger = 20
level0-stop-writes-trigger = 36
写入延迟比较重要的参数
- raftstore.raft-max-inflight-msgs
- raftstore.raft-max-size-per-msg
读的分析处理过程
配置参数
min-thread-count =4
80% * core number by default
max-thread-count = 4
如果读取的延迟很高，需要注意以下几个点
- too many large scan
- lmbalance
- thread pool is too small
- wrong query plan
另外一个很重要的配置
storage.block-cache.capacity 缓存的命中