版本:8.0.11
背景:5个tikv,配置一模一样,128G内存
现象:
1.有2个tikv内存使用率会高很多，23和28节点内存使用率，相比较于其他节点内存高一些，23用了92GB,28用了91GB，185节点75GB
2.185 这个节点频繁掉leader,掉完以后过段时间又补上了，掉的原因从日志来看是因为evict-slow-store-scheduler 导致
请问一下，这样的情况下，有没有什么办法排查出为什么23和28节点为什么内存用的多一点
排查了没有太多的写入热点
排查过程
1、185节点的磁盘IO没有太大的延迟
2、每个tikv节点的storage.block-cache.capacity 参数也是一致的
- 在 Grafana 中打开 TiKV Details 面板。
- 对比 185 节点与其他节点的 Scheduler Latch Wait Duration 和 Write/Read QPS 。
- 如果 185 节点确实慢，先将其隔离或重启，观察集群是否恢复平稳。
- 查看 PD 日志，确认为什么 Leader 会集中在 23/28
5 个 TiKV 配置相同，但 23、28 节点内存偏高，是因为 leader 分布不均或 table/index/filter 内存占用不均，导致 RocksDB 内存结构不一致。
185 节点因对比其他节点 latency 略高，被 PD 的 evict-slow-store-scheduler 频繁驱逐 leader。
通过均衡 leader + 关闭 evict-slow-store 调度
23、28和185的元数据有什么特别大的差异吗
先确定哪些进程占用的内存高。确定是tikv后，看看region的主节点情况
23/28 内存高大概率是因为Region 分布不均 （数据多）；185 掉 Leader 大概率是因为偶发的长尾延迟 （可能是硬件隐患或 CPU/网络争抢）触发了 PD 的保护机制。建议优先排查 185 的硬件日志和 P99 延迟指标。
1 个赞
负载均衡优化
- 开启热点 Region 调度，自动分散热点数据与 Leader
- 调整
evict-slow-store-scheduler阈值，避免误判驱逐 - 手动均衡 Leader 分布，确保各节点 Leader 数差异 < 10%
2. 内存配置优化
- 统一各节点
storage.block-cache.capacity，建议设置为物理内存的 40%-50%（128G 内存设置为 50G-60G） - 限制 RocksDB MemTable、Compaction 的最大内存占用，避免内存溢出
- 开启 TiKV 内存自动调优（v8.0 + 支持）：
storage.block-cache.adaptive-capacity = true
3. 监控与告警
- 配置 TiKV 内存使用率、Leader 分布、慢节点状态的告警，及时发现异常
- 定期抓取内存 profile，建立基线，快速定位内存泄漏 / 异常
1.每个tikv的storage.block-cache.capacity 都是20GB，但是占用这么大内存，不合理的
2.抓了下tikv的heap信息 如下
主要使用的内
tikv23-storaged.pdf (20.9 KB)
存在 rocksdb::UncompressBlockContentsForCompressionType (inline)
上传了一个23 tikv 内存的追踪图，哪位老师比较懂内存结构的，麻烦提点意见
还有一个非常重要的点，我这个集群的GC时间设置的很长，设置了一个月，旧版本数据量很多，不知道会不会有影响
gc时间这么长不知道对各种cache有没有影响哦
现在慢慢往下调整，不知道有没有用，内存这种东西太底层了
按理说版本这么多，性能不是早就受影响了吗，读取数据的链路太长了
你描述的情况，23 28内存高反而正常 。要分析下185节点。grpc延迟大或者其他原因
排查优先级：PD 慢节点日志 → TiKV 调度延迟 → 磁盘延迟 → 硬件环境。
感谢老师分享
感谢老师分享！！！
gc时间有调整回来吗，调整之后正常了吗