TiDB查询请求响应时长波动问题

循环提交相同sql查询到tidb server,发现查询响应时间有比较大的抖动,短的在3s左右,长的达到近7s,具体参见慢查询日志表对应日志记录:


查看tidb server debug日志发现对应conn=2733的查询,每次都触发了“rpc error: code = ResourceExhausted desc = Received message larger than max (xxxx vs. 10485760)”异常,是由于此异常导致重试从而带来延迟抖动吗? 这个异常是怎么引起的呢?改如何调整集群配置来避免此异常呢?
tidb server debug日志 tidb.log.7z (678.4 KB)
sql查询语句 query.sql (3.7 KB)
tidb版本:v3.0.3

2赞

都是同一个 SQL ,然后执行时间有长有短么?

放个 explain SQL 计划上来看看

1赞

SQL执行计划参见 SQL执行计划.xls (32.5 KB)

1赞

@xfworld 这种查询时长的明显异常波动跟这个ResourceExhausted rpc error有关吗?

1赞

这个执行计划感觉不准啊,table 数据有没有做analyze

1赞

不准什么意思?table数据怎么分析?

1赞

https://docs.pingcap.com/zh/tidb/stable/sql-statement-analyze-table#analyze
ANALYZE 语句用于更新 TiDB 在表和索引上留下的统计信息。执行大批量更新或导入记录后,或查询执行计划不是最佳时,建议运行 ANALYZE

1赞

@xfworld 按照你所说针对所有表执行了analyze table后,查询耗时确实出现了明显下降,现在普遍在0.3-0.5s,但还会出现个别点的大的耗时波动情况,慢查询日志表对应日志记录如下:


执行完analyze table后SQL查询计划情况参见 Analyze Table后SQL执行计划.xls (45 KB)
像这种查询耗时波动又会是由哪块怎么导致的呢?另外,表的统计信息是不会自动定期更新,怎么会出现这种统计信息更新不及时的情况呢?

1赞

analyze 做分析的时候,会影响读写的

可以自己配置,如果这个表的数据更新,删除狠频繁,建议做,不然执行计划肯定不准

你得考虑一下什么时候做这个动作会更合适,至于操作可以看看文档
https://docs.pingcap.com/zh/tidb/stable/statistics#自动更新

1赞

那analyze table后还有查询耗时的大的抖动,接下来该怎么进一步排查呢?

1赞

是同一条 SQL 么?

如果是同一条的话,只能通过 explain 来分析优化了,通过查阅索引配置等等

1赞

是相同的sql呢,并且我又切换到另一个tidb server上去查询,连续运行这个相同sql对应的查询耗时却一直在0.3-0.5s,说明这个抖动跟tikv层关系不大了,是由先前那个特定的tidb server贡献的。

1赞

额,不是同一个网络么,,差这么多…

都是相同网络环境,而且先前那个抖动的tidb server是每隔几次查询后就会固定有一次抖动。

上个网络流量监控看看, 资源够的话,tidb server 也可以多搞几个实例 :grin: