Cómo identificar scripts que consumen CPU y RAM en Linux con el comando "htop"

En servidores Linux, el comando htop es una de las herramientas más prácticas para monitorear en tiempo real qué scripts están consumiendo excesivamente la CPU y la memoria RAM. Observando las columnas CPU%, MEM%, PID, USER, TIME+ y COMMAND en la pantalla de htop, podrás detectar qué procesos PHP, Python, Node.js, cron, bases de datos o del sistema están sobrecargando el servidor; así, podrás investigar el propietario del proceso, la ruta del archivo y su función para actuar con seguridad.

Ya sea un hosting compartido, VPS, VDS o servidor dedicado, gran parte de las ralentizaciones repentinas se deben a scripts que corren sin control. Por ejemplo, un plugin defectuoso de WordPress, un archivo PHP en un bucle infinito, una tarea cron que consume mucho, una consulta a base de datos mal optimizada o un archivo web comprometido pueden llevar el uso de la CPU al 100% en minutos. Cuando el consumo de RAM aumenta, los servicios pueden colgarse, las conexiones MySQL caer, los sitios web mostrar errores 503 o el núcleo de Linux (OOM Killer) terminar procesos para liberar memoria.

En esta guía, comenzaremos con la instalación de htop, explicaremos cómo interpretar su pantalla, cómo identificar scripts que explotan CPU y RAM, cómo encontrar la ruta del archivo a partir del PID y cómo intervenir de forma segura. También trataremos aspectos de seguridad, revisión de cron, análisis de logs y recomendaciones para evitar que el problema vuelva a ocurrir. Si tu servidor sufre frecuentemente de limitaciones de recursos, te recomendamos revisar también nuestras páginas sobre Paquetes de servidor VPS y hosting web de alto rendimiento para evaluar tu infraestructura.

¿Qué es htop y por qué es mejor que el comando top?

htop es una herramienta interactiva para monitorear procesos en sistemas Linux desde la terminal. Se parece al clásico comando top, pero ofrece una interfaz más legible, indicadores de recursos a color, ordenamiento sencillo, búsqueda, filtros y gestión de procesos integrada. Por eso, muchos administradores de sistemas lo prefieren para diagnósticos rápidos en servidores en producción.

Con htop puedes ver en tiempo real:

• Porcentaje de CPU usado por cada proceso
• Porcentaje de RAM y cantidad de memoria usada por proceso
• PID (identificador único del proceso)
• Usuario que ejecuta el proceso
• Nombre del comando o script
• Tiempo de ejecución y prioridad
• Load average, RAM total, swap y uso de núcleos de CPU

En un entorno de hosting donde conviven múltiples sitios, usuarios o servicios, no basta con ver el uso total de recursos. Es crucial identificar qué usuario, sitio web, tarea cron o archivo script está generando el problema. En este punto, el comando htop ofrece un diagnóstico ágil y efectivo.

Instalación de htop: comandos según la distribución

En muchas distribuciones Linux modernas, htop no viene preinstalado. Si tienes permisos root o sudo, puedes instalarlo en segundos. Antes de instalar, es recomendable actualizar la lista de paquetes para evitar errores, especialmente en servidores recién configurados.

Instalación en servidores Ubuntu y Debian

En sistemas basados en Ubuntu o Debian, utiliza:

sudo apt update

sudo apt install htop -y

Luego, ejecuta htop para abrir la herramienta. Si no cuentas con permisos sudo, deberás solicitar ayuda al proveedor de hosting. En VPS gestionables, normalmente tendrás acceso root.

Instalación en AlmaLinux, Rocky Linux, CentOS y RHEL

En sistemas basados en RHEL, el gestor de paquetes puede ser dnf o yum, según la versión:

sudo dnf install htop -y

En CentOS antiguos puede ser necesario habilitar el repositorio EPEL:

sudo yum install epel-release -y

sudo yum install htop -y

Si la instalación fue exitosa, al escribir htop verás una pantalla colorida con información en vivo. Si estás empezando con administración Linux, nuestro guía de comandos de Linux es un buen punto de partida.

Cómo interpretar la pantalla de htop: significado de las columnas

Al abrir htop, en la parte superior aparecen los núcleos de CPU, RAM, swap, número de tareas, threads, load average y tiempo activo del sistema. En la parte inferior se listan los procesos activos. Para diagnóstico, las columnas más usadas son:

Es importante destacar que un pico momentáneo en CPU no siempre es problema: pueden ser tareas legítimas como backups, optimización de imágenes, limpieza de caché o picos de tráfico. El verdadero problema es cuando un proceso consume CPU o RAM de forma sostenida, el load average supera ampliamente el número de núcleos y los servicios web dejan de responder.

Detectar scripts que consumen CPU usando htop

Para encontrar scripts que saturan la CPU, ordena los procesos por la columna CPU%. Puedes hacerlo presionando F6 y seleccionando CPU% o, si tu terminal lo permite, haciendo clic en el encabezado de la columna. Los procesos que aparecen arriba son los que más CPU usan en ese momento.

Paso 1: Ordena por CPU%

En htop, ordena los procesos según el uso de CPU. Si ves que procesos como php-fpm, php, python3, node, java, mysqld o bash se mantienen en los primeros puestos, anota sus datos. En sistemas con un solo núcleo, 100% es el máximo; en sistemas con múltiples núcleos, un proceso puede superar 100% según cuántos núcleos use simultáneamente.

Paso 2: Anota el PID y el USER

Registra el PID y el usuario que ejecuta el proceso. Por ejemplo, si ves PID 24819, USER siteuser y COMMAND php /home/siteuser/public_html/wp-cron.php, lo más probable es que el problema esté relacionado con un cron o mecanismo de WordPress. Si la columna COMMAND está truncada, activa la opción para mostrar la línea completa o usa el comando ps para más detalles.

Paso 3: Visualiza el comando completo

Para ver la línea completa del proceso usando su PID, ejecuta:

ps -fp PID

Ejemplo:

ps -fp 24819

Esto suele mostrar el archivo exacto que está ejecutando el script. Por ejemplo, si ves php /home/usuario/public_html/index.php, puede tratarse de una petición web normal. Si aparece un archivo dentro de un plugin desconocido, puede ser un problema de ese complemento.

Paso 4: Verifica la ruta y archivos abiertos

Para saber qué archivos tiene abiertos un proceso, utiliza lsof:

lsof -p PID

Esta información revela bibliotecas, logs o conexiones de red usadas. En un entorno de hosting, con esto puedes identificar qué sitio está activo. Si detectas archivos PHP con nombres sospechosos dentro de /home/example/public_html/wp-content/uploads, puede ser indicio de infección. En estos casos, no basta con matar el proceso: debes limpiar archivos, cambiar contraseñas, actualizar plugins y hacer un escaneo de seguridad. Para configuraciones SSL seguras, consulta soluciones de certificados SSL.

Detectar scripts que consumen RAM usando htop

Los problemas de memoria pueden ser más difíciles de notar que los de CPU. Cuando la CPU sube, suele sentirse una ralentización inmediata; pero la falta de RAM puede provocar cierres inesperados, uso intensivo de swap y latencias en todo el sistema. Ordena los procesos por la columna MEM% para identificar los que más memoria consumen.

Entendiendo MEM%, RES y swap

Por defecto, htop muestra MEM%, pero en algunas configuraciones también puede mostrar VIRT, RES y SHR. El valor RES es especialmente relevante porque indica la memoria física realmente usada por el proceso. El valor VIRT refleja memoria reservada pero no necesariamente usada, por lo que puede inducir a error si se interpreta solo.

Por ejemplo, en un VPS con 4 GB de RAM, un proceso PHP que consume 900 MB RES es anormal. Un aumento de 200 MB a 1.5 GB en un proceso Node.js puede indicar fuga de memoria. En bases de datos MySQL o MariaDB, un uso elevado de RAM puede ser cache legítimo, pero debe evaluarse junto con el rendimiento y configuración del servidor.

Causas típicas de alto consumo de RAM

• Códigos PHP, Python o Node.js en bucles infinitos
• Carga en memoria de archivos grandes como CSV, XML o JSON de golpe
• Plugins y funciones no optimizados en WordPress
• Procesos de manipulación de imágenes, generación de PDFs o conversión de video
• Consultas repetitivas por falta de caché adecuada
• Alta concurrencia por bots o ataques que ejecutan el mismo script muchas veces
• Servicios de larga duración con fugas de memoria

En estos casos, matar el proceso con kill es solo un alivio temporal. La solución requiere analizar qué hace el script, qué datos recibe y por qué no libera memoria.

Búsqueda, filtrado y vista en árbol dentro de htop

Si hay cientos de procesos, buscar manualmente es complicado. htop ofrece atajos útiles: F3 para buscar texto, F4 para aplicar filtros y F5 para cambiar a vista en árbol, que muestra la relación padre-hijo de procesos. Así puedes distinguir mejor procesos hijos de php-fpm, scripts lanzados por cron o servicios Node.js controlados por supervisor.

Ejemplos prácticos de filtros

• Escribe php para ver solo procesos PHP.
• Escribe python para filtrar scripts Python.
• Escribe wp-cron para revisar tareas cron de WordPress.
• Escribe node para examinar aplicaciones Node.js.
• Filtra por nombre de usuario para ver procesos de una cuenta específica.

Estos filtros ahorran mucho tiempo en servidores multiusuario con decenas de sitios. Para simplificar la gestión de dominios o cuentas, puedes visitar Consulta de dominio y registro.

Plan de intervención segura para un PID sospechoso

Al encontrar un proceso que consume muchos recursos, puede parecer tentador usar kill -9 de inmediato. Sin embargo, esta acción puede causar pérdida de datos, operaciones incompletas o inestabilidad. Es mejor seguir un plan seguro.

1. Documenta el proceso

Anota PID, USER, COMMAND, CPU%, MEM% y tiempo de ejecución. Si puedes, captura la pantalla de htop. Estos registros ayudan a comparar en caso de problemas recurrentes y facilitan explicaciones técnicas a clientes o equipos.

2. Verifica la ruta del archivo

Confirma la ruta con ps -fp PID y lsof -p PID. Si el archivo está en la raíz web, revisa los logs de la aplicación: en WordPress, wp-content/debug.log; en el servidor web, logs de acceso y error; en PHP-FPM, logs de lentitud.

3. Intenta una finalización suave

Envía primero la señal estándar para terminar:

kill PID

Espera unos segundos y verifica si el proceso terminó. Si no, y el sistema se afecta gravemente, usa como último recurso:

kill -9 PID

Este comando termina el proceso sin darle oportunidad de limpiar, por lo que debe usarse con precaución en procesos que manejan bases de datos o archivos.

4. Si se reinicia automáticamente, encuentra el origen

Si el proceso reaparece segundos después, puede estar controlado por cron, systemd, supervisor, una petición web o tráfico de bots. Revisa con crontab -l, systemctl status nombre_servicio y logs de acceso. En caso de problemas con wp-cron, revisa la configuración real de cron y políticas de caché.

Combinar hallazgos de htop con análisis de logs

htop muestra qué consume recursos, pero los logs explican por qué. Sin ambos, el diagnóstico es incompleto. Por ejemplo, un proceso php-fpm puede usar 180% de CPU, pero sin logs de acceso no sabrás qué URL o bot lo dispara.

Logs útiles para revisar:

• Logs de acceso del servidor web: indican URLs con alto tráfico.
• Logs de error del servidor web: muestran fallos PHP, permisos o errores 500.
• Logs lentos de PHP-FPM: identifican scripts o funciones que tardan mucho.
• Logs lentos de consultas MySQL: detectan consultas SQL pesadas.
• Logs de autenticación (auth o secure): para intentos sospechosos de acceso.
• Logs de cron: muestran cuándo corren las tareas programadas.

Por ejemplo, si un PID con alto consumo CPU coincide con miles de peticiones a /wp-admin/admin-ajax.php, probablemente sea un plugin, tráfico malicioso o una mala implementación AJAX. En estos casos, se debe combinar WAF, limitación de peticiones, caché y optimización de plugins. Para un enfoque más amplio de rendimiento, revisa Optimización de velocidad de sitios web.

Diferenciar entre carga normal y carga problemática

No toda alta demanda indica un problema. Hay que considerar hardware, tráfico, tipo de aplicación y tareas de mantenimiento. Por ejemplo, un VPS de 2 núcleos con load average sostenido entre 6 y 8 es un cuello de botella serio. En un servidor dedicado con 16 núcleos, ese nivel puede ser normal. Por eso, siempre interpreta load average junto con el número de núcleos disponibles.

Este análisis te ayuda a distinguir entre pánico innecesario y crisis real. En e-commerce, promociones o integraciones pueden elevar temporalmente el consumo, pero si afecta la experiencia del usuario se debe optimizar la aplicación y ajustar la capacidad del servidor.

¿Puede un script que consume recursos ser malicioso?

No siempre un proceso que consume mucha CPU o RAM es un error inocente. En sitios comprometidos, atacantes pueden ejecutar scripts para spam, minería de criptomonedas, proxy, bots DDoS o puertas traseras. En htop, procesos con usuarios inesperados, comandos raros, archivos que corren desde /tmp o uploads y nombres aleatorios deben tomarse en serio.

Señales sospechosas

• Archivos con nombres sin sentido o caracteres aleatorios en COMMAND
• Procesos ejecutados desde carpetas temporales o uploads
• Procesos perl, python o bash que normalmente no deberían estar
• Procesos con conexiones externas inusuales
• Un usuario lanza muchos procesos en poco tiempo
• Archivos web con modificaciones recientes no autorizadas

En estos casos, antes de matar el proceso, toma evidencias con capturas y salidas de comando. Luego revisa permisos, aísla archivos maliciosos, cambia todas las contraseñas de panel y CMS, actualiza componentes y realiza un escaneo de seguridad. Usar autenticación de dos factores y restringir permisos de escritura también reduce riesgos en el largo plazo.

Buenas prácticas para evitar recurrencias en problemas de rendimiento

Detectar el problema con htop es solo el primer paso. Lo realmente valioso es evitar que vuelva a ocurrir. Estas acciones ayudan a reducir cortes por uso excesivo de CPU y RAM en servidores Linux:

• Ajusta memory_limit, max_execution_time y pm.max_children en PHP según la capacidad del servidor.
• Usa sistemas de caché en WordPress, Joomla o software propio.
• Elimina plugins, temas y módulos que no uses o estén desactualizados.
• Optimiza consultas lentas con logs de MySQL slow query.
• No ejecutes todas las tareas cron al mismo tiempo; distribúyelas en intervalos.
• Aplica límites de tasa, reglas en robots.txt y firewall para controlar bots.
• Rota y controla logs para evitar que ocupen demasiado disco y memoria.
• Monitorea métricas del servidor de forma continua, no solo en crisis.

Si a pesar de optimizar el software, el consumo sigue alto, puede que el tráfico haya crecido, la aplicación haya escalado o el plan de hosting sea insuficiente. En ese caso, un VPS escalable, más RAM, discos NVMe o un servidor dedicado con recursos aislados pueden ser la solución. Para comparar opciones, visita Paquetes de Hosting y soluciones de servidor corporativo.

Ejemplo práctico: pico de CPU en un sitio WordPress

Imaginemos un VPS con 4 núcleos y 8 GB de RAM que aloja varios sitios WordPress. Los usuarios reportan lentitud y errores 502 ocasionales. Al abrir htop, el load average está en 12, todos los núcleos al 100% y muchos procesos php-fpm del mismo usuario saturan la lista.

Filtramos por usuario con F4. Tomamos nota del PID del proceso que consume CPU y ejecutamos ps -fp PID, confirmando que es un worker php-fpm. Con lsof -p PID vemos que accede a /home/site/public_html/wp-content/plugins/example-importer/import.php. Al revisar el log de accesos, detectamos peticiones reiteradas al mismo archivo desde el administrador y llamadas AJAX constantes.

La solución fue detener el proceso de importación, deshabilitar la tarea cron del plugin, fragmentar la importación de datos y ajustar max_execution_time en PHP. Además, se reemplazó wp-cron por cron del sistema. Como resultado, el load average cayó a 1.8, el uso de CPU volvió a niveles normales y la respuesta web mejoró notablemente. Este caso muestra que htop es más efectivo si se usa junto con ps, lsof y análisis de logs.

Errores comunes al usar htop

• Matar solo el proceso que aparece arriba sin investigar la causa raíz.
• Confundir valor VIRT con consumo real de RAM.
• Considerar el uso de RAM por caché de MySQL como problema.
• Ejecutar kill -9 como primera opción.
• Acusar a usuarios o aplicaciones sin revisar logs.
• Interpretar load average sin considerar el número de núcleos.
• No revisar integridad de archivos ante sospechas de intrusión.

Evitar estos errores reduce tiempos de inactividad y el riesgo de pérdida de datos. En administración de sistemas, un diagnóstico acertado vale más que una acción rápida pero incorrecta.

Preguntas frecuentes

¿Para qué sirve el comando htop en un servidor Linux?

htop muestra en tiempo real los procesos que se están ejecutando, con datos de CPU, RAM, usuario, PID y comando, facilitando detectar scripts que consumen muchos recursos.

¿Cómo encuentro un script que consume mucha CPU con htop?

Ordena la lista por CPU%, identifica el PID y usuario del proceso que se mantiene arriba, luego usa ps -fp PID y lsof -p PID para encontrar la ruta y detalles del script.

¿Qué es mejor considerar en consumo de RAM, MEM% o VIRT?

MEM% y especialmente RES son más precisos para analizar RAM usada realmente. VIRT indica memoria virtual reservada, que puede ser engañosa.

¿Es correcto matar un proceso con kill -9 inmediatamente?

No. Primero documenta el proceso, verifica su ruta y usa kill PID. Solo si no termina y afecta gravemente el sistema usa kill -9 como último recurso.

¿Siempre un alto uso de CPU indica un ataque?

No. Procesos legítimos como backups, importaciones o picos de tráfico aumentan CPU. Pero procesos con nombres extraños, que corren desde carpetas temporales o con usuarios inesperados son sospechosos.

En resumen, el comando htop es un punto de partida rápido, práctico y efectivo para detectar scripts que consumen CPU y RAM en Linux. Para un diagnóstico completo, combina sus datos con análisis de PID, salidas de lsof, revisión de cron y logs. Si los problemas de recursos son recurrentes, evalúa tanto la optimización del software como la capacidad de tu infraestructura. Puedes comparar opciones sin presiones en Hostragons, en hosting, VPS y soluciones SSL para elegir la mejor configuración para tu proyecto.