主要关注三个模块:Transaction、Raft、 RocksDB
主要关注这三个模块的线程池
写请求从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: 批量处理的请求个数;
点查流程:
非点查流程
读取瓶颈分析
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打散,从而分散热点;
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/193247.html原文链接:https://javaforall.cn