Guía de htop y btop: Domina la Monitorización en Linux

htop y btop son monitores interactivos de procesos que reemplazan al viejo comando top con dashboards a color, soporte para ratón y gestión de procesos integrada. Si alguna vez te quedaste mirando top intentando descifrar qué proceso te estaba comiendo la CPU, estas herramientas te dan la respuesta en segundos.

En resumen: usa htop como visor de procesos rápido y ligero que funciona en cualquier sitio, y btop cuando quieras un dashboard completo con gráficos de CPU, estadísticas de red y I/O de disco en una sola pantalla. Ambos permiten matar procesos, cambiar prioridades y filtrar por nombre — todo sin salir de la terminal.

Por qué top no es suficiente

El comando top viene con cada sistema Linux, y para comprobaciones rápidas sirve. Pero después de años usándolo en servidores de producción, las mismas frustraciones se repiten:

• Sin soporte de ratón — navegas con comandos de una sola tecla poco intuitivos
• Sin scroll horizontal — las líneas de comando largas se cortan sin forma de verlas
• Aspecto feo por defecto — salida monocroma sin distinción visual entre CPU, memoria y swap
• Para matar un proceso necesitas escribir el PID — no puedes seleccionar y matar

Esto es lo que top te muestra:

top - 14:32:01 up 47 days,  3:12,  2 users,  load average: 2.31, 1.87, 1.45
Tasks: 312 total,   1 running, 308 sleeping,   0 stopped,   3 zombie
%Cpu(s): 15.2 us,  3.1 sy,  0.0 ni, 80.4 id,  0.8 wa,  0.0 hi,  0.5 si
MiB Mem :  15921.4 total,   1243.2 free,   8934.1 used,   5744.1 buff/cache

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1847 www-data  20   0 1245832 234112  18432 S  45.2  1.4  12:34.56 node
 2103 postgres  20   0  987264 456320  32768 S  23.1  2.8   8:21.03 postgres

Un muro de números. Ahora compara con la misma información en htop — barras de CPU a color por cada core, indicadores de memoria, y una lista de procesos desplazable donde puedes hacer clic para seleccionar. La densidad de información es la misma, pero la carga cognitiva baja drásticamente.

htop: La evolución de top

htop existe desde 2004 y ahora se mantiene en htop-dev/htop en GitHub. La versión 3.4.1 (abril 2025) añadió medidores de monitorización de GPU y mejoró el manejo de Unicode.

Instalación

# Debian / Ubuntu
sudo apt install htop

# Fedora / RHEL
sudo dnf install htop

# Arch Linux
sudo pacman -S htop

# macOS
brew install htop

En la mayoría de distribuciones, htop ya está en los repositorios por defecto. Sin PPAs ni repos de terceros.

Lo que ves al lanzar htop

Ejecuta htop y verás tres secciones:

1. Cabecera — barras de CPU (una por core), barra de memoria, barra de swap, load average, uptime y conteo de tareas
2. Lista de procesos — tabla ordenable y desplazable con PID, usuario, CPU%, MEM%, comando, etc.
3. Pie — atajos de teclas de función (F1–F10)

Las barras de CPU usan colores con significado:

Cuando configuro un VPS nuevo para 32blog, lo primero que hago tras conectarme por SSH es abrir htop para comprobar la línea base. Un servidor Ubuntu recién instalado debería mostrar las barras de CPU casi vacías y la memoria en torno a 200–400 MB. Si la memoria ya está al 60% sin haber desplegado nada, algo va mal.

Atajos de teclado esenciales

Estos son los atajos que uso a diario:

La vista de árbol (F5) es increíblemente útil para depurar. Cuando una app Node.js genera procesos hijos, el árbol muestra exactamente qué padre posee qué workers. Una vez perdí 20 minutos con ps aux | grep node intentando desenredar una jerarquía de procesos que la vista de árbol de htop me hizo evidente en segundos.

Personalizar la cabecera

Pulsa F2 para entrar en la pantalla de configuración. Puedes añadir medidores como:

• CPU average — barra única para todos los cores combinados
• Disk I/O — throughput de lectura/escritura
• Network I/O — bytes de entrada/salida (htop 3.4+)
• System load — promedios de carga de 1/5/15 minutos
• Hostname y reloj — útil cuando tienes varias sesiones SSH abiertas

Yo configuro mis servidores con CPU (por core) a la izquierda, y memoria + swap + carga a la derecha. La configuración se guarda en ~/.config/htop/htoprc, así que puedes copiarla entre máquinas con scp.

Filtrado y ordenación

Para encontrar fugas de memoria, ordena por uso de memoria:

# Lanzar htop ordenado por memoria
htop --sort-key=PERCENT_MEM

Dentro de htop, pulsa F6 y selecciona PERCENT_MEM. Los mayores consumidores suben arriba. Así fue como detecté una fuga de conexiones de PostgreSQL en un servidor de staging — 47 conexiones idle, cada una ocupando 30 MB de memoria residente.

Para filtrar por un nombre de proceso específico, pulsa F4 y escribe node o postgres. A diferencia de la búsqueda (F3), el filtro oculta todos los procesos que no coinciden, dándote una vista enfocada.

btop: El dashboard completo

btop es el sucesor en C++ de bashtop y bpytop. Mientras htop se enfoca en la lista de procesos, btop te da una vista completa del sistema — gráficos de CPU a lo largo del tiempo, ancho de banda de red, actividad de disco y estado de la batería en una sola ventana de terminal. La versión 1.4.6 (diciembre 2025) añadió soporte para renice de procesos y mejoró el trimming de nombres de CPU AMD.

Instalación

# Debian / Ubuntu (22.04+)
sudo apt install btop

# Fedora
sudo dnf install btop

# Arch Linux
sudo pacman -S btop

# macOS
brew install btop

# Snap (cualquier distro)
sudo snap install btop

La interfaz de btop

btop divide la pantalla en cajas:

• Caja de CPU — barras de uso por core + gráfico temporal que muestra el uso a lo largo del tiempo
• Caja de memoria — uso de RAM y swap con gráficos
• Caja de red — velocidad de subida/bajada en tiempo real
• Caja de disco — throughput de lectura/escritura por sistema de archivos montado
• Caja de procesos — lista de procesos ordenable y filtrable (similar a htop)

Lo que me convenció de btop fue el gráfico temporal de CPU. Cuando depuras un cron job que causa picos periódicos de CPU, htop te muestra la foto del momento. btop te muestra el patrón de los últimos minutos, dejando claro que el pico ocurre cada 60 segundos.

Atajos de teclado

Configuración

La configuración de btop está en ~/.config/btop/btop.conf. También puedes pulsar Esc → Options para configurar desde el menú integrado:

# ~/.config/btop/btop.conf (configuraciones clave)
color_theme = "Default"
theme_background = False    # fondo transparente para usuarios de tiling WM
update_ms = 2000            # actualizar cada 2 segundos (por defecto: 2000)
proc_sorting = "cpu lazy"   # ordenar por CPU, sin reordenar cada frame
shown_boxes = "cpu mem net proc"  # cajas a mostrar

Yo uso theme_background = False en mi setup de WSL2 para que el fondo de btop coincida con el tema de Windows Terminal. Un detalle pequeño, pero queda limpio.

htop vs btop: Cuándo usar cada uno

Mi regla: htop en servidores (más ligero, más rápido, disponible en todos lados), btop en mi máquina local (más datos, más bonito). En un VPS de 512 MB, cada megabyte cuenta — htop gana. En mi máquina de desarrollo con 32 GB de RAM, los gráficos de btop valen los megas extra.

Gestión de procesos: kill, nice y señales

Tanto htop como btop te permiten gestionar procesos directamente desde la interfaz, pero entender qué pasa por detrás te hace más efectivo.

Señales

Cuando pulsas F9 (kill) en htop, en realidad estás enviando una señal al proceso. Las más importantes:

Siempre prueba SIGTERM primero. SIGKILL debería ser el último recurso porque el proceso no puede hacer limpieza — los archivos temporales no se borran, las transacciones de base de datos no hacen rollback, y los procesos hijos pueden quedar huérfanos.

Desde la línea de comandos:

# Cierre graceful
kill 1847

# Kill forzado (solo cuando SIGTERM no funciona tras unos segundos)
kill -9 1847

# Kill por nombre
pkill -f "node server.js"

# Matar todos los procesos de un usuario
pkill -u www-data

Aprendí por las malas a no hacer kill -9 a PostgreSQL. La base de datos se recuperó, pero tuvo que reproducir el log WAL, lo que tardó 4 minutos en un servidor con carga. SIGTERM deja que Postgres termine las consultas activas y haga flush de los buffers primero.

nice y renice

Cada proceso tiene un valor nice de -20 (máxima prioridad) a 19 (mínima prioridad). El valor por defecto es 0. Cuanto más alto el valor nice, más "amable" es el proceso con los demás — cede tiempo de CPU.

# Iniciar una tarea pesada con baja prioridad
nice -n 10 ffmpeg -i input.mp4 -c:v libx264 output.mp4

# Cambiar la prioridad de un proceso en ejecución
renice 15 -p 1847

# Fijar máxima prioridad (requiere root)
sudo renice -20 -p 1847

En btop, pulsa r sobre un proceso seleccionado para cambiar su nice. En htop, puedes usar F7 (bajar nice = subir prioridad) y F8 (subir nice = bajar prioridad).

Patrones prácticos

Encontrar y matar un proceso que se come la CPU:

# En htop: pulsa F6, ordena por CPU%, selecciona el proceso, pulsa F9, elige SIGTERM

# Desde la línea de comandos:
ps aux --sort=-%cpu | head -5
kill $(pgrep -f "runaway-script")

Matar procesos zombie:

Los zombies no se pueden matar directamente — ya están muertos. Necesitas matar al proceso padre:

# Encontrar procesos zombie
ps aux | awk '$8 ~ /Z/ {print $2, $11}'

# Encontrar el PID del padre
ps -o ppid= -p <zombie_pid>

# Matar al padre (o enviar SIGCHLD para que recoja al hijo)
kill -SIGCHLD <parent_pid>

Cómo leer los estados de procesos

En la columna S de htop (o State en btop), cada proceso muestra una letra que indica su estado. Conocer su significado es esencial para depurar:

Qué debe preocuparte

Demasiados procesos en D (sleep de disco) — normalmente significa que el disco está saturado. Comprueba el I/O wait en la cabecera de CPU (el valor wa en top). Si wa está por encima del 20%, el almacenamiento es el cuello de botella. En VPSes cloud, muchas veces has agotado los IOPS de burst.

Procesos zombie acumulándose — unos pocos zombies son normales e inofensivos (casi no consumen recursos, solo un slot en la tabla de procesos). Pero si el conteo sigue subiendo, el proceso padre tiene un bug — no está llamando a wait() sobre sus hijos. Identifica al padre y reinícialo.

Load average mayor que el número de cores — si tu sistema tiene 4 cores y el load average de 1 minuto es 12, los procesos están haciendo cola esperando tiempo de CPU. Usa la vista de árbol de htop para encontrar qué árbol de procesos causa la carga.

# Comprobación rápida: ¿cuántos cores vs load average?
nproc              # número de cores de CPU
uptime             # load averages al final

# Si load >> nproc, encuentra a los culpables:
htop --sort-key=PERCENT_CPU

Un error común: un load average alto no siempre significa uso alto de CPU. Los procesos en estado D (sleep de disco) también cuentan para el load. Si la CPU está baja pero el load es alto, tu cuello de botella es el almacenamiento, no el cómputo.

Debugging real con htop

Escenario que me pasó en el VPS de 32blog. El build de Next.js estaba tardando 3× más de lo normal:

1. Abrí htop, ordené por CPU — nada raro, CPU al 40%
2. Revisé el load average — 8.2 en una máquina de 2 cores
3. Pulsé F5 para vista de árbol — vi 6 procesos node (workers del build de Next.js)
4. Miré la columna S — la mayoría en estado D (sleep de disco)
5. Diagnóstico: el VPS había agotado sus IOPS de burst. El build estaba limitado por I/O, no por CPU

La solución fue simple: actualizar a un tier de VPS con SSD. Pero sin htop mostrándome los estados de los procesos de un vistazo, habría perdido tiempo intentando optimizar la configuración del build.

FAQ

¿Es htop mejor que top?

Para uso interactivo, sin duda. htop añade barras de CPU a color, soporte de ratón, vista de árbol y gestión de procesos in situ. La ventaja de top es que viene preinstalado en todas partes, así que es útil en contenedores mínimos o shells de rescate donde no puedes instalar paquetes.

¿Puedo usar btop por SSH?

Sí, pero tu terminal necesita soportar el conjunto de caracteres extendidos que btop usa para los gráficos. La mayoría de terminales modernos (Windows Terminal, iTerm2, Alacritty, kitty) funcionan bien. Si los gráficos se ven con caracteres rotos, prueba a establecer TERM=xterm-256color o usa htop como alternativa.

¿Cómo mato un proceso que no muere con SIGTERM?

Espera unos segundos (puede estar limpiando), y si sigue sin morir usa kill -9 <PID> o pulsa F9 en htop y selecciona la señal 9 (SIGKILL). Si incluso SIGKILL no funciona, el proceso probablemente está atrapado en sleep no interrumpible (D) esperando una operación del kernel — normalmente un montaje NFS muerto o un disco atascado. En ese caso, puede que necesites reiniciar.

¿Cuál es la diferencia entre VIRT, RES y SHR en htop?

VIRT es el total de memoria virtual que el proceso tiene mapeada — incluye bibliotecas compartidas, archivos mapeados en memoria, y memoria reservada pero sin usar. RES (residente) es lo que realmente está en RAM ahora mismo. SHR es la porción de RES compartida con otros procesos (principalmente bibliotecas compartidas). Céntrate en RES — es la huella de memoria real.

¿Funcionan htop y btop en macOS?

Sí. Instálalos con Homebrew (brew install htop btop). Algunas funciones específicas de Linux como la frecuencia por core o información de cgroups no estarán disponibles, pero la monitorización principal y la gestión de procesos funcionan igual.

¿Cómo hago que htop arranque con mi orden preferido?

Usa flags de línea de comandos: htop --sort-key=PERCENT_MEM para ordenar por memoria. O configúralo en la pantalla de ajustes (F2) y se guarda en ~/.config/htop/htoprc.

¿Puedo monitorizar los procesos de un contenedor Docker con htop?

Sí. Ejecuta htop en el host y filtra (F4) por el nombre del proceso principal del contenedor. O ejecuta htop dentro del contenedor con docker exec -it <container> htop — esto muestra solo los procesos del contenedor, facilitando la concentración.

¿Cada cuánto se actualizan htop y btop?

htop por defecto cada 1.5 segundos, btop cada 2 segundos. Ambos son configurables — en htop desde la pantalla de ajustes, en btop con las teclas +/- o la opción de configuración update_ms.

Conclusión

top sirve en un apuro, pero htop y btop convierten la monitorización de procesos de una tarea tediosa en algo que realmente puedes razonar. htop es mi herramienta predilecta en servidores — está en todas partes, es ligero, y solo la vista de árbol ya justifica la instalación. btop vive en mi máquina local, donde los gráficos de CPU y la monitorización de red me dan una imagen completa sin abrir cinco herramientas diferentes.

El valor real no está en los colores bonitos. Está en el flujo de trabajo: ves un pico, filtras al proceso, revisas su estado, envías una señal — todo sin salir de la terminal ni memorizar PIDs. Una vez que construyes esa memoria muscular, te preguntarás cómo gestionabas procesos antes.

Siguiente paso: si gestionas tareas en segundo plano que se ejecutan en un horario, consulta la guía de cron y systemd timer. Y si escribes scripts que generan procesos hijos, la guía de shell scripting cubre el manejo de señales y traps de limpieza.