【 TiDB 使用环境】生产环境 /测试/ Poc
测试
【 TiDB 版本】
6.5.0
【复现路径】做过哪些操作出现的问题
集群有5.4.3升级至6.5.0
【遇到的问题：问题现象及影响】
业务偶发报错 Out Of Memory Quota
tidb_mem_quota_query这参数含义与之前有较大的变化
请问如果某个会话是长连接，比如持续运行10天，那么内存是不是就会一直累积，直到触发 tidb_mem_oom_action
【资源配置】
【附件：截图/日志/监控】
请问如果某个会话是长连接，比如持续运行10天，那么内存是不是就会一直累积，直到触发 tidb_mem_oom_action
如果在这10天之间，该长连接有一些时间段是sleep状态，内存是否会自动释放
这个参数是指单个session执行sql的过程中使用的内存
一个session，sql执行完了，占用的内存就可以释放
一直sleep，占啥内存啊，就算session本身，也只是很小一部分的
1 个赞
6.5.0含义变了，是一个session，不是单个sql
一个session同时也只能执行一个sql啊 想执行下一条 得等上一条执行完了
你理解同一个线程串行10条sql算一个session还是多个session？
1个…
是的，所以如果这个session断断续续的持续执行多个sql，是不是一直会累积内存，这个是我的疑问点，根据我们现在测试现象，是会累积的，但是不清楚何时会释放内存
执行完一个查询后，占用的内存应该会释放，就算缓存没有立即清理，也可以被拿来复用
如果真是您测的这种状况，累积不释放，那肯定是有bug
不好说，升级前都没报错，升级后触发了挺多oom了
可以在dashboard看看
执行计划的改变会导致内存使用不一样，可以analyze table 试试
6.5有了全局内存控制，OOM情况有了很大的改善，系统具体OOM的原因，你可以另开个帖子，贴上相关日志，让大佬们看看什么原因
谢谢了，已经查到原因了，是 tidb_server_memory_limit参数的原因，这个参数是从6.4.0引入的，默认2g，连接很多，有个大点的sql就报Out Of Memory Quota
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。