Observa la utilización y saturación de recursos, luego confirma con medición. Un enfoque sistemático — el método USE (Utilization, Saturation, Errors) — revisa cada recurso para que no culpes al incorrecto.
Para cada recurso (CPU, memoria, disco, red), haz tres preguntas:
UTILIZATION → how busy is it (% time in use)?
SATURATION → how much queued/waiting work (load, run queue, swap)?
ERRORS → any errors (dropped packets, disk errors, OOM kills)?
→ a resource that is saturated, not just busy, is usually the bottleneck.
Cada recurso tiene una firma distintiva que puedes leer con herramientas estándar:
CPU → top/htop: high %us or load > #cores, run queue backed up
MEMORY → free/vmstat: low free RAM + high SWAP in/out (si/so) → swapping = thrashing
DISK I/O→ iostat/vmstat: high %iowait, %util ~100%, high await → I/O-bound
NETWORK → iftop/sar/ss: bandwidth saturated, retransmits, high latency
Las distinciones clave: carga alta con %us alto significa CPU limitada; swapping (si/so) significa presión de memoria; %iowait alto significa que la CPU está inactiva esperando disco; latencia/retransmisiones altas apuntan a la red.
$ vmstat 1
r b swpd free si so bi bo us sy id wa
8 0 0 120m 0 0 12 20 92 6 2 0 ← CPU-bound (id=0, wa=0)
1 3 800m 30m 40 120 900 8 5 3 2 90 ← I/O + swap (wa=90, so>0)
Nunca te detengas en un número. Perfila el proceso (ej. perf, un perfilador de CPU/heap) para encontrar la función o asignación caliente, cambia una cosa, y vuelve a medir. Los síntomas pueden engañar — alta CPU podría ser realmente una espera ocupada causada por contención de cerrojos, no trabajo real.
Reparar el recurso incorrecto (agregar RAM a una máquina limitada por CPU) desperdicia dinero y no ayuda. El método USE más la herramienta correcta aísla la restricción real rápidamente, y la remeasuración confirma que la corrección movió la aguja.