TiKV关键性能参数及优化

TiKV整体架构

 

主要关注三个模块:Transaction、Raft、 RocksDB

主要关注这三个模块的线程池

• scheduler Pool：协调事物的并发写入冲突，并将收到的修改操作向下写入；
• raftstore thread: 接收到写请求后，将写请求转化为raft 日志；raft日志会存入rocksdb raft中，并外传
• apply thread:  从rocksdb raft中的日志读出来，应用到rocksdb kv，从而完成数据的持久化

 

TiKV读写流程

 写请求从TiDB传入到scheduler pool，scheduler pool负责协调并发写入的冲突；如果有多个写请求要写同一个KEY或者遇到锁的时候，scheduler pool通过latch来进行排队，成功获得latch的可以继续往下走传递给raftstore pool，其他写请求继续等待；

 raftstore pool会将写请求转化为写日志raft log， raft log一边会落到raft主的rocksdb raft log，另外会发送给follower节点；

apply pool 会将raft log应用到本地的rocksdb kv，完成数据的持久化；

 按照上面流程图查看哪个部分的监控升高，如果哪个位置升高，就可以按照下面的图示调节对应的参数（适当调大）；

 store-pool-size: 默认处理raft的线程池数量，默认2；

store-max-bach-size: 默认每一批请求的rows数量,默认256

raft-max-inflight-msgs: 如果超过raft log写入等待的数量超过raft-max-inflight-msgs,就会减缓写入，进行限流；

apply-pool-size: 处理数据落盘的线程数；

apply-max-batch-size: 批量处理的请求个数；

TiKV读取流程

 点查流程：

 非点查流程

读取瓶颈分析 

 

 

 

 readpool.unified.max-thread-count: 读线程池

storage.block-cache.capacity: Block Cache的量，如果发现Block Cache 命中率较低，可以适当调大，该值一般占机器内存的45-60%

split.qps-threshold，默认3000

split.byte-threshold，默认30MB/s，达到该值的时候会默认将region打散，从而分散热点；

常见问题