Llevo años administrando servidores Linux y te diré algo que aprendí a las malas: casi ninguna caída de servicio llega sin aviso. El aviso suele estar ahí, en el consumo de recursos, horas antes de que tu WordPress se vuelva lento o la memoria se sature. Las dos herramientas básicas para leer ese aviso son top y htop, ambas disponibles por defecto o instalables en segundos en cualquier distribución. Aquí va una guía para interpretar sus datos, cazar procesos problemáticos y actuar antes de que un pico de carga acabe en avería.
Índice
Qué es top y cómo interpretar su salida
El comando top viene de serie en casi todas las distribuciones. Muestra en tiempo real los procesos del sistema, ordenados por consumo de CPU por defecto. Se ejecuta así:
- top — abre el monitor en modo interactivo.
- top -u www-data — filtra solo los procesos del usuario de tu servidor web (útil si tienes Apache o Nginx).
- top -d 2 — actualiza cada 2 segundos en lugar de cada 3 por defecto.
La cabecera es donde está la información de verdad. Hay tres zonas que conviene mirar con lupa:
La línea de carga del sistema (load average)
Aparece como load average: 1.25, 0.90, 0.75: carga media en los últimos 1, 5 y 15 minutos. La regla práctica es simple. Si el valor supera el número de núcleos de CPU, el servidor está saturado. En una máquina con 4 núcleos, una carga sostenida de 5 o más es señal de problema.
La línea de memoria (MiB Mem y MiB Swap)
Distingue entre memoria usada, libre y en caché. Un detalle que despista a mucha gente: Linux aprovecha la RAM libre como caché de disco, así que poca memoria «free» no significa nada grave por sí solo. Lo crítico es el swap. Si crece de forma sostenida, el servidor se ha quedado sin RAM real y el rendimiento se irá al traste.
El área de procesos
Cada fila muestra un proceso con PID, usuario, %CPU, %MEM, tiempo de ejecución y comando. Pulsa P para ordenar por CPU, M por memoria, y k si necesitas matar un proceso sin salir de la interfaz.
htop: la alternativa moderna para monitorizar recursos
top es universal, sí. Pero htop se lee mucho mejor: barras de color para CPU y memoria, navegación con flechas, soporte de ratón. En muchas distribuciones no viene preinstalado, aunque instalarlo toma un momento:
- Debian/Ubuntu: sudo apt install htop
- CentOS/RHEL/AlmaLinux: sudo yum install htop
Ventajas prácticas de htop sobre top
- Visualización por núcleo: cada CPU aparece como barra independiente, ideal para ver si un solo núcleo está al 100% (típico de un proceso PHP mal optimizado) o si la carga está repartida.
- Búsqueda de procesos: F3 busca por nombre, por ejemplo «mysqld» o «php-fpm».
- Árbol de procesos: pulsa F5 y verás qué proceso generó a cuál. Muy práctico para localizar scripts colgados.
- Gestión sencilla: seleccionas un proceso con las flechas, pulsas F9 y envías una señal (SIGTERM por defecto). Sin memorizar PIDs.
Casos reales: cómo detectar problemas frecuentes
Proceso que consume el 100% de CPU
Localiza el proceso con top u htop y anota su PID. Si es un proceso de PHP-FPM o un script PHP, lo más probable es que haya un plugin de WordPress con un bucle infinito o un ataque de fuerza bruta detrás. Puedes detenerlo temporalmente con kill -15 PID. ¿Reaparece? Entonces toca revisar los logs en /var/log/ y el access log del servidor web.
Memoria RAM agotada y swap activo
Si el %MEM acumulado supera el 90% y la swap crece, mira qué procesos consumen más memoria. En servidores WordPress el sospechoso habitual es MySQL/MariaDB: revisa las variables innodb_buffer_pool_size y max_connections. Bajar max_connections de 500 a 150, por poner un ejemplo, puede liberar cientos de megabytes en un VPS pequeño.
Carga alta sin consumo de CPU aparente
Este caso despista a más de uno. Carga alta, CPU baja: el cuello de botella suele estar en la E/S de disco. Comprueba la columna wa (iowait) en la línea de CPU de top; valores sostenidos por encima del 20% indican que el disco no da abasto. Cuando eso pasa, toca plantearse migrar a NVMe o añadir caché a nivel de aplicación.
Automatiza la monitorización: no dependas solo de mirar
top y htop son diagnóstico en tiempo real. Nadie está delante de un terminal las 24 horas (o no debería). Conviene complementarlos con:
- Alertas por carga: un script con cron que ejecute uptime y te envíe un correo si la carga pasa un umbral definido.
- Monitorización histórica: herramientas como Netdata, Zabbix o Prometheus para conservar gráficas y detectar patrones.
- Registros de procesos consumidos: combina htop con atop, que guarda snapshots del sistema y permite analizar qué pasó tras un incidente.
Buenas prácticas al monitorizar consumo de recursos
- Establece una línea base: conoce los valores normales de carga, RAM y CPU de tu servidor en horas valle y pico.
- No mates procesos críticos (mysqld, nginx, sshd) sin entender antes qué hacen; usa SIGTERM (15) antes que SIGKILL (9).
- Revisa la carga cada 15 minutos, no cada minuto. Los picos puntuales son normales.
- Documenta cada incidente con PID, hora y proceso implicado. Los patrones recurrentes solo se ven con historial.
¿Cuál es mejor, top o htop?
htop es más cómodo y visual para el día a día; top es universal y no requiere instalación. Lo ideal: conocer ambos.
¿Cuánta carga de CPU es normal?
Como referencia, una carga inferior al número de núcleos del servidor se considera saludable. Sostenida por encima, saturación.
Conclusión
Saber leer top y htop es una habilidad básica que te adelanta a la mayoría de incidentes: procesos desbocados, memoria agotada, discos saturados. Empieza familiarizándote con la salida de top, instala htop para el trabajo diario, fija tu línea base de rendimiento y automatiza alertas. Y si prefieres no lidiar con terminales, logs y ajustes de rendimiento, en RedServicio (redservicio.net) encontrarás ayuda profesional para optimizar y mantener tu servidor o tu WordPress.
