【 TiDB 使用环境】
生产环境
【概述】场景+问题概述
1、每个整点会有一批定时任务，清表，然后插入数据，数据量不大，但是sql比较复杂（通过拖拉拽生成的）
2、数据订阅：flink cdc 和 DM，dm订阅有大概3w张表。
【现象】 tidb-server 实例总有一个内存占用超80%，直至OOM 重启。飘到另外一个实例，接着这个实例占用也会超80% ，直到OO M重启。如此反复。
【业务影响】
客户端侧重连。
【TiDB 版本】
v5.1.1
通过Dashboard搜索内存暂用高的tidb实例日志中最近一天的expensivequery。
memory_usage_alarm 日志：
record path记录的heap：
runsql：
tidb-server config：
希望大佬协助分析下，这个内存占用问题。
分析下 sql 复杂到什么程度？ 能不能适量的优化一下？
目前 这种sql 是同一类型的，还是很多不同类型的，最好抓出来，看看执行计划
有个比较大的疑惑是，内存上去之后，并不见有太多释放的。
从慢sql监控中得到最大sql执行占用在1.7G、1.2G。但出现次数很少。执行时间在7s 和 3s内。这类sql跑完，内存应该是会有释放的（sql缓存默认配置1G）。并且执行的tidb-server也并不是内存高的实例。
执行完 go runtime 也不会立即把当前的 alloc的内存还给系统。
你的情况很像：https://tidb.net/blog/de9bf174，当时我遇到的也是轮着重启一遍。
从处理过的问题来看，如果遇到文章中的场景，慢sql等不一定能正确记录，建议搜一下oom日志，最好抓一下heap，分析看看是哪的问题。
有 GC 等待时间的，所以要控制好 内存的使用量
还是尽量优化～
即使有内存空洞，也保证在可以接受的范围内
分析下慢sql，并对慢sql做个调优。
主要是golang的gc不能立马释放，先看下慢SQL吧，优化SQL可以解决一多半问题。
优化下sql吧，至于已经占的内存，如果后续没有类似expensive sql执行，就会慢慢释放
感谢各位回复。目前正在梳理相关sql中。
看看执行计划，对SQL语句是否走索引『对我有用』
目前本地的tidb-sever 有出现相同的问题。断开了所有连接到该节点的连接（理论上已经没有sql在执行），内存依然没有得到释放。尝试重启后，依然内存持续高企不落。
本地集群从 5.0. 升级 5.1.1 → 5.1.4 → 5.3.1
从 tmp-storage-path 路径上拿到的 heap日志，最新的内容如下：
该节点 tidb 日志 有大量 如下错误：
目前毫无头绪。
并发数做下限制吧，token-limit 。看tidb-server的内存分配了多少G，每个query 多少G。并行查询别超过总内存。
发现内存高涨时，特地把该节点的连接都断了。 select INSTANCE, ID, HOST, DB, COMMAND, TIME, MEM from INFORMATION_SCHEMA.CLUSTER_PROCESSLIST 已经没有这个解节点连接信息了。并且重启过该实例。所以理论上不存在query才对。但内存依然高涨
是不是需要手动释放内存
相似问题
标记一下
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
