TiDB-Server OOM起来后，所有SQL执行都很慢

🪐 TiDB 技术问题
,
21

从你的反映情况看，是tidb server在获取表的统计信息时出现异常导致，从这个点去深入查一下

1 个赞
22

感谢回复！
oom的sql已找到，现在主要的问题是oom后起来时卡的问题

23

感谢回复！
请问统计信息这个方向该如何入手排查及解决？

24

[2023/12/20 18:15:38.767 +08:00] [ERROR] [terror.go:307] [“encountered error”] [error=“write tcp 172.16.5.174:4000->172.16.5.95:45512: write: broken pipe”] [stack=“github.com/pingcap/tidb/parser/terror.Log\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/parser/terror/terror.go:307\ngithub.com/pingcap/tidb/server.(*packetIO).writePacket\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/packetio.go:174\ngithub.com/pingcap/tidb/server.(*clientConn).writePacket\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:399\ngithub.com/pingcap/tidb/server.(*clientConn).writeError\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1446\ngithub.com/pingcap/tidb/server.(*clientConn).Run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1078\ngithub.com/pingcap/tidb/server.(*Server).onConn\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:551”]
2023/12/20 18:15:38.768 +08:00] [ERROR] [terror.go:307] [“encountered error”] [error=“connection was bad”] [stack=“github.com/pingcap/tidb/parser/terror.Log\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/parser/terror/terror.go:307\ngithub.com/pingcap/tidb/server.(*clientConn).Run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/conn.go:1079\ngithub.com/pingcap/tidb/server.(*Server).onConn\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/server/server.go:551”]
172.16.5.95 这是CPU高的那个tikv吗？

25

172.16.5.95 是应用服务器，它访问TiDB-Server

26

感谢各位的回复，楼上各位的解答都对我有很大的指导意义，这里给大家汇报下我的解决方案：
1、优化了导致OOM的sql语句
2、有一个分区表的分区数差不多有700个，这是近期加上去的，目前已把这张表干掉（这可能是导致加载统计信息慢的原因，但没有验证）
3、清除一些没用的表
4、在计划升级TiDB版本到v7.1.0 或以上，加入force-init-stats参数进行控制

目前能确定解决方法是优化导致OOM的sql语句，因为只要不再发生oom，这个问题就不会发生。

27

:+1: :+1: :+1: :+1:

28

之前我们出现过OOM之后TiDB节点hung住了一段时间，才真正完成重启，真正完成重启之后SQL执行才恢复正常

29

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。