Qué hacer cuando el I/O de disco del VPS es muy alto (2026): iowait, iostat, iotop, bases de datos y registros

El primer paso es mirar top:

top

En la línea de CPU, mira %wa. Si %wa se mantiene alto durante mucho tiempo, significa que la CPU pasa mucho tiempo esperando a que se complete el I/O de disco.

También puedes usar:

vmstat 1

Céntrate en:

• wa: proporción de CPU esperando I/O;
• bi / bo: lecturas y escrituras de dispositivos de bloque;
• r: procesos esperando CPU;
• b: sueño ininterrumpible, común cuando se espera I/O.

Si wa es muy alto, b tampoco es bajo y la máquina se siente lenta, no te limites a mirar los registros de la aplicación.

Instala la herramienta:

sudo apt install sysstat -y

O en sistemas RHEL:

sudo dnf install sysstat -y

Ver métricas extendidas del disco:

iostat -x 1

Céntrate en estas columnas:

• %util: grado de ocupación del dispositivo;
• await: tiempo medio de espera de las solicitudes de I/O;
• r/s, w/s: solicitudes de lectura/escritura por segundo;
• rkB/s, wkB/s: rendimiento de lectura/escritura por segundo;
• aqu-sz: longitud media de la cola.

Juicio simple:

• Si %util se acerca a 100% durante mucho tiempo, el disco está muy ocupado;
• Si await aumenta claramente, la espera de I/O se ha vuelto más larga;
• Si aqu-sz se mantiene alto durante mucho tiempo, las solicitudes están en cola;
• Si el rendimiento no es alto pero await es muy alto, puede ser I/O aleatorio, un límite de IOPS o latencia del almacenamiento subyacente.

No mires solo un valor. Un iowait alto solo significa que la CPU está esperando I/O, no demuestra directamente que "el disco esté roto". Combínalo con iostat y las lecturas y escrituras a nivel de proceso.

Instala:

sudo apt install iotop -y

Ejecuta:

sudo iotop -oPa

Significado de los parámetros:

• -o: mostrar solo procesos que están generando I/O;
• -P: agregar por proceso en lugar de por hilo;
• -a: mostrar el volumen acumulado de lectura y escritura.

Procesos que suelen aparecer arriba:

• mysqld / mariadbd / postgres: lecturas y escrituras de la base de datos;
• dockerd / containerd: registros de contenedores o capas de imágenes;
• journal / rsyslogd: escritura de registros del sistema;
• backup / tar / gzip / rsync: compresión y sincronización de copias de seguridad;
• updatedb / apt / dpkg: tareas de indexación o instalación;
• Procesos de aplicación: escribiendo registros o archivos temporales sin parar.

Si un proceso en iotop sigue escribiendo mucho, no te apresures a matar el proceso; primero confirma qué está escribiendo.

iotop es muy útil para ver la situación actual, mientras que pidstat es más adecuado para ver tendencias durante un período de tiempo.

pidstat -d 1

Ver un proceso específico:

pidstat -d -p PID 1

Céntrate en:

• kB_rd/s: lecturas por segundo;
• kB_wr/s: escrituras por segundo;
• kB_ccwr/s: escrituras canceladas.

Si la escritura de una aplicación sigue siendo alta, revisa su directorio de registros, directorio de subidas y directorio de caché.

Primero mira los directorios grandes:

sudo du -xh /var/log --max-depth=1 | sort -h

Mira los registros que han cambiado rápidamente recientemente:

sudo find /var/log -type f -printf '%s %p\n' | sort -n | tail -n 20

Ver en tiempo real si un registro está creciendo sin parar:

sudo tail -f /var/log/nginx/error.log

Escenarios comunes:

• Nginx registra errores de upstream repetidamente;
• Las pilas de excepciones de la aplicación llenan la pantalla;
• Los contenedores Docker escriben registros stdout/stderr sin límite;
• fail2ban, fallos de autenticación o acceso de rastreadores provocan una explosión de registros;
• Se olvidó desactivar el registro de depuración.

Si son registros de Docker, consulta: Qué hacer cuando Docker llena el disco del VPS. Ese artículo trata sobre el uso de disco, mientras que este se centra en los bloqueos de I/O; los dos problemas suelen aparecer juntos.

Si en iotop aparece MySQL, MariaDB o PostgreSQL, no significa que la base de datos "tenga un problema"; puede que el negocio realmente esté leyendo y escribiendo, o pueden ser consultas lentas, índices faltantes, tablas temporales, checkpoints, vacuum o copias de seguridad.

Primero mira a nivel de sistema:

sudo iotop -oPa
pidstat -d -p $(pidof mysqld) 1
pidstat -d -p $(pidof postgres) 1

Luego mira los registros de la base de datos:

sudo journalctl -u mysql -n 100 --no-pager
sudo journalctl -u mariadb -n 100 --no-pager
sudo journalctl -u postgresql -n 100 --no-pager

Causas comunes:

• Falta de índices que provoca muchas lecturas aleatorias;
• Consultas que generan grandes tablas temporales;
• Tareas de copia de seguridad que chocan con las horas punta del negocio;
• Alta presión de escritura de binlog / WAL;
• La escritura de la base de datos se ralentiza cuando el disco está casi lleno;
• Memoria insuficiente que provoca una baja tasa de aciertos de caché.

Si no se puede conectar a la base de datos o el servicio no arranca, puedes consultar los artículos específicos de MySQL, PostgreSQL y Redis respectivamente; aquí primero determinamos si el I/O lo causa la base de datos.

Los VPS con poca memoria encuentran fácilmente thrashing de swap. En apariencia es I/O de disco alto, pero la causa raíz es memoria insuficiente, y el sistema intercambia páginas de memoria de entrada y salida con frecuencia.

Comprueba:

free -h
swapon --show
vmstat 1

En vmstat, mira:

• si: swap in;
• so: swap out.

Si si/so se mantiene distinto de 0 de forma continua y %wa es alto al mismo tiempo, el swap participa en el bloqueo.

Como mitigación temporal, puedes detener servicios innecesarios, reducir la concurrencia y escalonar tareas. A largo plazo, aún hay que optimizar la memoria, añadir caché, actualizar el plan o separar la base de datos y la aplicación.

Muchos picos de I/O los creamos nosotros mismos.

Por ejemplo:

tar -czf backup.tar.gz /var/www /var/lib/mysql
rsync -av /data remote:/backup
mysqldump app > app.sql
docker save image > image.tar

Si estas tareas coinciden con las horas punta del negocio, las escrituras de la base de datos y la rotación de registros, el VPS se atasca fácilmente.

Diagnostica las tareas programadas:

crontab -l
sudo crontab -l
systemctl list-timers --all

Mira los registros recientes:

journalctl --since "2 hours ago" --no-pager

Si lo provoca una tarea programada, consulta: Qué hacer cuando las tareas programadas del VPS no se ejecutan; los métodos de diagnóstico de allí también sirven para encontrar "quién está generando I/O periódicamente".

En escenarios Docker, el I/O alto suele venir de dos lugares:

1. Los registros de contenedores escriben sin parar;
2. La capa overlay2 escribe archivos temporales con frecuencia.

Primero mira el estado de los contenedores:

docker ps --size

Mira el tamaño de los registros:

sudo du -xh /var/lib/docker/containers --max-depth=2 | sort -h | tail -n 20

Mira si los registros de un contenedor están inundando:

docker logs 容器名 --tail 100

Si el negocio lo permite, configura la rotación de registros para Docker, por ejemplo max-size y max-file en json-file. No dejes que un contenedor anómalo arrastre el disco y el I/O del host.

Si ya has confirmado:

• No hay procesos evidentes de escritura masiva;
• La presión de la base de datos y los registros no es alta;
• El swap no tiene thrashing evidente;
• Las tareas de copia de seguridad no están en ejecución;
• Pero await es alto durante mucho tiempo, %util es alto, y SSH y todas las aplicaciones se atascan juntos;
• Es más evidente en horas punta de la noche, o los usuarios del mismo nodo también reportan lentitud;

Entonces puede ser contención del almacenamiento del host, límites de IOPS o impacto de vecinos.

En este momento, no envíes solo "el disco va lento". Adjunta pruebas al ticket del proveedor:

date
uptime
vmstat 1 10
iostat -x 1 10
sudo iotop -oPa -b -n 5
free -h
df -h

Si haces pruebas con fio, ten cuidado de no hacer pruebas de estrés al disco de producción sin criterio durante las horas punta del negocio. En un VPS pequeño, fio puede ralentizar aún más el negocio.

Cuando encuentres I/O de disco alto o iowait alto en el VPS, comprueba en este orden:

1. Usa top para ver si %wa se mantiene alto.
2. Usa vmstat 1 para ver wa, b, bi/bo y si/so.
3. Usa iostat -x 1 para ver %util, await y aqu-sz.
4. Usa iotop -oPa para encontrar los procesos que están leyendo y escribiendo.
5. Usa pidstat -d 1 para ver la tendencia de lectura y escritura de los procesos.
6. Usa du -xh /var/log para comprobar si los registros están explotando.
7. Revisa la base de datos, Docker, copias de seguridad, compresión y tareas de sincronización.
8. Usa free -h, swapon --show y vmstat para determinar el thrashing de swap.
9. Escalona las tareas pesadas, limita los registros y optimiza las consultas y la caché de la base de datos.
10. Cuando no haya causa local, lleva pruebas de iostat/vmstat/iotop al proveedor.

Cuando el I/O de disco del VPS es alto, no mires solo la CPU y no reinicies directamente. Primero usa top y vmstat para confirmar si es iowait, luego usa iostat -x para juzgar la latencia y las colas del disco, y finalmente usa iotop y pidstat para encontrar el proceso específico.

La mayoría de los problemas terminan siendo explosión de registros, lecturas y escrituras aleatorias en la base de datos, registros de Docker, thrashing de swap, choque de tareas de copia de seguridad o contención del almacenamiento del host. Si puedes localizar el proceso, primero corrige la máquina local; si no puedes localizar una causa local, entonces lleva métricas completas al proveedor, para que el ticket tenga fuerza.