2.5.6 TiKV Tuning Guide（TiDB 的 TiKV 性能优化指南）
TiKV 性能优化路线
TiKV 体系架构
TiKV 存储层
- 关键组件：
- Transaction
- Raft 协议
- RocksDB
TiKV 模块
- Transaction → Scheduler Pool
- 写数据之前会先校验 ts，检测版本号是否比已经提交的数据大
- Raft 协议 → Raftstore thread
- RocksDB → Apply thread
性能问题定位
当出现性能问题，或系统缓慢的时候，查询监控系统中 TiDB 的 QPS 、 Duration 面板进行定位
- 正常情况下，99% 的 读延迟在 100ms
- 正常情况下，99% 的 写延迟在 500ms
判断性能问题在 TiKV 还是 TiDB 层
- KV Request QPS 面板
- KV Request Duration 99 by type 面板
写请求性能调优
理解两阶段提交的原理
- select … for update
- update … set …
- insert into …
- replace into …
- TiKV 事务层下层操作的总耗时
TiKV RaftStore 性能问题排查
- 表示TiKV transation 层开始向 raft 层写入数据，从 raft 接收数据到开始写入数据的时间
- 如果是 propose wait延迟高 ，可能是 磁盘性能太差 ，或者是 raft 线程数配置太小
- 表示 raftstore 线程的 leader、follower 达成一致，开始异步写入数据，到apply 线程接收到消息，准备真正的写入到底层存储引擎 RocksDB 的等待事件
- 如果是 Apply wait延迟高 ，可能是 apply 线程数参数配置太小
分析造成性能瓶颈的原因
- 查看 TiKV-server 的CPU使用率
如果 apply 线程延迟比较高，通常有四个原因
- apply 线程数量
- apply async CPU，如果使用达到线程池 80%，可以考虑增加 apply 线程数量
- 整机资源利用率太高导致 apply 现场争抢不到足够的 CPU 资源
- 通过 Server CPU进行判断
- 写入被 RocksDB 限流了
- TiKV 部署的磁盘性能太差
如果 raftstore 线程延迟比较高，通常有四个原因
- 线程 CPU 不足
- 心跳过于频繁，可以开启 hybridnet region？减少心跳数（4.0默认开启）
- 整个集群需要全部开启或全部关闭，否则可能出现大量无效的写心跳，影响网络和日志的收集
- 磁盘性能不好导致延迟过高
- disk performance 监控面板
- RocksDB 发生 Write Stall
Write Stall
- 内存中的 memory table 写满之后，会将数据写入 SST 文件中，如果写请求过多， 超过RocksDB 的能够处理请求的限制，就会发生 Write Stall
- Write Stall 是为了防止 RocksDB 的写放大太高，占用过多磁盘空间及IO性能
- 判断 RocksDB 是否处于 Write Stall 状态，查看 RocksDB 日志
- tikv/data/db/XXX.log
造成 Write Stall 的原因
- 过多的 Memory table 写入数据到 RocksDB 中
- 增加 Memory table 缓存预设数量
- 过多的 L0 层 文件（LSM-Tree），引起更多的写放大和 Compaction 的性能
- 增加 RocksDB 线程
- 过多等待 Compaction 的数据，compaction 速度达到极限
读请求性能调优
如果 Coprocessor 线程 CPU使用非常高
- RocksDB 删除过多被查询的数据
- 错误的执行计划导致过多的请求发送到 TiKV