Htop en Linux: lectura de la carga del servidor sin pánico por los colores

Cuando un servidor se ralentiza, arriba Da rápidamente la impresión de explicarlo todo. Barras de CPU, memoria, colores, una lista de procesos que se mueven en todas direcciones… y a veces un impulso bastante peligroso: eliminar el primer proceso que parece consumir demasiados recursos.

Recomiendo comenzar leyendo htop. Ayuda a identificar posibles problemas, pero no es una fuente fiable de conclusiones. En este artículo, veremos qué comprobar primero: uso de CPU, uso de memoria, carga promedio, ordenación de procesos y, lo más importante, las comprobaciones que se deben realizar antes de apagar un servicio de producción.

Instalar y ejecutar htop en Linux

En muchas distribuciones, htop no viene instalado por defecto. En Debian o Ubuntu, puedes añadirlo usando APT:

sudo apt update
sudo apt install htop

En Fedora:

sudo dnf install htop

En ArchLinux:

sudo pacman -S htop

Luego, simplemente ejecuta:

arriba

Si estás conectado a un servidor remoto mediante SSH, abre htop en una sesión limpia. Evita realizar acciones destructivas desde una sesión inestable o desde una terminal que puedas cerrar accidentalmente.

Lee las barras de la CPU sin entrar en pánico.

En la parte superior de la pantalla, htop muestra una barra para cada núcleo o hilo de la CPU. Esto resulta útil para comprobar si la carga está distribuida o si un solo núcleo está trabajando a plena capacidad.

Un breve pico de uso de la CPU no es necesariamente un problema. Las copias de seguridad, las compilaciones, los análisis antivirus o las compresiones pueden provocar picos de unos segundos. Lo que más me interesa es la duración de dicho pico y el proceso involucrado.

Antes de tocar nada, compruebe también el número de procesadores lógicos disponibles:

nproc

Una carga promedio de 4 en una máquina con 8 hilos no tiene el mismo significado que en un VPS pequeño con 1 vCPU. Es una distinción simple, pero evita muchas decisiones erróneas.

tiempo de actividad

el orden tiempo de actividad Muestra los tres valores promedio de carga durante 1, 5 y 15 minutos. Si los tres han estado aumentando durante un tiempo, la señal es más fuerte que un simple pico observado en htop.

Si quieres profundizar en este punto, el artículo sobre carga promedio en Linux Esta lectura lo complementa bien.

Uso de memoria: no confunda la caché con la saturación.

El uso de la memoria suele ser motivo de preocupación. En Linux, una parte importante de la RAM puede utilizarse como caché de disco. Esto no es necesariamente malo. El kernel libera esta caché cuando las aplicaciones la necesitan.

Para comprobarlo fuera de htop, ejecute:

libre -h

Fíjese especialmente en la columna. disponibleSi el sistema sigue funcionando correctamente, es posible que la memoria no sea el principal problema, incluso si la barra htop parece estar muy llena.

Sin embargo, si la memoria disponible disminuye, el espacio de intercambio aumenta y el servidor se vuelve lento, entonces necesita identificar el proceso de saturación. En htop, puede ordenar por memoria con F6luego elige la columna MEM%.

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | cabeza

Este comando proporciona una lectura rápida fuera de una interfaz interactiva. Puede ser útil para solucionar problemas si htop no está instalado o si desea copiar la salida a un ticket.

Analizando los procesos para encontrar al verdadero culpable.

En htop, la lista inferior muestra los procesos. Las columnas más útiles inicialmente son: PID, USUARIO, UPC%, MEM%, TIEMPO+ Y Dominio.

Algunas cosas que debes saber:

• F6 para elegir la columna de ordenación;
• F4 para filtrar la lista;
• F5 para mostrar el árbol de procesos;
• F9 enviar una señal a un proceso;
• q para salir de htop limpiamente.

La vista de árbol es muy útil. Permite ver si un proceso que consume muchos recursos es iniciado por un servicio, un script, un usuario SSH o un proceso secundario de un servidor web.

Si observa que un proceso de Java, PHP, Python o Node consume muchos recursos, no lo finalice sin motivo. Primero, verifique a qué servicio pertenece:

systemctl status nginx --no-pager
systemctl status php8.4-fpm --no-pager
systemctl status mariadb --no-pager

Por supuesto, adapte los nombres de los servicios a su servidor. Si no sabe qué servicios se están ejecutando, consulte el artículo sobre Comandos systemctl para listar los servicios de Linux Es más apropiado antes de continuar.

Antes de finalizar un proceso, revise los registros.

El botón más tentador en htop es F9Se utiliza para enviar una señal a un proceso. Técnicamente, se puede terminar un proceso con htop. En la práctica, suele ser lo último que se hace, no lo primero.

Antes de desactivar un servicio, revise sus registros recientes:

sudo journalctl -u nginx -n 80 --no-pager

Si el servicio escribe en un archivo específico, sígalo durante unos segundos:

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

Para esta sección, también puedes volver a leer El artículo sobre la monitorización de registros en tiempo real y de colaEvita que te quedes atascado frente a htop sin contexto.

Si el proceso pertenece a un servicio systemd, es preferible reiniciar el sistema:

sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

Si realmente necesitas enviar una señal a un PID, comienza por TÉRMINO. Mantener MATAR para los casos en que el proceso deja de responder por completo.

sudo kill -TERM 1234
sudo kill -KILL 1234

Reemplazar mil doscientos treinta y cuatro por el PID real. Y si estás en una base de datos, almacenamiento, servidor de producción o una sesión de cliente activa, espera treinta segundos adicionales antes de hacer clic en cualquier cosa. Ahí es donde a menudo se evita un fallo grave.

Cuando htop no es suficiente

Htop muestra los procesos con mucha claridad, pero no ofrece una visión completa. Una carga elevada puede deberse a la CPU, la memoria, la entrada/salida del disco, la red, un servicio bloqueado o un pico normal de la aplicación.

Dar un paso atrás:

vmstat 1 5
systemctl --failed
journalctl -p advertencia..alerta -b --no-pager

vmstat Proporciona una visión rápida de los tiempos de espera de CPU, memoria, intercambio y E/S. systemctl --failed Enumera las unidades que han fallado. diarioctl Te permite identificar las advertencias del inicio actual.

Si el problema involucra puertos de red o un servicio que ya no está escuchando, verifique también qué está realmente abierto con ss o netstat en Linux.

Mi método rápido para lidiar con un servidor lento

Cuando abro htop en un servidor lento, mantengo esta secuencia:

• mira el promedio de carga con tiempo de actividad y compararlo con el número de subprocesos de la CPU;
• Compruebe la memoria disponible con libre -h ;
• ordenar htop por CPU y luego por memoria;
• identificar el departamento o usuario responsable del proceso;
• Lea los registros antes de reiniciar o detener cualquier cosa;
• Realice un reinicio limpio con systemctl si el proceso depende de un servicio.

Htop es excelente para ver lo que está sucediendo en este momento. Pero la decisión correcta rara vez se basa en un solo color o columna. Analice el PID, el servicio y los registros, y solo entonces elija la acción.

Para obtener documentación de referencia, puede consultar el sitio web oficial de arriba, su Repositorio de GitHuby la página de manual de arriba para conceptos relacionados con la carga y los procesos.

sudo apt update && sudo apt upgrade