TIDB线程卡死

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.0
【复现路径】做过哪些操作出现的问题
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST WHERE time > 300;
【遇到的问题:问题现象及影响】
查询线程执行时间大于300ms的记录,结果发现有一个SQL执行时间很长,占用内存17个G,不知道是不是在看板查询告警或者其他页面时候出现的,并执行KILL语句也杀不掉,最终导致TIDB不稳定,经常出现中断。

SQL如下:
SELECT FLOOR(UNIX_TIMESTAMP(MIN(summary_begin_time))) AS agg_begin_time, FLOOR(UNIX_TIMESTAMP(MAX(summary_end_time))) AS agg_end_time, ANY_VALUE(digest_text) AS agg_digest_text, ANY_VALUE(digest) AS agg_digest, SUM(exec_count) AS agg_exec_count, SUM(sum_latency) AS agg_sum_latency, MAX(max_latency) AS agg_max_latency, MIN(min_latency) AS agg_min_latency, CAST(SUM(exec_count * avg_latency) / SUM(exec_count) AS SIGNED) AS agg_avg_latency, ANY_VALUE(schema_name) AS agg_schema_name, COUNT(DISTINCT plan_digest) AS agg_plan_count FROM INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY_HISTORY WHERE summary_begin_time <= FROM_UNIXTIME(?) AND summary_end_time >= FROM_UNIXTIME(?) GROUP BY schema_name, digest ORDER BY agg_sum_latency DESC

这个SQL是系统内的历史摘要信息的表

什么操作下会执行这个SQL啊

贴一下执行计划看看。

darshboardp之类的监控吧

或者是你在darshboard开了什么性能统计分析的定时任务之类的

正常这个应该不会耗费太多资源啊,这个就是 dashboard 上你点 sql 语句分析后台执行的 sql ,你可以抓个 heap profile 看下咋占这么多内存

1 个赞

我也碰到过类似的情况,系统自身的查询应该是效率相当高的,但是tidb在这方面就是有点不完善。

是查询sql一直没执行完吗

遇到过一次,是sql执行过程中,oom了,超过了memoryquota,然后kill的时候panic了。也没给客户端发消息,导致这个连接客户端一直等回复,但是实际上服务端就没有回复了。卡死了。这个是个bug。

1 个赞

楼主是7.5版本,也不知新的8.0版本解决这个了没有

是怎么kill的