linux-performancelisted

# Linux Performance Find which resource is saturated before changing anything, using utilisation, saturation and errors for each one. ## Purpose **Use this when:** - A host is slow but not failing: high latency, low throughput, no errors. - Latency regressed and you need to know whether the cause is CPU, memory, disk or the application. - Someone proposes resizing an instance or adding replicas without evidence. - A container is slow and the container's own metrics look fine. **Do not use this when:** - The host is out of a resource entirely (disk full, OOM) — use `linux-troubleshooting`. - The latency is in network round trips — use `linux-network-debugging`. - The workload is in Kubernetes and the suspicion is cgroup limits — use `kubernetes-resource-debugging`, which measures throttling directly. **What this skill assumes:** shell access, and ideally `sysstat` (`sar`, `iostat`, `pidstat`). If those are unavailable, `/proc` gives you most of the same numbers; the skill notes where. ## Operating Procedure Work the USE method: for each resource, measure **U**tilisation, **S**aturation and **E**rrors. Utilisation alone is misleading — a disk at 100% utilisation with 0.2ms latency is fine, and a CPU at 40% with a run queue of 30 is not. 1. **Define slow.** Which operation, measured where, how much worse than what baseline? "The site is slow" is not a starting point. 2. **Take a 60-second system snapshot** covering all four resources. 3. **Identify the saturated r