内部SQL查询OOM如何优化

【 TiDB 使用环境】生产环境
【 TiDB 版本】v8.1.0
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
tidb服务通过负载均衡器(权重1:1:1)对外提供服务,其中2个节点资源占用比较低:


其中1个节点频繁、周期性出现OOM情况:

Dashboard 慢查询经常出现内部SQL查询占用大内存情况,


目前tidb_mem_quota_query配置为2.5G,导致内部SQL查询执行失败,内部SQL查询有哪些优化思路吗?

调整 TiDB 节点配置,避免资源过载

检查负载均衡器的 “连接保持” 配置,定期清理无效会话

1 个赞

降低内部 SQL 的内存占用试试

2 个赞

根据业务、优化内部SQL吧

比较奇怪的一点是看不到 SQL 文本,不过通过执行计划可以看到访问的是 stats_histroy 表,这块有个历史统计信息功能有问题,高版本已经是默认关闭了,v8.1.0 默认是打开的,关闭就好了,这个参数关了就好了 tidb_enable_historical_stats

内部SQL查询可以关?关了会不会有影响啊?

紧急kill掉性能sql,然后联系业务优化SQL

1 个赞

如果是云上资源可以紧急扩容 临时处理

1 个赞

扩容未必能解决问题哦,比如内存泄露问题

1 个赞

咋降低内部SQL内存占用?

1 个赞

这个倒是可以试试~~

直接清了stats_history,然后限制内部SQL内存,先这样了

优化SQL,增加硬件配置,基本就这两个方向。

避免全量扫描

1 个赞

内部sql,bug的可能性大

预估10行,实际1128行,统计信息误差比较大,该表实际占用了多少空间有没有记录?

查出来慢sql扔给开发

看上去是sql使用资源过载,可以考虑从应用逻辑上进行优化,毕竟优化器不是万能的


这种sql点击进去,应该是批量操作造成的,可以把里面的大事务拆分成小事务。