---
name: storage-or-io-bottleneck
description: Diagnose storage, disk IO, RocksDB, raft/apply/propose, and IO throttling root causes.
---

# Use When

Use this family subskill when the primary mechanism is device/storage engine bottleneck,
IOPS or throughput ceiling, RocksDB write stall, raft/apply/propose latency, slow score,
or disk exhaustion.

# Required Evidence

- Disk utilization, IOPS/throughput exceeded signal, or throttling metrics.
- RocksDB, raftstore, apply, propose, slow score, or write-stall evidence.
- Workload correlation showing whether IO is independent infra failure or workload-induced.

# Classification

- `standard_root_cause_class`: `storage_or_io_bottleneck`
- compatible `primary_class`: `storage_or_infra_io`
- common symptom tags: `io_saturation`, `tikv_hotspot`, `slow_query`, `network_latency`
- specialist skills: `tikv-storage`, `tikv-performance`

# Decision Rules

- Distinguish workload-induced IO saturation from independent infrastructure failure.
- If SQL scan volume caused IO saturation, classify SQL as primary unless IO started earlier
  or independently explains the incident.
- Do not treat tiny residual EBS throttle values as a storage bottleneck.
- For TiKV stall cases, distinguish impact/timing signals from mechanism signals. When evidence
  identifies an engine, disk, write-stall, or read-pool mechanism, name that mechanism instead of
  stopping at generic slow-score or warning-log wording.

# Final Response Anchors

- Say whether the bottleneck is NVMe, EBS, RocksDB, raft/apply/propose, or disk capacity.
- Explicitly state `workload-induced IO saturation` when the evidence supports that.