大佬 集群扫描配置

啥都没看到

没改过采集指标

dashboard的top sql，持续分析功能都没有开启，tidb集群版本是8.1.1

目前观察到的是cpu 升高的时候，node_exporter 监控到 磁盘IOPS 延迟 吞吐量全都上来了

跨表合并是开的，adj-disallow-merge 的值不多，应该不是这个导致的

是的,region 过多,

90万个

raftstore.store-pool-size 调整到4以后，高峰期 也没有发生过掉leader的现象

在哪个监控面板

你的意思是storage.block-cache.capacity 为13.8GB，但是tikv 进程占用了内存24GB？

在slow store时间点，看下线程池是否打满， raft store cpu 几乎都打满了，看了下在slow store的时间点 Raft Propose 下的 Propose wait duration 发现也是很高（和commit log 的延迟重合） 几乎是可以确定了还是raft store cpu的瓶颈， [image] 您说的区分写入延迟还是提交延迟。是否有大事务导致raftstore线程处理单条消息时间过长 ，这是什么意思呢 我们这个集群是个大集群，有近90万个region,这种情况下，对raft store估计有不小的压力 [image]

还是那个老生常谈的问题 为什么之前可以，现在不行了呢

ai说的全都不对

和服务器时钟没有关系

完整报错就是这个，不是在日志里面看到的， 就是直接update语句就是这样的报错，我现在怀疑就是 可能就是单机部署1个pd+1tikv,但是副本数设置为3了，导致这样，但是呢又找不到原因

现在慢慢往下调整，不知道有没有用，内存这种东西太底层了

1.每个tikv的storage.block-cache.capacity 都是20GB，但是占用这么大内存，不合理的 2.抓了下tikv的heap信息 如下 [image] 主要使用的内 tikv23-storaged.pdf (20.9 KB) 存在 rocksdb::UncompressBlockContentsForCompressionType (inline) 上传了一个23 tikv 内存的追踪图，哪位老师比较懂内存结构的，麻烦提点意见 [image] 还有一个非常重要的点，我这个集群的GC时间设置的很长，设置了一个月，旧版本数据量很多，不知道会不会有影响

之前没有报错