crash的原因，我感觉还不是这个，这个报错还是有些连接上的问题。 我感觉是这类报错太多，导致crash的根因，可能淹没在日志里面了。 你在日志里面搜一下fatal，看看有啥内容没有？ 还有就是注意搜索 Welcome to TiKV，这是启动第一行日志，这行上面一般就是crash的fatal报错。

numa最好是能划分出4个。不要ticdc的2台机器把监控也部署好。数据库没监控还是不太好的。

大概率是有别的清理脚本，进tmp下面把对应的目录清理掉了。建议mkdir以后，把owner和权限都设置好，让别的用户不能删这个目录就应该可以了。

[image] 期望看到的是2，也就是select 可以被tidb_mem_quota_query限制住。 实际结果是3，tidb oom了。 如果是auto_analyze的问题，应该只有ddl owner会oom。也就是说只会有一个tidb节点内存升高，不会是2个tidb节点都升高。 空region有点多是个问题，但我感觉和这个内存的问题关系不大。

github.com/pingcap/tidb/pkg/server/internal/util.BufferedReadConn.Read(...) 这里的io指的是网络连接。所以第一时间应该查连接。

先从内存查起。oom killer相关的日志能找到吗？ 如果是oom killer选中了tidb进程，那基本可以确认是oom的问题。然后在内存高位，开profiling看一下，到底什么东西占用的内存高。 IO的问题如果导致tikv重启，日志里面应该会有的。这个你可以翻翻tikv的日志。看看是不是有什么提示。

1，tidb serverless云服务上，还有单表600T的业务在支撑。不建议超过200g，从何说起？tidb的读写能力和节点数量有关，如果节点数量不够，别说200g，20g可能也很慢。读写能力是根据你的资源配置线性扩展的，没有硬性标准说大于多少就不行。 2，同上。你要机器不行，多要资源吧。tidb不背这个锅。 3，这在7.5版本以前确实是个问题。只有ddl owner一个节点在工作，大表加索引是个痛点。 7.5版本之后，有分布式执行框架，可以多找几台tidb节点，并行加索引，大表加索引慢的问题，也变成了和你的资源配置线性相关了。 https://docs.pingcap.com/z…

你这个机器很不错。如果要混合部署的话，记得绑numa。给每个组件划定cpu和内存资源。这种隔离性会比较好，不会有组件之间相互影响的问题。 有多块盘，numa有富余，可以多起几个tikv实例。但如果没有多块盘，就算了吧。没有必要。

[image] mysql 8.0.42版本。报错插不进去。 [image] tidb 8.5.2版本，错误是一样的。 tidb 7.5.3我也测了下，确实和mysql8不一致。插入是成功的。 [image] 7.5.6就变得一致了。 这个兼容性问题，应该确实存在，不过后续应该是修复了。

[1752154005508] 这两个图捞出来看看。

有一个类似的issue。 里面提到，当有100w表的时候，执行下面这个语句， select count(1) from information_schema.tables; 导致了oom。 感觉和这个问题很像。你可以自己判断一下是不是类似这种表或者information库下元数据非常多的场景。 进一步的问题在于修复。这个issue修复直接合到了master上，没有在8.5分支上合并，我对比了一下修复代码和8.5.2版本，确实这部分修复不在8.5分支上。 这也就造成了目前还没有可用的子版本，可以通过升级修复这个问题。

你这确实是默认值，最大只有512Mb，但你这个图里面看怎么都不止512Mb。 [image] 起码3-4g了。bug的概率很高了。 [image] [image] 再看看这个图吧，如果说这个图统计的内存占用和heap profiling也不对上，我感觉就是bug了。

https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_schema_cache_size-从-v800-版本开始引入 tidb_schema_cache_size tidb_schema_version_cache_limit 这两个变量设置的是多少？ https://docs.pingcap.com/zh/tidb/stable/saas-best-practices/#缓存配置 我注意到infoschema是一块缓存，而且有明确的大小限制。不应该膨胀到4-5g。 https://docs.pingcap.com…

ping值2ms左右，确实可以接受。 后面的结论我也同意是果不是因。是当时不能互通的一种佐证。我已经没什么思路了。这个oom的原因让人困惑。

289ms 是比较高的了。 我先整理一下思路吧。首先一开始的问题从日志上看就是每个节点之间的互联互通有问题，那么我想到如果每个节点之间的互通有问题，获取tso肯定会慢，就值得看看tso wait指标是否正常。tso wait这里现在看是个有优化空间的地方，不过很难说和原始内存升高的问题有多大的相关性。 默认的slow sql的阈值是300ms。tso wait需要289ms的意思就是，几乎所有的sql在默认设置下都会变成慢查询。很显然留给其他环节的时间必须小于11ms才会不进慢查询，这是很难做到的。 https://docs.pingcap.com/zh/tidb/stable/late…

curl -X DELETE http://10.1.1.41:2379/pd/api/v1/gc/safepoint/ticdc-default-6745880471065248223 还真是这么删的。最近ai生成的不靠谱的多。大致求证了一下，这个应该是没问题的。 另外可以写个文章记录一下这个处理过程，也很好。而且积分更多。

感觉整体都慢。慢的还挺均匀，写入也是20s左右，查询也是20s左右。 [image] SQL Execute Time Overview这个图里面找tso wait，看看是多少。

你注意翻我发的那个帖子。 里面讲的比较清楚的，判断机制是，readpool的排队时间上升，grpc的RPS（每秒请求数）下降。当这2个事件同时发生，就认为这个store是slow store。 换句话说，不管你怎么看io，这个store一定是grpc请求也下滑了，排队时间也上升了。才会导致被evict leader。

但只有62的leader降到了0 这个是符合预期的，因为如果2个tikv的leader都evict，那某些raft组的多数派就没办法维持了。所以2个都高的情况下只能evict一个。 这么看的话leader掉0的主要原因，就是evict slow store。如果确定你的盘很慢，我感觉可以考虑去掉evict slow store 这个scheduler。 你可以看看这个帖子，里面对于slow store的讨论是比较全面的。从判断机制，到解决方法。 以往掉0，我会第一时间感觉是slow store的问题。这次我没有第一时间怀疑是slow store，主要是以往碰到的都是瞬间掉下去，…