求助!!!复杂sql导致tidb server 内存飙升,机器直接卡死

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.4.0
【复现路径】用户查询复杂sql,有8个表join
【遇到的问题:问题现象及影响】执行复杂sql时,tidb server 内存飙升,机器卡死
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

想问下
1、为什么tidb server内存不会释放?5.4版本有没有限制tidb server进程内存使用的参数?
2、如何避免这种问题?
3、除tidb server 卡死问题之外,还有tikv oom问题也比较频发,目前计划升级,想请教一下,升级到6.5比较好还是7.5?

1.因为是活跃内存,算子执行过程中会用到的,所以不能释放
2.优化SQL
3.建议升级到最新LTS,新版本更强大

建议升级7.5 或更高的LTS 版本,从7.5之后内存控制这块哟有了明显改善

最快最直接的方式是优化SQL。
升级建议升级到7.5的最新小版本。

1、看监控,内存用完之后就释放了
2、需要规范sql,优化sql
3、建议升级到7.5.x

建议升级到7.5

您好,第一个问题 5.4版本有参数限制内存使用吗? 想在升级之前临时限制一下

有未执行完的SQL缓存,所以不会释放内存空间
建议检查优化SQL语句 尤其注意笛卡尔积 排序等
版本来说 如果有条件 肯定越高的版本越好(这里说的是正式版)因为是对之前版本问题和优化的累积处理版本 在性能和BUG上肯定有优势的

  1. 正常内存使用过多是 OOM,如果服务器卡死,是不是系统一些 oom 行为有修改导致不释放。。
  2. sql 可以发出来优化下

有的,可以限制单条语句的使用内存


https://docs.pingcap.com/zh/tidb/v5.4/tidb-configuration-file#mem-quota-query

为了避免内存不释放的问题,可以通过调整操作系统的内核参数vm.min_free_kbytes来改善。将vm.min_free_kbytes从默认16MB变更为更大的值(如8GB)后,SQL抖动问题可以得到恢复。建议未合理设置vm.min_free_kbytes 、出现allocstall的TiDB集群选择低峰期主动设置,并在设置后进行观察,如果仍出现allocstall则应继续调整。建议升级到7.5的版本,会提供更多的新特性和改进

是的 补充上一楼 vm.min_free_kbytes 调整的更大一些,会让 Linux 更快的回收内存。

1、看图是高了一下,然后释放了不是,如果你的SQL不够优化,全表扫描或大量的临时数据生
2、优化SQL,调整内存配置
3、升都7.5吧,但是升级比较复杂

1 个赞

v5升v7还好吧,不过跨大版本,一般备份之后,原地离线升级比较好一点。