当前位置: 首页 > news >正文

tikv排查指南2 - 小镇

tikv排查指南2

你现在这个问题已经进入生产级判断:如何在 TiKV / TiDB 体系里确认“内存瓶颈”

我按你当前 Grafana 目录(你列的那些 dashboards)给你一份可直接用的确认表(不是概念,是判定 SOP)


🧭 TiKV / TiDB 内存瓶颈确认表(v8.1.0)

🎯 目标:确认“是不是内存问题”,不是猜


排查层级Dashboard关键指标/现象内存瓶颈判定条件结论类型
1 基础入口 online-Overview / online-Performance-Overview latency ↑ / QPS正常 慢但QPS正常 需要继续下钻
2 是否读写异常 online-Performance-Read / Write read latency ↑ / write latency ↑ 双边或单边慢 内存可能参与
3 TiKV cache命中 online-TiKV-Raw block cache hit / miss miss ↑ 且持续 ⚠️ 内存压力信号
4 RocksDB读路径 online-TiKV-Raw read latency ↑ + cache miss ↑ miss ↑ + IO ↑ ✔ 内存不足(关键)
5 OS内存压力(间接) online-TiKV-Details(线程/CPU) CPU高但IPC低(结合perf) CPU stall + cache miss 内存/IO混合压力
6 IO联动确认 online-Disk-Performance read IO ↑ + latency ↑ IO上升且cache miss ↑ ✔ 内存导致IO放大
7 PD无异常排除 online-PD leader正常 hotspot不存在 排除热点因素
8 Raft排除 online-TiKV-Details propose/apply正常 无明显延迟 排除复制问题

🧠 一、内存瓶颈“核心判定条件”(最重要)

✔ 只有同时满足才算内存问题:

block cache miss ↑
AND
read IO ↑
AND
latency ↑
AND
无scan暴涨(排除coprocessor)

🚨 二、三种“假内存瓶颈”(非常常见)


❌ 1. scan 导致 miss(最容易误判)

现象实际原因
cache miss ↑ SQL全表扫描
CPU ↑ coprocessor
IO ↑ scan SST

👉 ❌ 不是内存问题

📍看:
online-Performance-Read


❌ 2. compaction 导致 IO + miss

现象实际原因
miss ↑ RocksDB重写
write IO ↑ compaction

👉 ❌ 不是内存不足

📍看:
online-TiKV-Raw


❌ 3. raft snapshot 导致 IO

现象实际原因
IO spike 副本同步
latency ↑ snapshot

👉 ❌ 不是内存问题

📍看:
online-TiKV-Details


🧠 三、真正“内存瓶颈”的标准画像

✔ 典型组合(生产最准确)

block cache miss ↑↑
+ read IO ↑
+ latency ↑
+ CPU不一定高
+ 没有scan暴涨

✔ 进一步确认(强信号)

信号含义
cache miss持续上升 数据放不住
IO read增加 fallback磁盘
latency逐步变高 读路径退化

🧭 四、完整判断路径(你这个Grafana体系)

online-Overview↓
online-Performance-Read↓
是否scan(关键分界)↓
online-TiKV-Raw(cache miss)↓
online-Disk-Performance(IO是否上升)↓
online-TiKV-Details(CPU/线程)↓
online-PD(排热点)

🎯 五、一句话工程结论

✔ 内存瓶颈不是“内存低”,而是:

❗ cache miss → IO 放大 → latency 上升 的链式反应


⚡ 六、最关键判断口诀(生产直接用)

✔ 真内存问题:

miss ↑ + IO ↑ + latency ↑ + scan不明显

❌ 不是内存问题:

miss ↑ 但 scan ↑(SQL问题)

IO ↑ 但 miss正常(磁盘/compaction)


🚀 如果你要继续提升

我可以帮你做一个更强的:

👉 “TiKV 内存 / IO / scan 三大误判一页纸对照图(生产必备)”

或者:

👉 “3秒判断是不是内存瓶颈的决策树(YES/NO版)”