El load average es la métrica que muestran uptime y top, y una de las peor interpretadas en Linux: un valor alto no significa necesariamente que la CPU esté saturada. En esta guía aprenderás qué mide exactamente, cuándo un valor es realmente alto para tu servidor y cómo averiguar, paso a paso, si la carga viene de la CPU, del disco o de la falta de memoria. Los comandos son para Ubuntu 24.04 y funcionan igual en Debian 12.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS o Debian 12, por ejemplo un VPS de CubePath.
  • Un usuario no root con privilegios sudo.
  • Idealmente, acceso al servidor mientras la carga está alta: la mayoría de las herramientas muestran el estado actual.

Qué mide el load average

Linux calcula el load average como la media del número de tareas que están:

  • En ejecución o esperando CPU (estado R).
  • En espera no interrumpible (estado D), normalmente bloqueadas esperando al disco o a un sistema de archivos de red como NFS.

Por eso un servidor puede tener un load average de 20 con la CPU casi ociosa: basta con que 20 procesos estén esperando a un disco lento.

Los tres números son medias móviles exponenciales de 1, 5 y 15 minutos:

uptime

 10:42:17 up 12 days,  3:05,  1 user,  load average: 6.12, 3.40, 1.85

Leídos de izquierda a derecha cuentan una historia. En el ejemplo, la carga del último minuto (6.12) es muy superior a la de 15 minutos (1.85): el problema acaba de empezar y va a más. Si los tres valores fueran parecidos y altos, sería un problema sostenido; si el primero fuera el más bajo, el sistema se estaría recuperando.

Cuándo es "alto"

El load average solo tiene sentido comparado con el número de CPU:

nproc

4
Load average en 4 vCPUInterpretación
Menor que 4Hay CPU libre; no hay cola
Alrededor de 4El sistema está usando toda su capacidad
Claramente mayor que 4 de forma sostenidaHay tareas esperando: el servidor va con retraso

Un pico breve por encima del número de CPU (un cron, una compilación) es normal. Lo que merece investigación es una carga de 5 y 15 minutos por encima de nproc junto a síntomas reales: latencia en la web, SSH lento o timeouts.

Paso 1: Instalar las herramientas de diagnóstico

vmstat, ps y top vienen con el sistema. iostat, pidstat, mpstat y sar están en el paquete sysstat:

sudo apt update
sudo apt install sysstat

Comprueba que están disponibles:

iostat -V

sysstat version 12.6.1

Paso 2: Averiguar el tipo de carga con vmstat

vmstat resume en una línea por segundo todo lo que necesitas para clasificar la carga. Ejecútalo con un intervalo de 1 segundo y 5 muestras:

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 7  0      0 412300  51200 2203400    0    0     4    36 2210 3900 93  6  1  0  0
 8  0      0 411900  51200 2203420    0    0     0    12 2305 4012 94  5  1  0  0
 6  0      0 411500  51200 2203460    0    0     0    48 2198 3880 92  7  1  0  0

La primera línea son medias desde el arranque; fíjate en las siguientes. Las columnas clave son:

ColumnaQué indicaSi es alta
rTareas ejecutables (estado R)Mayor que nproc: la CPU es el cuello de botella
bTareas bloqueadas (estado D)Hay procesos esperando E/S
us, sy% de CPU en usuario y kernelCarga de CPU real
wa% de tiempo esperando E/SEl disco no da abasto
st% de CPU robada por el hipervisorEn un VPS, el host físico está sobrecargado
si, soPáginas que entran y salen de swapFalta memoria

Con esa tabla, el diagnóstico suele encajar en uno de estos casos:

  • CPU: r alto, us + sy cerca de 100, id cerca de 0. Sigue en el paso 3.
  • Disco (E/S): b alto, wa alto, CPU con id alto. Sigue en el paso 4.
  • Memoria: si y so distintos de cero de forma continuada. Sigue en el paso 5.
  • Steal time: st sostenido por encima de 10. Consulta la sección de solución de problemas.

Como comprobación adicional, el kernel de Ubuntu 24.04 expone la presión de recursos (PSI), que mide directamente cuánto tiempo pasan las tareas esperando cada recurso:

cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory

some avg10=78.40 avg60=61.12 avg300=30.05 total=912837465
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
some avg10=0.35 avg60=0.20 avg300=0.10 total=10238475
full avg10=0.20 avg60=0.11 avg300=0.05 total=6543210
some avg10=0.00 avg60=0.00 avg300=0.00 total=12034
full avg10=0.00 avg60=0.00 avg300=0.00 total=5321

some avg10=78.40 en cpu significa que durante el 78 % de los últimos 10 segundos al menos una tarea estuvo esperando CPU. Aquí la presión está claramente en la CPU, no en el disco ni en la memoria.

Paso 3: Resolver una carga de CPU

Identifica qué procesos consumen la CPU. pidstat muestra el uso por proceso durante un intervalo, algo más fiable que una captura instantánea de top:

pidstat -u 1 5

Al final aparece la media del periodo:

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:       33      2811   95.20    3.80    0.00   12.40   99.00     -  php-fpm8.3
Average:       33      2812   94.60    4.00    0.00   11.80   98.60     -  php-fpm8.3
Average:      999      1450   40.10    2.30    0.00    3.20   42.40     -  mysqld

La columna %wait indica cuánto tiempo pasó el proceso esperando CPU: valores altos confirman que hay más trabajo que núcleos.

Para ver con qué se lanzó el proceso y desde cuándo corre:

ps -o pid,user,etime,%cpu,args -p 2811

Según lo que encuentres:

  • Un proceso descontrolado (un script en bucle, un worker colgado): reinicia el servicio que lo lanzó, por ejemplo sudo systemctl restart php8.3-fpm, y revisa sus logs con journalctl -u php8.3-fpm --since "1 hour ago".
  • Tráfico legítimo que supera la capacidad: el servidor necesita más vCPU o hay que optimizar la aplicación (caché, consultas lentas).
  • Una tarea pesada que no es urgente (copias, compresión, informes): baja su prioridad para que no afecte al servicio:
sudo renice -n 10 -p 2811

Si la tarea pertenece a un servicio de systemd, puedes limitar su CPU de forma persistente. Este ejemplo limita backup.service al equivalente de un núcleo:

sudo systemctl set-property backup.service CPUQuota=100%

Comprueba que el límite se ha aplicado:

systemctl show backup.service -p CPUQuotaPerSecUSec

CPUQuotaPerSecUSec=1s

Paso 4: Resolver una carga de disco

Si vmstat mostró b y wa altos, localiza primero qué dispositivo está saturado:

iostat -xz 1 3

Device      r/s     w/s   rkB/s    wkB/s  r_await  w_await  aqu-sz  %util
vda       12.00  840.00  96.00  52400.00     1.20    38.50   32.10  99.60

%util cerca de 100 y tiempos de espera (r_await, w_await, en milisegundos) altos indican que el disco no absorbe la demanda. aqu-sz es la longitud media de la cola.

Averigua qué procesos generan esa E/S:

sudo pidstat -d 1 5

Average:      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
Average:        0      9120      0.00  51200.00      0.00     412  tar
Average:      999      1450     95.00    980.00      0.00      35  mysqld

Y cuáles están bloqueados ahora mismo en estado D, junto a la función del kernel donde esperan (wchan):

ps -eo stat,pid,user,wchan:32,args | awk 'NR==1 || $1 ~ /^D/'

Acciones habituales:

  • Una copia de seguridad o un tar en horario de tráfico: bájale la prioridad de E/S con ionice. La clase 3 (idle) solo usa el disco cuando nadie más lo necesita:
sudo ionice -c 3 -p 9120

Para las próximas ejecuciones, lanza la tarea directamente con ionice -c 3 nice -n 10 comando o prográmala fuera de horas punta.

  • La base de datos lee constantemente del disco: su caché es demasiado pequeña para el volumen de datos (en MySQL, innodb_buffer_pool_size); revisa también las consultas sin índice.
  • Procesos en D con wchan relacionado con nfs o rpc: el servidor NFS remoto no responde. Resuélvelo en el servidor NFS o en la red; los procesos no se pueden matar mientras sigan en estado D.
  • Logs creciendo sin control: comprueba el espacio con df -h y la actividad de escritura de journald o de la aplicación.

Paso 5: Resolver una carga por falta de memoria

Cuando falta RAM, el kernel mueve páginas a swap y las recupera continuamente. Cada fallo de página es una lectura de disco, así que la carga sube y todo se vuelve lento. Comprueba la memoria disponible:

free -h

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.6Gi        98Mi        12Mi       190Mi       112Mi
Swap:          2.0Gi       1.7Gi       300Mi

La columna que importa es available, no free. Aquí quedan 112 MiB disponibles y la swap está casi llena. Localiza los procesos que más memoria usan:

ps -eo pid,user,rss,args --sort=-rss | head -n 6

Revisa también si el OOM killer ha actuado:

sudo journalctl -k --since "24 hours ago" | grep -i "out of memory"

Las soluciones reales son reducir el consumo (menos workers de PHP-FPM o Apache, cachés de base de datos ajustadas a la RAM disponible) o ampliar la memoria del servidor. Añadir más swap evita que el OOM killer mate procesos, pero no quita la lentitud.

Paso 6: Guardar el historial de carga con sar

Muchas veces el pico ya ha pasado cuando entras al servidor. sysstat puede registrar la carga, la CPU y el disco cada 10 minutos para consultarlos después. En Ubuntu y Debian la recogida viene desactivada; actívala:

sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

Tras al menos una muestra, consulta la carga del día:

sar -q

10:00:01 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:10:01 AM         1       412      0.62      0.71      0.80         0
10:20:01 AM         9       430      7.85      4.20      2.10         3

Con sar -u ves el uso de CPU del mismo periodo y con sar -d la actividad de disco. Para consultar un día anterior, usa el archivo correspondiente en /var/log/sysstat/, por ejemplo sar -q -f /var/log/sysstat/sa24 para el día 24 del mes.

Solución de problemas

El load average es alto pero top muestra la CPU ociosa. Hay procesos en estado D. Revisa el paso 4: disco saturado, un montaje NFS colgado o un volumen con errores. Comprueba también sudo dmesg -T | tail -n 50 en busca de errores de E/S.

La columna st de vmstat es alta de forma sostenida. Tu VPS está esperando CPU física que el hipervisor asigna a otras máquinas. No se corrige desde dentro del sistema; si persiste, abre un ticket con soporte indicando las horas y los valores de st.

La carga sube cada pocos minutos a la misma hora. Suele ser un cron que se solapa consigo mismo porque cada ejecución tarda más que el intervalo. Revisa crontab -l, /etc/cron.d/ y systemctl list-timers, y protege el trabajo con flock -n /run/lock/tarea.lock comando para que no arranquen dos copias.

Hay muchos procesos zombi (estado Z). Los zombis no suman al load average ni consumen CPU; indican que su proceso padre no los recoge. Reinicia el servicio padre en lugar de intentar matarlos.

Conclusión

El load average cuenta tareas que esperan CPU o E/S, así que siempre debe leerse frente al número de CPU y acompañado de vmstat para saber qué recurso falta. Con pidstat, iostat y ps identificas el proceso responsable, y con renice, ionice o los límites de systemd reduces su impacto mientras aplicas la solución de fondo. Como siguientes pasos, deja sar registrando el historial, configura alertas sobre la carga de 15 minutos en tu sistema de monitorización y revisa si el servidor necesita más recursos cuando la carga alta es tráfico legítimo.