这个只能把大会话的sql杀掉，然后操作系统层面回收内存吧
如果内存确实将要耗尽，不关数据库，只能echo 3 > /proc/sys/vm/drop_caches手工回收
咦，版本不是6.5.0么？看你帖子选的版本是6.5，6.5的内存管控有了比较大的提升，之前版本的内存统计有缺陷，有些场景的内存会漏记，导致容易OOM。6.5之后OOM问题就降低了很多。
1 个赞
这个帖子不是我发起的 
额，没注意到，不过5.2的话确实有可能不释放，可以尝试升级一下集群版本。。
我这边的集群版本是v7.1.0，昨天也遇到相同的问题了，tidbserver内存有非预期的占用【虽然已经停掉读写请求了】，但是内存居然还是占用50gb左右，比较暴力的方式是先摘除单个tidbserver的实例流量然后重启
可以通过如下方式获取哪个线程占用内存多，但是细节还得分析源码才行
curl -G tidb_ip:port/debug/pprof/heap > heap.profile
然后使用go tool pprof heap.profile → top20命令查看
我一般都是直接restart tidb节点 反正是分布式的，反正都慢的不得了了，快速重启就好
我检查了下我们的服务限制的4g,这个一般限制多少为好
看看最大内存大小是多少
内存参数设置好，应该不会oom
不会oom吧
kill会话
kill一下链接