@jhm633 跑到了下午6点左右 pd cpu降下来趋于平稳，但利用率还是有之前的2-3倍，如果是由于region数量多, pd在检查时消耗cpu高，这个可以理解，但是感觉这块还是可以优化降低cpu利用率，比如给这些region打个标记 调度后就固定在主机上 [image]

每个表的region数量，region数量太多了？现在开了一个表，从12:35开始截止现在已经跑了3个多小时了，看多久能跑完吧，有下降趋势 [image] [image] 链接：百度网盘 请输入提取码 提取码：g3go

一直持续高，如果是开始有调度产生高那么几下还能理解 [image]、 profiling_2024-11-28_13-57-03.zip (174.9 KB)

没用，一添加就涨 [image]

是不是tidb 以阴历年来定一年一个大版本号

不得不吐槽下flashback cluster ，这个功能到实际生产中有多大几率能用的，开发这些功能的经历还不如搞搞稳定性和提升性能

一年前3季度dmr 最后一个季度lts DMR 可以用小版本号， 版本号别推的那么高，后面念着都绕口了

[image] 这压力有点大了， 看描述这当时引入这算法就是为了降低迁移时的影响 [image]

不一样磁盘大小的 我会调整region_weight [image]

[image] 你df看下磁盘空间是多少

试试把leader-schedule-limit 调到一个很小的值 比如1 ,减少这类调度和balacne region的争抢，但有可能会导致tikv cpu利用率不均衡

看下pd监控的operator产生和消费正常吗。正常的话先试试调大调度参数 pd-ctl config set 调整 replica-schedule-limit ，max-pending-peer-count 以及 max-snapshot-count 。 pd-ctl store limit all xx 增大store limt。

还是得看日志啊，找个region 看看pd leader 和 tikv.log 有啥报错导致调度下发了，但是执行不成功

tiup cluster display 看下集群状态

单副本肯定是因为你就一个tikv ， 也很好奇为啥你没调整max-replicas 单副本也能跑起来。 理论上你副本数是设置3 ，是会补副本的。

operator add add-peer 2 5：在 Store 5 上为 Region 2 添加 Peer 用pd-ctl 试试手工再其他节点添加副本能不能成功

如果其他节点一直副本没补成功，看看日志里能不能看到些信息。

看这个日志， 他在往另一台上去添加副本，你按这个region id 搜下tikv.log 和pd leader的log 看看有没有啥报错信息， 还有就是你说的缩容报错，看你发的日志 这一个正常的Info信息，你说的报错是什么样。你注意观察下store_id=1上的region count是不是再减少 其他上的再增加，我感觉这个上的region 得要先补完副本 才能处理下线的操作。 region_count 可以从 tikv_store_status里直接查 或者 直接看监控 overview-> tikv 里的region/leader监控

pd-ctl config show 看看