# TiKV Storage And IO

## Question

Is the visible latency produced by TiKV storage/raft apply work, and what
engine, disk, snapshot, ingest, compaction, or throttle boundary explains it?

## Enter When

Use for one slow TiKV, IO jitter, disk long-tail latency, RocksDB stall,
compaction backlog, snapshot/ingest delay, flow control, or apply/raft wait.

## First Batch

1. Locate the slow TiKV and direct request/gRPC/result latency on exact samples.
2. Follow the same samples through raft append/apply or engine/RocksDB latency.
3. Compare node/disk latency and the strongest alternative: hotspot/workload
   change, scheduler contention, or a peer.

## Decision

One slow TiKV and a short anomaly are useful clues, not proof of storage
jitter. Require a matching internal storage/raft signal and disk or engine
counterpart. Separate producer backlog from consumer latency: a wait metric can
rise because work is queued even when the downstream operation remains normal.

## Strongest Alternative And Stop

Check workload/hotspot change on the same TiKV and interval. Stop at the first
confirmed engine/disk/raft boundary or one exact missing aligned signal; do not
inventory every RocksDB and host metric.