---
name: tikv-hotspot-or-coprocessor
description: Diagnose TiKV store-local hotspots, coprocessor/unified-read saturation, and hotspot attribution.
---

# Use When

Use this family subskill when the primary mechanism is a TiKV store-local read/write,
coprocessor, unified-read, scheduler, raftstore, or gRPC hotspot that is not better
explained by a single SQL plan or independent storage failure.

# Required Evidence

- Hot TiKV instance(s) with CPU, gRPC P99, thread CPU, or peer-skew evidence.
- Thread pool attribution such as `cop`, `coprocessor`, `unified-read`, `grpc`, `raftstore`,
  `scheduler`, or `apply`.
- Region/key/table/query attribution when available.

# Classification

- `standard_root_cause_class`: `tikv_hotspot_or_coprocessor`
- compatible `primary_class`: `tikv_read_hotspot`
- common symptom tags: `tikv_hotspot`, `network_latency`, `slow_query`, `high_cpu`
- specialist skills: `tikv-performance`, `tikv-slow-diagnosis`

# Decision Rules

- If one SQL digest dominates CPU on the hot TiKV instance and aligns with timeline, classify
  SQL as primary and TiKV hotspot as contributing.
- If hotspot evidence is store-local and not attributable to one query, keep this class primary.
- Distinguish read/coprocessor hotspot from write/raftstore/storage bottleneck before finalizing.
- Slow score, RPC latency skew, and warning logs are strong evidence for affected store and
  timing. Treat them as symptoms unless they are the most specific available mechanism; when
  evidence identifies a narrower pool, scheduler, Raft, or storage path, classify that mechanism.

# Final Response Anchors

- Name the hot TiKV instance(s), thread pool, gRPC/CPU magnitude, and whether the hotspot is
  primary or downstream.
- Avoid vague `TiKV is slow`; state the exact pool or mechanism.