【故障排查】在业务高峰KV CPU跑高至80+%

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

  • 【TiDB 版本】:3.0.7
  • 【问题描述】:在业务高峰KV CPU跑高至80+%,并一直不会下降,导致业务查询异常。请帮忙提供下排查思路。



若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

查看下 慢查询,着重优化其中 processed key 高的 SQL

如果用负载连接tidb是否每次查询的慢查询都是不全的,每个tidb上的慢查询是不一样的吧 1.是否有地方可以看到所有慢查询 2.processed key 大概多少会影响到呢,processed key的单位是什么呢 3.高峰时期的QPS非常的高,能达到10W的量需要减少QPS吗

  1. 需要在每个 tidb 上来确认,现在有 slow query 的系统表来帮助排查

  2. 单位是扫描的 tikv 的 keys 数量

  3. 需要看具体的情况,如果没有热点,或者全表扫描的话,再根据系统负载来判断,10万 qps 还是 ok 的。

今天查询了一下没有高的processed key,但是慢查询里面有1S左右的慢查询,但是process_time 在1-2S左右,是因为这个堆积吗,一个TIDB大概1分钟2-3条

这边需要查看下相关监控了,可以看下 trouble shotting 面板的 hot read 和 hot write

读的监控:


写的监控:
这里的监控查看官方文档有解释吗。监控很多,但是我们很多时候不懂的怎么具体查看。或者不知道从哪个监控能分析出问题。

可以查看一下 slow query 的 SQL 的执行计划,按照 SQL 优化思路先做一下优化。从监控看,是可能是读热点的,某个 KV 的 CPU 高的情况。可以通过两个方向优化和分析:

  1. SQL优化流程,可以参考一下官方文档。
  2. 监控的 CPU 高的 tikv 的,根据具体的 KV 节点,查看 KV log ,会有一些 slow query 的日志,里面会记录响应的 table id 和时间戳,根据时间戳和 table id 可以在 slow query 定位到 SQL。

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