看起来 leader 迁移和 slow store 的原因更像是同一个。如果内存资源比较宽裕的话，更多可能是 对应 store IO 的问题。
8 天前
根据以往经验来讲，例如其他组件 pd 里面的meta 没有被清理掉是没有影响的，就是再进行同 IP，同 Port 扩容的时候会扩容报错
8 天前
QPS 2K+基本符合预期。单并发测试，qps 与请求的瓶颈 duration 成反比，吞吐肯定有限。对于 tikv 这种系统，单线程的测试意义很小，不建议在这上面浪费太多时间
11 天前
11 天前
pd-ctl中显示store 5region count还有两万多个，这部分region迁移走，pd-ctl信息会自动清理。
目前迁移速度较慢，可以尝试调大参数加快迁移速度：
config set replica-schedule-limit
config set max-snapshot-count
config set max-pending-peer-count
config set region-schedule-limit
https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices/#节点下线速…
15 天前
也可参考这篇帖子进行tikv async write抖动的排查：TiDB 写入慢流程排查系列（四）— TiKV Server 写入流程 - #7，来自 GangShen
15 天前
https://github.com/tikv/tikv/issues/16308 看起来之前也遇到过。从日志看，确实是某个 sst 文件损坏了导致报错，并且 tikv 在 panic 之前已经检测到 sst 的损坏. 感觉大概率是磁盘的问题，但很难实锤 root cause.
[2025/05/14 11:29:16.164 +08:00] [WARN] [event_listener.rs:131] [“detected rocksdb background error”] [err=“Corruption: block checksum mismatch: stored = 24998…
16 天前
tikv memory的主要占用就是block cache, region， memtable，running task。
可以从这几个角度看看。如果没有明显差异，可以去相差较大两个tikv node的heap分析是否符合预期。
23 天前
@Jerin 老师，确认了下，问题现象是符合预期的：SQL命中query_watch之后action switch_group到default（action kill duration 1ms），SQL不会被kill。目前switch_group一般是针对 RU_PER_SEC 这个，降速用的
这个功能我这边已经发起了feature：select sleep(2)命中query watch后被kill，且保持duration 1m效果（此后保持一分钟之内此sql的发起一直被kill）。
1 个月前
本地测试了下，如上述现象。也测试了 root 默认resource group 改为rg_limit
mysql> alter user root resource group rg_limit;
Query OK, 0 rows affected (0.02 sec)
session2 root重新连接：第二次查询生效了
mysql> select sleep(2);
±---------+
| sleep(2) |
±---------+
| 1 |
±---------+
1 row in set (0.07 sec)
mysql> select sleep(2); …
1 个月前
limit 8,1 limit 9,1
回表 actrows 9 86900
回表 cop_task 7 7022
total_process_keys 9 86900
究其原因还是limit8,1 在回表之前有一层过滤
1 个月前
没有更多内容了