The USE method & finding bottlenecks

A repeatable way to locate the constraint.

Performance problems are usually solved backwards — people guess a cause and start tuning, when the fast path is to methodically find the actual bottleneck first. The USE method gives you that method: for every resource (CPU, memory, disk, network), check three things — Utilization (how busy it is), Saturation (how much work is queued waiting for it), and Errors. Walk the resources, and the one that is saturated or erroring is your constraint. It turns "the server is slow" into a short, repeatable checklist.

The 60-second triage

Before deep tools, a fixed sequence of quick commands orients you in a minute: uptime for load trend, dmesg for recent errors, vmstat for CPU/memory/swap flow, and a glance at disk and network. This is the "first 60 seconds" checklist popularized by performance engineers — it tells you which resource to zoom into, so you spend your investigation where the problem actually is instead of tuning at random.

$ uptime                        # load trend (1/5/15 min) — rising or falling?
 load average: 8.10, 5.22, 3.15   # climbing, and > CPU count = something is queuing
$ dmesg -T | tail                # recent kernel errors (OOM kills, IO errors)?
$ vmstat 1 5                     # r=run queue, si/so=swap, wa=IO wait, per second
$ mpstat -P ALL 1 3              # per-CPU utilization (is it one hot core or all?)

Read the constraint, then confirm the cause

The method finds the constrained resource; the next step is finding what is consuming it. High CPU utilization plus a high run queue points to CPU-bound work — then top or pidstat names the process. High IO wait points to disk — then iostat and iotop find the offender. The discipline is: identify the saturated resource first (USE), then drill into who is using it, rather than jumping straight to a process and guessing. The following lessons cover the per-resource tools.