心想事成，非常好，非常棒！ [image]

Release Version: v5.2.2 Edition: Community Git Commit Hash: da1c21fd45a4ea5900ac16d2f4a248143f378d18 Git Branch: heads/refs/tags/v5.2.2 UTC Build Time: 2021-10-20 06:08:33 GoVersion: go1.16.4 Race Enabled: false TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 Check Table Be…

每台TiKV服务器3块SSD，水平都差不多： fio Pass IOPS of random read: 66534.010152 fio Pass IOPS of random read: 17758.630063, write: 17868.442512 fio Pass Latency of random read: 156743.568944ns, write: 25442.079436ns permission Pass /mnt/disk5/tikv/deploy/da…

磁盘 io 看起来延迟很低： [image]

有个疑问，raft 耗时最大是在 apply wait duration 吧， io 应该不是最大的因素才对（而且 store-pool-size=3,apply-pool-size=3, CPU 使用率都在 150%左右，raftstore.apply-max-batch-size=1024，是什么导致了 apply wait duration 高？应该怎么排查呢） propose wait duration：100-400ms append log duration：90ms 以内 commit log duration：最大1s apply wait duration：3-8s ap…

resource-cluster-TiKV-Details_2021-09-06T09_44_04.533Z.json.zip (1.7 MB) 目前有监控图，可以先帮忙分析下监控指标吗，现在拿火焰图不是很方便

上面分析的结论中有： 没有 write stall 没有 latch cheduler writing bytes 最大20M，应该不是 scheduler-pending-write-threshold 瓶颈 各线程池 CPU 使用率没满 append log duration：90ms 以内

好的，warning 展示出来只是为了说明和参数不限时无关，不用关注，谢谢

调大了 gc life time，花了40分钟终于启动了。debug 日志全是历史 DDL 的信息： [image] [image] 然后看了下 DDL 历史记录，只能用海量来形容： [image] 为什么 drainer 启动时需要获取所有 DDL 记录记录？这篇文章有解释： [image] 所以这个问题无解？？？

pump 和另外2个 drainer 都正常： [image] 开了debug 日志，drainer.log 一直输出： [image] 并且看了 TiDB 中也没有在做什么慢查询和DDL： [image]

我也知道是超过了gc时间，但是为什么启动drainer 会这么慢呢？有没有排查手段？

你好，我手工安装的drainer 也有同样的现象：进程一直持续消耗内存，直到 OOM，并且 OOM 之前都没有启动 8249 端口。 启动命令： nohup ./drainer -config ./drainer.toml > log/drainer_stderr.log 2>&1 & 但是 OOM 后 drainer_stderr.log 并没有输出，drainer.log 也没有报错，只是一直没有启用 8249端口的信息： [image] [image] 请问如何才能让drainer_stderr.log 有输出，然后根据输出信息排查是什么在消耗内存呢？

其他接口 http://172.16.199.66:2379/dashboard/api/topology/pd、http://172.16.199.66:2379/dashboard/api/topology/tidb 等都正常啊，肯定不是因为无法访问 172.16.199.66:2379