可以在sql分析看下最后一段时间的sql
在触发系统oom前一分钟tidb-server 日志中有打印oom 告警，告警会记录当时的heap 和正在执行的sql . 但记录sql 的文件是空的。
内存使用太快了，还来不及dump就OOM了。所以建议开 topsql 功能呀，那个是端到端的技术。
1 个赞
可以在sql分析看下最后一段时间的sql
这个尝试可以复现么。
那条SQL是啥，具体
我这出现tidbserver oom问题是，存在一些不能下推到tikv的sql，通过优化后排除。在dashboard中排查下sql看看。
是不是这台服务器上有运行其他的进程，其他的进程占用内存比较高，然后服务器把tidb kill 了
1 个赞
比较同意楼上的推测，毕竟从监控上看，内存比较平稳。日志里面也找不到可疑的expensive query。
那可能性就剩下，tidb panic暴毙了，或者有别的进程占了很大的内存，导致oomkiller选中了tidb进程杀掉了。
有没有lightning这类导入任务？时间接近整点，crontab里面也可以查查。
服务器系统日志可以看下 dmesg
Oom好多情况下，是设置没有设置内存控制或配置太小引起的
今天设置了这个环境变量 GODEBUG=madvdontneed=1
目前看上去内存使用率降下来了。我这边还需要继续观察一下。
慢查询里只会记录执行完成的sql吧，感觉前后10分钟的范围有点小。我们排查一般都是前后半小时。
有时候确实会突然oom.然后也没有sql记录，有时候也会记录sql。不知道啥情况。不记录的时候都是瞬间内存暴增，然后重启
这个应该是没有达到设置的阈值，瞬间就OOM了，没有记录到
这个算不算阈值定高了
如果你是6.5以后的版本，针对单条SQL的限制可能会缓解，但是更低的版本貌似还是全局的，这个不好解决，我们也准备通过升级的方式解决，我们拉了条监控拉取执行长的SQL语句，这样也能抓到一点SQL导致的OOM
没看懂，等大神