【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.3.0
【复现路径】生产环境无法人为复现
【遇到的问题：问题现象及影响】
其中一台TiDB-Server发生OOM，服务起来后，执行SQL慢（甚致是执行不出来），大量sql语句堆积，某个表流量很高，执行show stats_healthy无任何结果输出，即使把业务停掉，把sql全kill掉，查询一些小表也依然查不出来，执行ANALYZE TABLE一张只有几条记录的表也没反应，只能等约十分钟左右，执行show stats_healthy有结果输出后，所有sql才能恢复正常。
这个问题从本周一第一次发生，然后每天基本都会发生１～２次，以前也经常发生过oom，但服务起来后TiDB-Server是正常的。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
log.rar (347.8 KB)
读写慢可能是TiKV 重启后重新选举，同时查看下 block-cache是否配置太大
如果给的缓存比较大的，是比较慢，我现在重启我们集群的tidb-Server，至少要等个一两个小时才能加载完
TiKV没有重启哦，是TiDB-Server重启
以前也经常OOM，但起来后就好了，只是这周一开始才这样
v5.3.0 无解，只能手工控制前端 LB 流量，等 tidb ready 了后再放进来
https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#force-init-stats-从-v710-版本开始引入
看下SQL跑的是不是都是错误的执行计划，看下启动日志，关注下init stats
为什么你几个tidb节点配置差那么多。
tidb-server重启的时候会重新加载统计信息，如果加载时间过长就会强制停止加载后直接启动，这时候有一些sql可能会走到错误的执行计划上，导致对tikv的数据进行大量的扫描造成数据库大量的慢sql。我觉得你还是先分析你oom的原因吧，tidb-server虽然是无状态的，但是老是oom对业务也是有影响的。
感谢回复。
执行计划倒没错，我把卡住很久的sql取出来explan看是没问题的，另外TiDB-Server启动的时候日志报“[ERROR] [client.go:845] [“[pd] update connection contexts failed”] [dc=global] [error=“rpc error: code = Canceled desc = context canceled”]” 和较多的"get timestamp too slow" 不知有没影响
感谢回复。
方法应该是可行的，就是如果有其它解决办法还是不希望通过升级数据库来解决，毕竟升级可能会有很多未知的风险
看下刚启动时的慢查询吧
不同TiDB-Server对应不同的业务，因此配置差得有点多
单个tikvcpu 高可以在topsql中查看那些sql使用资源多
是的，刚启动的时候基本什么sql都执行不出来，但切到另外一台tidb是可以正常执行出来
单个tikv cpu高应该是有一个表存在大量的读导致，但这也不能解释在刚启动的tidb-server里sql执行不出来，同样的sql在另一台tidb-server是可以很快执行出来
感谢回复。
奇怪的是，执行不出来的sql，在同一台的tidb-server里explain看执行计划是正常的。
oom是需要解决，但tidb很难根本杜绝oom，因此这个问题也需要解决
在oom的tidb实例上可以找到引起oom 相关的SQL，消耗资源比较大的SQL关键字expensive_query ，查看执行计划是否有全表扫描，避免OOM，你这里tikv实例才32G内存比较小，一旦 有全表扫描对集群io影响比较大吧，show stats_healthy只能查看表的统计信息是否健康
读写流量那么高，那台TiKV有写热点吗
都已经OOM了肯定做啥都慢了。
