Qué te dicen htop y top en Linux

Si alguna vez abriste top o htop y sentiste que el sistema te estaba hablando en otro idioma, no eres el único. Ves números que suben y bajan, colores, siglas como wa, si, st, una lista de procesos que cambia cada segundo, y no siempre queda claro qué está pasando de verdad.

La buena noticia es que casi todo lo que ves ahí tiene una lectura bastante concreta. Si entiendes qué significa cada bloque, puedes detectar en minutos si el problema es CPU, memoria, swap, I/O, contención por contenedores o simplemente un proceso que se fue de control. Esta guía está pensada para que leas top y htop como lo haría alguien de dev o SRE cuando necesita diagnosticar un cuello de botella sin perder tiempo.

Qué son top y htop, y por qué no muestran lo mismo

top viene instalado en casi cualquier distribución Linux. Es una herramienta clásica, rápida y suficiente para ver procesos y uso de recursos desde la terminal. htop hace lo mismo, pero con una interfaz más cómoda, colores, navegación con teclado y una lectura más amigable de CPU, memoria y procesos.

No son dos herramientas distintas en el fondo. Ambas leen información del kernel y del sistema, sobre todo de /proc, y la presentan de forma resumida. La diferencia está en cómo la organizan. top prioriza densidad de información; htop prioriza legibilidad y exploración interactiva.

Si quieres una referencia oficial sobre top, puedes revisar la página del manual de procps-ng: https://man7.org/linux/man-pages/man1/top.1.html. Para htop, la documentación del proyecto está en https://htop.dev/.

Cuándo usar uno u otro

top te sirve cuando necesitas algo disponible en cualquier servidor, incluso en imágenes mínimas o entornos de rescue. También es útil si estás automatizando capturas o si quieres trabajar por SSH en una máquina muy justa de recursos.

htop te conviene cuando quieres entender rápido qué está pasando. Puedes ordenar por columnas, matar procesos con más comodidad, cambiar vistas y navegar sin sufrir tanto. En una incidencia real, suele ser más fácil empezar con htop y luego pasar a top si estás en un entorno donde htop no existe.

En ambos casos, el objetivo no es mirar “si el número está alto”, sino responder preguntas concretas:

1. ¿La CPU está saturada o solo ocupada?
2. ¿La memoria está realmente presionada o solo cacheada?
3. ¿Hay procesos bloqueados por disco, red o locks?
4. ¿El problema viene del host, de un contenedor o de límites del cgroup?

La parte de arriba: carga, tareas, CPU y memoria

La zona superior de top y htop resume el estado general del sistema. Si aprendes a leerla bien, ya tienes la mitad del diagnóstico. Lo que aparece ahí no es decorativo: cada línea responde a una pregunta distinta sobre la salud del host.

En top, la primera línea suele mostrar el uptime y la carga promedio. Luego vienen tareas, CPU y memoria. En htop, la información está más visual, con barras por núcleo y barras de memoria/swap. Aunque el formato cambia, el significado base es el mismo.

Load average: no es uso de CPU

Uno de los errores más comunes es confundir load average con porcentaje de CPU. No son lo mismo. La carga promedio mide cuántos procesos están ejecutándose o esperando recursos, incluyendo CPU y, en muchos casos, espera por I/O. Si tienes una carga de 8.0 en una máquina de 4 vCPU, no significa automáticamente 200% de CPU; significa que hay más trabajo pendiente del que esas CPU pueden atender al mismo tiempo.

La lectura correcta depende del contexto. En una máquina de 1 núcleo, un load de 1.0 ya puede ser normal. En una de 8 núcleos, un load de 8.0 puede ser perfectamente aceptable si el sistema está haciendo trabajo constante. Lo que te alerta es cuando la carga sube y, al mismo tiempo, ves mucho tiempo en wa o procesos en estado D.

Tareas, estados y memoria

La línea de tareas te dice cuántos procesos están corriendo, durmiendo, detenidos o zombis. Si ves muchos procesos en running, el sistema está activo. Si ves una cantidad inusual de zombie, el problema no es rendimiento sino limpieza de procesos padre.

La línea de memoria requiere más cuidado. En Linux, “memoria usada” no significa lo mismo que “memoria realmente comprometida”. El kernel usa RAM para cachear archivos y acelerar lecturas. Por eso, ver poca memoria libre no implica automáticamente un problema. Lo que importa es si tienes presión real y si el sistema empieza a usar swap de forma sostenida.

CPU: user, system, idle y wait

La línea de CPU es la que más se malinterpreta. En top suele aparecer con porcentajes como us, sy, ni, id, wa, hi, si, st. En htop ves barras por núcleo y, dependiendo de la configuración, los mismos conceptos resumidos.

Aquí tienes una tabla útil para leerlos rápido:

Si ves wa alto, no corras a culpar a la CPU. Muchas veces el problema es almacenamiento lento, una base de datos esperando respuestas, o un volumen de red con latencia. Si ves st alto en una VM, el host físico está compitiendo por CPU con otras cargas.

La lista de procesos: PID, usuario, prioridad y memoria

La parte inferior de top y htop es donde realmente encuentras al culpable. Ahí ves cada proceso con columnas que describen quién lo ejecuta, cuánto consume y en qué estado está. La clave está en leer esas columnas juntas, no una sola por separado.

htop suele mostrar más columnas por defecto y permite personalizarlas. top muestra menos, pero es suficiente si sabes qué mirar. En ambos casos, las columnas más útiles para diagnóstico rápido son PID, USER, PR, NI, VIRT, RES, SHR, S, %CPU y %MEM.

Qué significa cada columna importante

PID identifica el proceso. USER te dice qué cuenta lo lanzó. PR es prioridad, NI es nice, VIRT es memoria virtual, RES es RAM real asignada, SHR es memoria compartida, S es el estado, %CPU es consumo de CPU y %MEM es porcentaje de RAM física.

VIRT suele confundir mucho. No es memoria realmente ocupada. Incluye espacio virtual reservado, librerías mapeadas y memoria que puede no estar resident en RAM. Para saber si un proceso está presionando memoria de verdad, mira RES y compara con el resto del sistema.

SHR también requiere contexto. Un proceso con mucho SHR puede estar compartiendo librerías con otros procesos, algo normal en servicios bien empaquetados. No lo confundas con fuga de memoria.

Estados de proceso que sí te importan

Los estados aparecen como una letra. Las más comunes son:

• R: running o runnable
• S: sleeping
• D: uninterruptible sleep, normalmente espera de I/O
• T: stopped o trazado
• Z: zombie

Si ves muchos procesos en D, sospecha de disco, NFS, storage de red o un subsistema del kernel esperando una operación que no termina. Si ves Z, el proceso hijo ya murió pero el padre no recogió su estado. Eso no consume CPU, pero sí te dice que algo está mal en la lógica del proceso padre.

Cómo leer CPU sin caer en trampas

La CPU no se diagnostica mirando solo el porcentaje total. Tienes que cruzar varias señales: carga, estado de procesos, tiempo en wa, distribución por núcleo y si estás en bare metal o VM. Un sistema puede mostrar 20% de CPU y aun así estar mal, o 95% y estar perfectamente sano si está haciendo trabajo esperado.

En htop, una barra casi llena en un núcleo no siempre significa problema global. Puede ser un proceso single-thread saturando un solo core mientras el resto está libre. En top, la línea global puede ocultar ese detalle si no ordenas por %CPU.

Señales típicas de cuello de botella de CPU

Si un servicio está consumiendo mucho us, normalmente está haciendo trabajo de aplicación: compresión, serialización, cálculos, parsing, render, etc. Si sube sy, el kernel está interviniendo mucho. Eso puede pasar con redes intensas, muchísimas syscalls o contención por archivos y sockets.

Una pista útil es ordenar por CPU y mirar si el consumo está repartido o concentrado. Si un único proceso domina y su consumo sube con la carga, ya tienes un candidato claro. Si varios procesos suben al mismo tiempo, puede ser un patrón de tráfico o un batch job.

Cuando el problema no es CPU sino espera

Aquí es donde wa y D entran en juego. Si la CPU parece libre pero la app responde lento, revisa si los procesos están esperando disco. Un host puede tener id relativamente alto y, aun así, sentirse lento porque las llamadas a I/O tardan demasiado.

Ejemplo realista: una API Node.js con una base de datos en el mismo host puede verse con CPU baja, pero con load alto y varios procesos en D. En ese caso, el cuello de botella puede estar en el volumen donde vive la base de datos, no en el runtime de Node.

Memoria, swap y presión real del sistema

La memoria es otro lugar donde top y htop engañan si los lees rápido. Linux usa RAM agresivamente como cache, y eso es bueno. El problema no es “tener poca libre”, sino empezar a intercambiar páginas a swap de forma constante o quedarse sin memoria disponible para procesos nuevos.

Si ves swap en uso, no asumas desastre inmediato. Linux puede dejar páginas antiguas en swap aunque el sistema esté estable. Lo que te interesa es si hay actividad continua de swap, latencia creciente o procesos que se quedan sin memoria bajo carga.

Cómo distinguir cache de presión real

Mira la combinación de memoria usada, buff/cache y swap. Si la memoria usada parece alta pero también hay bastante cache, probablemente el kernel está aprovechando RAM de forma normal. Si el sistema empieza a liberar cache agresivamente, los procesos crecen en RSS y la swap se mueve, ya hay presión.

Una forma práctica de leerlo es esta:

1. Si RES de los procesos crece y la swap empieza a subir, hay presión real.
2. Si el cache baja mucho mientras el sistema sigue lento, el kernel está tratando de sobrevivir a una carga mayor.
3. Si la app tiene latencia alta pero la memoria está estable, el problema probablemente no está en RAM.

Qué mirar en contenedores y cgroups

En hosts con Docker o Kubernetes, top y htop pueden mostrar procesos del host, pero no siempre te dejan claro el límite real del contenedor. Un proceso puede estar consumiendo “poco” desde la perspectiva del host y, aun así, haber llegado al límite de memoria del cgroup o del pod.

Por eso, cuando la app corre en contenedores, top y htop son una primera vista, no el diagnóstico final. Úsalos para detectar el proceso que sube, luego cruza con métricas del orquestador, límites de pod y eventos de OOMKill. Si no haces ese cruce, puedes culpar al servicio equivocado.

Atajos prácticos para usar htop y top mejor

Tanto htop como top te dejan ordenar y filtrar. Si conoces cuatro o cinco acciones, ahorras tiempo en cada incidente. No necesitas memorizar todo; basta con usar lo que acelera el diagnóstico.

En htop, puedes navegar con flechas, buscar procesos, ordenar por columnas y matar procesos con una interfaz más cómoda. En top, las teclas cambian la ordenación y te permiten ajustar la vista sin salir. La diferencia es que htop te invita más a explorar y top te obliga a ser más preciso.

Secuencia recomendada de diagnóstico

Cuando llegas a una máquina con síntomas raros, sigue este orden:

1. Mira la carga promedio y compárala con el número de CPU.
2. Revisa wa, id y st para saber si el problema es CPU, I/O o hipervisor.
3. Ordena por %CPU y encuentra el proceso dominante.
4. Ordena por %MEM y revisa si hay consumo anormal de RAM.
5. Busca procesos en D o Z si la lista parece sana pero el sistema sigue lento.
6. Cruza con logs, métricas y eventos del orquestador antes de tocar nada.

Algunos comandos útiles

top
htop
htop -u nginx
top -p 1234

top -p 1234 te sirve para seguir un PID concreto. htop -u nginx filtra por usuario y te ayuda a ver si un servicio específico está disparado. Si estás en una incidencia con varios procesos parecidos, este tipo de filtro te ahorra revisar ruido innecesario.

También vale la pena recordar que top y htop no reemplazan a herramientas como vmstat, iostat, pidstat o sar. Las complementan. top te da la foto rápida; las otras herramientas te dan series temporales y detalle por subsistema.

Tabla resumen

Si quieres leer top y htop con criterio, la idea no es memorizar cada columna como si fuera un examen. Lo útil es aprender a cruzar señales. Carga, CPU, espera, memoria, estado de proceso y contexto de despliegue te dicen mucho más que un porcentaje aislado.

Cuando un sistema va mal, el objetivo es reducir el espacio de búsqueda. top y htop te ayudan a separar si el problema vive en CPU, memoria, disco, hipervisor o en un proceso específico. Con eso ya puedes decidir si el siguiente paso es revisar logs, métricas, límites de contenedor o el propio código.