批量 insert 慢 & tikv server is busy

【 TiDB 使用环境】
测试环境

【概述】 场景 + 问题概述
100亿行的表,以insert on duplicatekey的方式插入数据,一个 insert 插入2万行记录,开20个并发,发现 tidb 日志里大量的tikv server is busy的错误,显示是 scheduler is busy,insert 耗时很高50s左右,但是查看系统资源发现CPU、IO都不是很高。

【TiDB 版本】
4.0.10

通过监控分析如下,但是没有找到真正问题在哪:


2 个赞

https://book.tidb.io/session4/chapter7/tikv-is-busy.html

https://docs.pingcap.com/zh/tidb/stable/tidb-troubleshooting-map

先按照这个文档排查一下,因为是 scheduler is busy 报错。

2 个赞

上面分析的结论中有:

  1. 没有 write stall
  2. 没有 latch
  3. cheduler writing bytes 最大20M,应该不是 scheduler-pending-write-threshold 瓶颈
  4. 各线程池 CPU 使用率没满
  5. append log duration:90ms 以内
1 个赞

可以提供一下 TiKV- details 监控吗 ?我们一起看一下? 通过你的描述,还是有一些问题需要确认;通过导出工具导出一下这个时间段的监控,https://metricstool.pingcap.com/#backup-with-dev-tools

另外通过 Dashboard 取一下在进行批量 insert 过程中的火焰图

1 个赞

resource-cluster-TiKV-Details_2021-09-06T09_44_04.533Z.json.zip (1.7 MB) 目前有监控图,可以先帮忙分析下监控指标吗,现在拿火焰图不是很方便

1 个赞

落盘延迟很高,这个对写入性能影响比较高。建议检查一下 Disk 监控,是否按照官网提供的磁盘类型是否相符。

1 个赞

有个疑问,raft 耗时最大是在 apply wait duration 吧, io 应该不是最大的因素才对(而且 store-pool-size=3,apply-pool-size=3, CPU 使用率都在 150%左右,raftstore.apply-max-batch-size=1024,是什么导致了 apply wait duration 高?应该怎么排查呢)

  • propose wait duration:100-400ms
  • append log duration:90ms 以内
  • commit log duration:最大1s
  • apply wait duration:3-8s
  • apply log duration:最大1s
1 个赞

磁盘 io 看起来延迟很低:

1 个赞

Latency 延迟有点高,这块建议通过 fio 检查一下磁盘性能是否达标,可以通过 TiUP check 检查一下。

1 个赞

每台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 重新测试后,发现:

  1. transaction duration 下降到 30s 左右:

  2. 主要耗时在 batch_get 和 coprocessor(和grpc duration显示一致,另外 scheduduler priwrite duration 和 aysync write duration 都较低):



  3. coprocessor detail → 95% handle duration by store 显示所有 TiKV 节点的 analyze_table 最大16s,每个节点的线都不连续:

  4. 不过 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 分钟后被自动关闭。不再允许新回复。