【 TiDB 使用环境】
测试环境
【概述】 场景 + 问题概述
100亿行的表,以insert on duplicatekey的方式插入数据,一个 insert 插入2万行记录,开20个并发,发现 tidb 日志里大量的tikv server is busy的错误,显示是 scheduler is busy,insert 耗时很高50s左右,但是查看系统资源发现CPU、IO都不是很高。
【TiDB 版本】
4.0.10
通过监控分析如下,但是没有找到真正问题在哪:
【 TiDB 使用环境】
测试环境
【概述】 场景 + 问题概述
100亿行的表,以insert on duplicatekey的方式插入数据,一个 insert 插入2万行记录,开20个并发,发现 tidb 日志里大量的tikv server is busy的错误,显示是 scheduler is busy,insert 耗时很高50s左右,但是查看系统资源发现CPU、IO都不是很高。
【TiDB 版本】
4.0.10
通过监控分析如下,但是没有找到真正问题在哪:
https://book.tidb.io/session4/chapter7/tikv-is-busy.html
https://docs.pingcap.com/zh/tidb/stable/tidb-troubleshooting-map
先按照这个文档排查一下,因为是 scheduler is busy 报错。
上面分析的结论中有:
可以提供一下 TiKV- details 监控吗 ?我们一起看一下? 通过你的描述,还是有一些问题需要确认;通过导出工具导出一下这个时间段的监控,https://metricstool.pingcap.com/#backup-with-dev-tools
另外通过 Dashboard 取一下在进行批量 insert 过程中的火焰图
resource-cluster-TiKV-Details_2021-09-06T09_44_04.533Z.json.zip (1.7 MB) 目前有监控图,可以先帮忙分析下监控指标吗,现在拿火焰图不是很方便
有个疑问,raft 耗时最大是在 apply wait duration 吧, io 应该不是最大的因素才对(而且 store-pool-size=3,apply-pool-size=3, CPU 使用率都在 150%左右,raftstore.apply-max-batch-size=1024,是什么导致了 apply wait duration 高?应该怎么排查呢)
每台TiKV服务器3块SSD,水平都差不多:
fio Pass IOPS of random read: 66534.010152
fio Pass IOPS of random read: 17758.630063, write: 17868.442512
fio Pass Latency of random read: 156743.568944ns, write: 25442.079436ns
permission Pass /mnt/disk5/tikv/deploy/data is writable
fio Pass IOPS of random read: 66500.253678
fio Pass IOPS of random read: 17380.686353, write: 17488.161745
fio Pass Latency of random read: 154928.353020ns, write: 24432.604653ns
permission Pass /mnt/disk6/tikv/deploy/data is writable
fio Pass IOPS of random read: 52660.506227
fio Pass IOPS of random read: 13847.816872, write: 13933.446376
fio Pass Latency of random read: 226612.086089ns, write: 24528.027354ns
permission Pass /mnt/disk4/tikv/deploy/da
另外调整:apply-pool-size=4,raftstore.apply-max-batch-size=2048 重新测试后,发现:
transaction duration 下降到 30s 左右:
主要耗时在 batch_get 和 coprocessor(和grpc duration显示一致,另外 scheduduler priwrite duration 和 aysync write duration 都较低):
coprocessor detail → 95% handle duration by store 显示所有 TiKV 节点的 analyze_table 最大16s,每个节点的线都不连续:
不过 coprocessor overview 中看起来 ops 和耗时都很低:
请问这个情况应该如何判断?可以看出原因吗?
你好,从上面上传的 tikv-details 监控看像是有 2 个问题:
一个是 tombstone 导致 batch get 和 get 慢,也会影响 prewrite 的整体延迟,这个问题在 v4.0.12 有相关专门的优化,可以考虑升级到 v4.0 最新版本。
另外一个是 apply 处理似乎有堆积,调大 apply-pool-size 之后可以对比一下 apply wait 的情况,从上面描述看起来 async write duration p99 下降了挺多。堆积的原因是否业务模型有写入热点,可以结合 tidb 和 pd 的监控再看看。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。