看下tidb 到pd的 网络流量和延迟监控，blackexpoter nodeexporter里

发下dll leader tidb节点 12/10 18:02 之后的日志看看，你的日志是2024/10/09的

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

https://docs.pingcap.com/zh/tidb/stable/tikv-control#手动-compact-整个-tikv-集群的数据 可以compact整个集群，但是可控性不如每个tikv独立弄好。 一定要加 --bottommost ，否则没效果 tikv-ctl --host :20160 compact -c write -d kv --bottommost force --threads 2

你的tikv多大磁盘， 数据量有多少 ，你的是不是mvcc有点多 需要手动compact下

还是空间问题，另外这个10%限制有点一刀切的意思。你说的这个加大压缩率是啥？ 8.5的压缩率也不会提升吧，rocksdb每层算法也没变 ，你说的是那个每日compaction吗

admin show ddl 命令确认下 ddl leader 节点，然后看看加索引报错时的tidb 日志

集群没启用TLS是吧。 你可以测试试试最新的7.1.6上有这问题没

集群没有启用TLS吧, 会话级关闭这个变量 tidb_ddl_enable_fast_reorg ，用传统加索引方式 看看报错吗

是所有的表都会有这问题吗？这字段是什么数据类型

为啥要加ASC呢 ？ 去掉试试

TiKV Detail → Resolved TS → Lock heap size TiKV Detail → Server → Memory Trace 这2个先看看

[image] 这个打开后 确实快了 ，建议打开吗 ？ 关于三阶段聚合 我看官网也没具体的文章介绍，这个能在哪学习下

grep spill 了一下，麻烦看下是这个信息吗 spill.log (146.7 KB)

explain.txt (23.8 KB) @ guo-shaoge 从执行计划看 1个distinct的sql 里有3个 hashagg [image]

@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]