为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
生产环境
【概述】 场景 + 问题概述
tidb server 的内存持续增长 ,oom kill
【背景】 做过哪些操作
手动分析过tidb server的内存
第一次分析时间为：2022/10/24日
第一次分析：
第二次分析：
tidb server参数配置：
memory-usage-alarm-ratio=0.8
mem-quota-query=4294967296(4G)
oom-action=cancel
手动分析原始文件：
profiling_2022-10-24_15-13-42.zip (6.8 MB)
第二次原始分析文件：
profiling_2022-10-25_16-58-59.zip (6.9 MB)
【现象】 业务和数据库现象
数据库异常 直接重启
最近7日tidb server内存使用
oom kill
【问题】 当前遇到的问题
tidb server oom kill系统服务异常重启
【业务影响】
数据统计服务数据不可用
【TiDB 版本】
v5.4.0
【应用软件及版本】
【附件】 相关日志及配置信息
/data/tidb_db/tidb-log]#dmesg |egrep -i -r ‘killed’ /var/log
/var/log/messages-20221002:Oct 1 17:24:48 PD205 systemd: tidb-4000.service: main process exited, code=killed, status=9/KILL
/var/log/messages:Oct 25 15:03:04 PD205 systemd: tidb-4000.service: main process exited, code=killed, status=9/K
抓取的内存堆栈
profile.zip (7.2 MB)
好的。我抽个时间测试下该调整看是否有效，非常感谢！
人如其名
(人如其名)
5
贴下analyze version
还有当前没有执行完的SQL，看看information_schema.cluster_processlist里面有没有还在执行的语句，如果有就贴下看看。
tidb_analyze_version 参数修改过。已经重建了table analyze。目前看来没有效果
buddyyuan
(Buddyyuan)
9
看上去像是统计信息的问题，统计信息的参数是怎么设置的 ？
人如其名
(人如其名)
10
我是怀疑他这个分区表的分区特别多，然后还没有做统计信息搜集，临时产生了pseudo表，相关的这个insert select执行的又太久。。。
alfred
11
看起来是平稳上涨，可能某些进程一直增加未正常释放或者TiDB本身的bug，有运行其它程序吗？在OS层分析下
你指的是tidb_analyze_version分析参数吗
tidb_analyze_version=1和tidb_analyze_version=2都设置过。设置后感觉不太大效果
jansu-dev
(Jansu Dev)
13
该观点 +1；
- memory Usage 和 profile mem 消耗对不上
- 看 go-threshold 就 hold 了 25GB 的内存，reserved-by-go 也有 12GB 内存，这 12GB 是 GO 语言自己 hold 的，在 v5 TiDB 默认采用的应该就是 激进的 内存释放策略，这块也没什么可调的了。如果想从这块调的话🤔，可以试一下 v6.3.0，他是用 go 1.9 build 的，释放内存会更激进写。看是生产环境，可以把业务流量用 https://github.com/zyguan/mysql-replay/tree/dev mysql-replay 采集下生产流量，然后测试环境持续的压新版本，如果新版本不出现该种情况，证明该问题新版本消失。
MySQL Replay 流量回放工具说明(2).pdf (308.3 KB)
已经尝试使用配置 GODEBUG=madvdontneed=1 参数，tidb_analyze_version=1,重新drop table 分析信息。 并重建，目前在观察中，我后续会在测试环境升级版本测试。验证是否在新版本中是否有该问题！
非常感谢！
