【故障排查】高峰期TIDB同个物理库中一个逻辑库出现大量查询延迟

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

  • 【TiDB 版本】:3.0.7
  • 【问题描述】:我们用一个TIDB物理库创建了12个逻辑库,做不同业务的负载,在晚间高峰期,一个业务突然出现大量接口异常,查询发现是这个业务的数据查询慢。其他的业务逻辑库都没有受到影响。这种情况应该怎么排查呢?

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

  1. 如果其他逻辑库没有受到影响,只有这个业务库有影响,那可以先看下慢日志中关于这个库的慢日志记录
  2. 查看慢日志当时的 SQL 运行时间是否真的比较慢,以及慢在哪个环节
  3. 慢日志中的 tidb_decode_plan(xxx) 函数记录的是对应 SQL 当时的执行计划,可以到 tidb 中执行 select tidb_decode_plan(xxx) 看下当时的执行计划是否正常

没有特别慢或者特别多的慢查询,但是发现很多1S+时间的update,会是这个影响的么。

  1. 晚上高峰期是由于只有这个库业务比较多,所以感受到受影响, 还是其他库业务也很多,但是没有影响?
  2. 上传觉得慢的时间段一小时的监控信息,over-view,tidb,tikv-detail,disk-performance信息 (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

  1. 觉得慢的那个库的tidb日志,慢的时间段和监控一致的tidb.log日志和 slow日志 ,麻烦也截取一些上传,多谢。
  2. 你觉得慢的update语句,麻烦上传一个完整的slow信息,多谢

1.其他库业务还更多,但是没有影响。现在就两个库有影响。

2.昨晚影响的部分时间监控截图

orver-view:

tidb:

kv:

disk-performance:

您好: 1. 从上面的监控看,总的duration都在500ms以下,怀疑点在于有些tikv的IO达到了100%,23:30-23:40的时候coprocessor有些error。

2. 麻烦还是反馈下具体什么时间点慢了? 上传一下那个时间段的slow日志和tidb.log,tikv.log日志。 3. 反馈说查询慢,有具体的sql吗?是否都是某张表慢? 另外在那个时间段有什么大的批量操作吗?

在这一段时间内断断续续的时好时坏周期都很长,看了慢查询,没有异常,大量的慢查询,稍后上个慢查询的语句,在那个时间段有一个活动,可能造成短时间的大并发,大概一小时一次,一次并发写入在3000 - 4000个事务单位。昨晚在截图的时间端有做增加索引的操作。

  1. 查看tidb侧duration都比较正常
  2. 和用户沟通业务接口侧超时时间是10s,tidb在整个高峰期最大的慢sql记录也只有3s,问题应该在上游链路
  3. 由于一个tidb集群有12个业务库,连接数不足会导致其他业务库受影响。用户调大连接池连接数后,问题缓解。