--- title: "Load average alto en Linux: qué significa y cómo resolverlo" description: "Aprende a interpretar el load average en Linux, distinguir si la carga viene de CPU, disco o memoria con vmstat, iostat y pidstat, y corregir la causa real." category: "Guía de Solución de Problemas" language: es source: https://cubepath.com/es/docs/guía-de-solución-de-problemas/promedio-de-carga-alto-que-significa-y-como-solucionarlo updated: 2026-09-25 --- # Load average alto en Linux: qué significa y cómo resolverlo 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: ```bash uptime ``` ```output 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: ```bash nproc ``` ```output 4 ``` | Load average en 4 vCPU | Interpretación | |---|---| | Menor que 4 | Hay CPU libre; no hay cola | | Alrededor de 4 | El sistema está usando toda su capacidad | | Claramente mayor que 4 de forma sostenida | Hay 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`: ```bash sudo apt update sudo apt install sysstat ``` Comprueba que están disponibles: ```bash iostat -V ``` ```output 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: ```bash vmstat 1 5 ``` ```output 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: | Columna | Qué indica | Si es alta | |---|---|---| | `r` | Tareas ejecutables (estado R) | Mayor que `nproc`: la CPU es el cuello de botella | | `b` | Tareas bloqueadas (estado D) | Hay procesos esperando E/S | | `us`, `sy` | % de CPU en usuario y kernel | Carga de CPU real | | `wa` | % de tiempo esperando E/S | El disco no da abasto | | `st` | % de CPU robada por el hipervisor | En un VPS, el host físico está sobrecargado | | `si`, `so` | Páginas que entran y salen de swap | Falta 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: ```bash cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory ``` ```output 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`: ```bash pidstat -u 1 5 ``` Al final aparece la media del periodo: ```output 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: ```bash 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: ```bash 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: ```bash sudo systemctl set-property backup.service CPUQuota=100% ``` Comprueba que el límite se ha aplicado: ```bash systemctl show backup.service -p CPUQuotaPerSecUSec ``` ```output CPUQuotaPerSecUSec=1s ``` ## Paso 4: Resolver una carga de disco Si `vmstat` mostró `b` y `wa` altos, localiza primero qué dispositivo está saturado: ```bash iostat -xz 1 3 ``` ```output 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: ```bash sudo pidstat -d 1 5 ``` ```output 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`): ```bash 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: ```bash 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: ```bash free -h ``` ```output 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: ```bash ps -eo pid,user,rss,args --sort=-rss | head -n 6 ``` Revisa también si el OOM killer ha actuado: ```bash 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. > Advertencia: `echo 3 > /proc/sys/vm/drop_caches` no soluciona una carga alta. Vacía la caché de página, que es memoria que el kernel ya libera solo cuando la necesita, y obliga a volver a leer del disco todo lo que estaba en caché. ## 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: ```bash 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: ```bash sar -q ``` ```output 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.