【TiDB 使用环境】生产环境
【TiDB 版本】7.5.1
【操作系统】
【部署方式】虚拟机部署，16G内存
【集群数据量】1
【集群节点数】1
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
出现了内存占用特别高的情况，吃掉了80%的内存，memory-usage-limit参数设置为系统内存的50%，但是拦不住，看了下社区的有关oom的帖子，也都说这个参数拦不住，现在我用jeprof抓了一下内存，发现有个叫status_init 这个占了非常多的内存，且无法回收，请问有人知道这个跟哪个流程有关吗？是什么地方创建的？
3 个赞
status_init 内存高与 TiDB 状态初始化流程相关，多是元数据加载异常未释放，要不试试重启节点或清理过期元数据。
1 个赞
16g内存你部署了几个节点 多少副本？
内存会不会太小.实际很多操作都吃内存的
2 个赞
16G估计真的只能启动每个节点，然后稍微波动下就不够了，每个节点的应用起来都要占起码2G左右的内容的。。
2 个赞
就一个store一个meta一个db
1 个赞
生产环境16G内存，还是虚拟机，终究是差点味哟。
2 个赞
不够内存用的话，有时会出现一些平常没见到的错误。
2 个赞
单个机器的话，可以私聊一下我微信：billmay 我给你企业版敏捷模式的安装包 8c16g 可用。
平时跑得通的 SQL，在数据量突增或并发变大时突然报错
2 个赞
有些设计是需要在阈值内运行的，但内存小这种极端情况，就超了，然后就出错了。我这么理解的，不知道对不对。
1 个赞
嗯,正确的. 内存溢出会有意想不到的错
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。