tidb server 异常OOM

我先找个环境测试一下吧,远程意义不大,就是看操作一遍而已

上面的步骤是我已经在生产上都复现了的。。

:ok_hand:,那我们分析一下

1 个赞

看了一下你的版本是v5.0.3,问一下你的 tidb-server 哪有什么配置嘛?

有这几个

server_configs:
tidb:
log.slow-threshold: 300
mem-quota-query: 12884901888
new_collations_enabled_on_first_bootstrap: true
oom-action: cancel
performance:
server-memory-quota: 8000000000
txn-entry-size-limit: 12582912

image

:ok_hand:收到

1 个赞

不过刚发现一个问题,8000000000 才 7G 多?

有点怀疑这个,要不你先修改一下试试?

这个是tidb server的配置,只限制的是tidb server的使用内存, 这个sql本来按执行计划是用几KB,然后日志中显示用了1.09G,都远没有到达这个7G
而且这个设置 如果达到限制,是随机kill 语句,现在的表现是tidb server重启,报错是不一样的

不过我可以测试下这个,但感觉不太可能是这个

可以提供一下 /tmp/1001_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record 这个文件吗

看起来,使用 hash agg 会导致 OOM,这里的 estimate 不是准确的;hash agg 会全量聚合所有数据,然后再执行 limit,所以这里是可能导致 OOM 的。

可能的解决方式是尝试使用 stream agg。

希望提供

这里面的几个 heap 文件实锤一下

这个
record.tar.gz (1.9 MB)

可以考虑在 main_post_id 字段上添加索引,然后看看计划能否产生 stream agg,如果可以的话应该可以把内存占用降下来

对这个字段加上索引就不会走tiflash了吧。。

对,不会走 tiflash 了,但是因为你有 limit,量不大的话也可以很快跑出来

看可以实锤是 hash agg OOm

2 个赞

这个表3个多亿。而且后续会有更多数据,另外我们的场景不只这一个sql,加了索引,对这个表的操作就都不会走tiflash了,对其他查询影响很大

并不会,添加索引之后只是这一条 SQL 不走 TiFlash 了,其他不使用这个索引的 query 会继续使用 TiFlash

如果优化器不够聪明,可以使用 optimizer hint,譬如强制不使用某个 index