RaftBatchSystem处理速度慢

🪐 TiDB 技术问题 部署&运维管理
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：v4.0.0
  • 【问题描述】：

在tikv原理解读文章中提到过

在 PeerStorage 的 handle_raft_ready 方法中，会将收集到 Ready 中的 Raft 日志收集到一个 WriteBatch 中，最终在 RaftPoller 的 end 方法中批量写入磁盘。

通过阅读源码我发现RaftPoller::end会跳转到RaftPoller::handle_raft_ready(peers)，而RaftPoller::handle_raft_ready又会向poll_ctx.raft_wb进行写盘操作（具体是这段代码）。有几个问题想请教下：

  • 这里raft_wb是负责处理raft消息的写盘操作吗？
  • 是通过raftstore.store-pool线程池来完成的吗？
  • 如果定位发现这部分的速度比较慢，可能的原因是什么呢

谢谢

1 个赞
2
  1. raft_wb 是 rocksdb 的 write batch，用于收集这一轮中处理 raft 消息之后需要写盘的操作
  2. 是的，这些操作都是 store 线程池中完成的
  3. 可能的原因较多，可以看 append log，propose wait，commit log 这几个监控，其中 append log 是一轮处理时间加上写 rocksdb 时间的总和，propose wait 是每个请求发给对应 region 之后得到处理的等待时间，commit log 是一条 proposal 被提出到确定被 commit 之后的时间，可以先看一下哪部分时间占比较大
3

感谢！看了下监控，发现commit log占用比例比较大(400-500ms)，propose wait大约100-150ms，append log在100ms左右。

请问这三项都是 store 线程池完成的吗？ store 线程池的源码大概在哪个文件呀？

4

可以提供一下 cpu 情况和网络情况，一个 raft propose 在 raft propose wait，append log & msg broadcast 之后就能 commit，commit 之后走一次 rocksdb 就能返回了。

5

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。