---
name: resource-control-or-capacity
description: Diagnose resource control, RU throttling, capacity reduction, worker loss, and node-count bottlenecks.
---

# Use When

Use this family subskill when the primary mechanism is insufficient effective capacity,
RU/resource-group throttling, worker/coprocessor capacity loss, node-count reduction,
scale-in, or quota bottleneck.

# Required Evidence

- Node count, CPU quota, RU/resource group, worker count, scale event, or peer/baseline
  capacity comparison.
- Evidence that no single SQL/lock/IO mechanism explains the primary symptom better.
- Per-node or nodegroup comparison when capacity skew is the claim.

# Classification

- `standard_root_cause_class`: `resource_control_or_capacity`
- compatible `primary_class`: `resource_control_or_capacity`
- common symptom tags: `capacity_pressure`, `high_cpu`, `slow_query`, `tikv_hotspot`, `gc_signal`
- specialist skills: `pd-resource-control`, `tikv-scale`, `autoscaler-dashboard`

# Decision Rules

- In nodegroup comparison cases, do not promote a modest top SQL into primary root cause
  unless one digest independently explains most of the differential.
- Treat TopSQL, GC, and TiKV hotspots as secondary when they are carried by reduced capacity.
- For RU/resource control cases, include queue time, available RU, or throttling evidence.

# Final Response Anchors

- For node-count cases, explicitly say `node count reduction`, `fewer TiDB nodes`, or
  `capacity reduction`.
- Recommend restoring capacity, scale adjustment, resource group/RU tuning, or workload
  redistribution before cache tuning.