lighting local 模式恢复，也会恢复 tiflash 副本。

[image] [image] 日志里面有什么内容么。 你试试 daemon-reload 也做下。

推荐升级，新版本 tidb 稳定性是有提升的。

看报错是获取系统版本失败了，是不是系统版本太低了。

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

我也觉得有点多，所以让观察一会，如果缓存到一定程度不涨了 我理解是没问题的。 如果一直涨。。。感觉可能需要看下。

1、 cdc 不同步系统表 2、https://docs.pingcap.com/zh/tidb/stable/ticdc-bidirectional-replication 双向是这个。rule 怎么配置看你需求 你想同步啥就配置啥即可。

不是，是统计信息：https://docs.pingcap.com/zh/tidb/stable/statistics

分布式就是扛高并发。

看火焰图截图是 statistics 应该和统计信息相关。 要不先观察一段时间 Orz

要不试试： String url = "jdbc:mysql://<host>:<port>/<database_name>?useUnicode=true&characterSet=utf8mb4&characterEncoding=utf8mb4";

81.19k/s 这个很高么？ 如果单位是 kb 我理解这个压力很低的吧。难道这里是 iops 的意思？

试试先升级到 * 6.5.11: 2024-09-20

这个应该是心跳导致的吧，没有变更也需要探活 我理解。这玩意忽略就好了吧。

看 50+% 的 cpu 是在 gogc 上，感觉是在频繁的回收内存。 但是你 processlist 也看不到有什么业务直连，而且你重启之后 cpu 会飘。 如果觉得和 ttl 有关，看了下有相关监控可以看：https://docs.pingcap.com/zh/tidb/stable/grafana-tidb-dashboard#ttl 你可以看看 [image]

[image] 看起来 cpu 就是在调度 (53%)和 gc 回收(34%)上. 至于为啥这么多和久是不是预期的就不确定了。我摇个研发瞅瞅

添加一个之后观察一段时间呢。我理解如果表分布很不均衡，生成 task 确实是需要消耗很多 cpu 的。 你可以dashboard 点下 cpu 高的时间段里面 pd 的火焰图。发上来 我瞅瞅

你先加一个 调度任务算完了 再加一个试试呢 。 难道 scatter 相关算法没有限流什么的

如果怀疑和写入有关系，可以看下 tikv detail >> schedule 监控下有个 pending 的监控面板，如果高可能是写入阻塞了 如果觉得和读热点有关系，可以看下 tikv detail >> thread cpu 和 read pool 相关面板，看看每个 tikv 的 cpu 是否均衡。 如果是读写热点问题看：https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues 写堆积的话，可以考虑调高一些 cf 参数：专栏 - TiDB 5.1 Write Stalls 应急文档 | TiDB 社区