Comandos y herramientas para verificar el consumo de RAM en Linux

Monitorear el uso de RAM en Linux significa consultar el subsistema de memoria del kernel para recuperar métricas sobre la asignación de memoria física, la utilización del swap y los tamaños de conjunto residente por proceso. Los métodos más directos utilizan utilidades integradas — free, top, htop, ps, vmstat y smem — cada una exponiendo una capa diferente de la jerarquía de memoria, desde los totales del sistema hasta el tamaño de conjunto proporcional por proceso (PSS).

La presión excesiva de memoria activa el eliminador OOM (Out-of-Memory) de Linux, que termina forzosamente los procesos para recuperar RAM. Entender qué comandos revelan qué métricas — y qué significan realmente esas métricas — es la diferencia entre apagar incendios de forma reactiva y gestionar la capacidad de forma proactiva. Esta guía cubre todas las herramientas principales, las fuentes de datos del kernel de las que leen y los casos extremos que sorprenden incluso a administradores experimentados.

Por qué importa el monitoreo de RAM en servidores Linux

La gestión de memoria de Linux es deliberadamente agresiva. El kernel utiliza toda la RAM disponible como caché de páginas para acelerar la E/S de disco, lo que significa que un sistema que reporta memoria libre casi nula no está necesariamente bajo presión — simplemente puede estar almacenando en caché de manera eficiente. Malinterpretar este comportamiento es uno de los errores más comunes al interpretar cifras de memoria sin procesar.

Razones clave para monitorear la RAM continuamente:

• Prevención del eliminador OOM: Identificar procesos con alto consumo de memoria antes de que el kernel termine servicios críticos.
• Detección del uso de swap: La actividad intensa de swap (swapping) indica agotamiento de RAM y causa grave latencia de E/S.
• Diagnóstico de fugas de memoria: Los procesos con RSS en constante crecimiento a lo largo del tiempo indican fugas a nivel de aplicación.
• Planificación de capacidad: Los datos de tendencias informan las decisiones sobre escalado vertical o redistribución de cargas de trabajo.
• Ajuste de rendimiento: Ajustar vm.swappiness, páginas enormes y la topología NUMA requiere datos de memoria de referencia.

En un entorno de Hosting VPS donde los recursos son compartidos o limitados por los límites del hipervisor, el monitoreo preciso de RAM es especialmente crítico — alcanzar un límite de memoria degrada silenciosamente el rendimiento antes de que se active cualquier alerta.

Comprensión de la terminología de memoria de Linux

Antes de ejecutar cualquier comando, necesitas entender qué representan realmente las columnas de salida.

Información crítica: Utiliza siempre la columna Available de free -h, no la columna Free, al evaluar si un sistema tiene suficiente RAM para una nueva carga de trabajo. La columna Free ignora la caché recuperable, lo que lleva a falsas alarmas.

El archivo /proc/meminfo: La fuente autorizada

Cada herramienta descrita en este artículo lee de /proc/meminfo, un archivo virtual mantenido por el kernel en tiempo real. Inspeccionarlo directamente te proporciona los datos más granulares disponibles:

cat /proc/meminfo

Campos clave a observar:

• MemTotal — RAM total utilizable
• MemFree — RAM completamente inactiva
• MemAvailable — RAM disponible estimada para nuevos procesos
• Buffers — caché de bloques de disco sin procesar
• Cached — caché de páginas para archivos
• SwapTotal / SwapFree — capacidad y disponibilidad de swap
• Dirty — memoria esperando ser escrita en disco (valores altos indican presión de E/S)
• HugePages_Total / HugePages_Free — estado de asignación de páginas enormes
• Slab — caché de estructuras de datos del kernel (puede crecer mucho en servidores NFS o de bases de datos con mucha actividad)

Entender /proc/meminfo te permite interpretar la salida de cualquier otra herramienta con pleno contexto.

Verificar la RAM con el comando free

free es la forma más rápida de obtener una instantánea de memoria a nivel de sistema. Lee directamente de /proc/meminfo y formatea la salida en una tabla legible por humanos.

Uso básico

free

La salida está en kilobytes por defecto. Usa indicadores para formatos más legibles:

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Explicación de la salida de ejemplo

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

En este ejemplo, el sistema parece tener solo 1,1 GB libres, pero 10,9 GB están realmente disponibles para nuevos procesos porque el kernel recuperará buff/cache bajo demanda. Esto es lo más importante que debes entender sobre la salida de free.

Caso extremo: El uso de swap como señal de advertencia

Incluso una pequeña cantidad de uso de swap (Swap: used > 0) en un servidor de producción merece investigación. Significa que el kernel ya ha decidido que algunas páginas de memoria se almacenan mejor en disco que en RAM — una señal de que el conjunto de trabajo supera la memoria física.

Verificar la RAM con el comando top

top proporciona una vista en tiempo real continuamente actualizada del uso de recursos del sistema, combinando estadísticas de CPU y memoria con una lista de procesos clasificada.

top

Campos de memoria clave en top

En la parte superior de la interfaz de top, dos líneas muestran estadísticas de memoria:

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

En la tabla de procesos, las columnas de memoria más relevantes son:

• VIRT — tamaño de memoria virtual (equivalente a VSZ)
• RES — memoria física residente (RSS)
• SHR — porción de memoria compartida de RES
• %MEM — porcentaje de RAM física total utilizada

Comandos interactivos útiles de top

Ejecutar top de forma no interactiva

Para scripting y captura de registros, ejecuta top en modo por lotes:

top -b -n 1 | head -30

Esto genera una única instantánea — útil para scripts de monitoreo basados en cron.

Verificar la RAM con htop

htop es un visor de procesos mejorado basado en ncurses que presenta los mismos datos subyacentes que top con una interfaz significativamente más usable. No está instalado por defecto en la mayoría de las distribuciones.

Instalación

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

Qué agrega htop sobre top

• Barras de memoria con código de colores que distinguen la memoria usada, los búferes y la caché de un vistazo
• Vista de árbol de procesos horizontal y vertical (F5)
• Soporte para ratón para hacer clic y desplazarse
• Selección múltiple para gestión masiva de procesos
• Búsqueda integrada (F3) y filtro (F4) sin necesidad de memorizar combinaciones de teclas
• Visualización directa de memoria disponible de forma prominente en el encabezado

Leyenda de colores de la barra de memoria de htop

Consejo profesional: En htop, presiona F2 (Configuración) > Opciones de visualización > habilita "Show CPU frequency" y "Detailed CPU time" para obtener una imagen más completa junto con los datos de memoria.

Verificar la RAM con el comando ps

ps (estado de proceso) consulta la tabla de procesos del kernel y puede ordenarse y filtrarse para identificar los principales consumidores de memoria en un momento dado.

Ordenar procesos por consumo de memoria

ps aux --sort=-%mem

Explicación de las columnas de salida

Comandos de una línea prácticos

Mostrar los 10 procesos que más memoria consumen con salida legible por humanos:

ps aux --sort=-%mem | head -11

Mostrar el uso de memoria para un nombre de proceso específico (por ejemplo, Apache):

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Esto suma los valores RSS de todos los procesos trabajadores de apache2 — fundamental para entender la huella real de los servidores web multiproceso.

Advertencia importante: ps muestra RSS, que cuenta doble las bibliotecas compartidas. Si 20 trabajadores de Apache mapean la misma biblioteca compartida de 50 MB, ps reporta 1.000 MB de uso de biblioteca compartida entre ellos, mientras que el costo físico real es solo 50 MB. Usa smem para una contabilidad precisa.

Verificar la RAM con smem

smem es la herramienta de contabilidad de memoria por proceso más precisa disponible en Linux porque reporta PSS (Proportional Set Size) — la memoria compartida se divide proporcionalmente entre todos los procesos que la mapean, eliminando el problema de doble conteo inherente a las herramientas basadas en RSS.

Instalación

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Uso básico

smem

Opciones útiles de smem

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS vs RSS: Por qué importa

Considera un servidor que ejecuta 10 procesos trabajadores de Node.js, cada uno compartiendo una biblioteca de tiempo de ejecución V8 de 100 MB:

• RSS por proceso: 200 MB (100 MB compartidos + 100 MB privados)
• RSS total reportado: 2.000 MB
• PSS por proceso: 110 MB (10 MB de participación en 100 MB + 100 MB privados)
• PSS total reportado: 1.100 MB
• RAM física real utilizada: 1.100 MB

RSS sobreestima el uso en casi 2x en este escenario. Al tomar decisiones de escalado en un Servidor Dedicado, usar PSS de smem te da la verdad absoluta.

Verificar la RAM con vmstat

vmstat (estadísticas de memoria virtual) proporciona una vista más amplia de la actividad de memoria, swap, E/S y CPU, lo que lo hace ideal para diagnosticar la presión de memoria a nivel de sistema en lugar de problemas de procesos individuales.

vmstat 2 10    # Report every 2 seconds, 10 times

Columnas de memoria clave

Señal crítica: Los valores no nulos de si (swap-in) y so (swap-out) en un flujo de vmstat en ejecución indican intercambio activo — una señal definitiva de agotamiento de memoria. Incluso picos ocasionales en so pueden causar picos de latencia de aplicación de cientos de milisegundos.

Verificar la RAM con sar (System Activity Reporter)

sar del paquete sysstat registra datos históricos de memoria, permitiendo análisis retrospectivo — algo que las herramientas en tiempo real no pueden proporcionar.

Instalación

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Uso

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar es invaluable para responder preguntas como "¿Hubo un pico de memoria a las 3 AM que causó el fallo de la aplicación?" — una pregunta que ninguna herramienta en tiempo real puede responder después del hecho.

Verificar la RAM con /proc/<PID>/status y /proc/<PID>/smaps

Para un análisis profundo por proceso, el kernel expone mapas de memoria detallados directamente en /proc.

Verificación rápida de memoria por proceso

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Ejemplo de salida:

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — tamaño máximo de memoria virtual alcanzado alguna vez por este proceso
• VmRSS — tamaño actual del conjunto residente
• VmSwap — cuánto de este proceso ha sido intercambiado

Mapa de memoria detallado con smaps

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Esto revela cada mapeo de memoria (heap, stack, bibliotecas compartidas, mapeos anónimos) con valores individuales de RSS y PSS — la vista de memoria más granular disponible sin un perfilador.

Comparación de herramientas: Elegir el comando correcto

Flujos de trabajo de monitoreo prácticos

Flujo de trabajo 1: Triaje rápido (menos de 60 segundos)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

Flujo de trabajo 2: Identificar una fuga de memoria

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

Flujo de trabajo 3: Análisis histórico post-incidente

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

Flujo de trabajo 4: Script de alertas automatizadas

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Este script puede colocarse en un trabajo cron para monitoreo automatizado continuo — una necesidad práctica en cualquier VPS con cPanel de producción o servidor bare-metal.

Avanzado: Parámetros de ajuste de memoria del kernel

Una vez que hayas identificado la presión de memoria, estos parámetros de sysctl afectan directamente el comportamiento:

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

vm.swappiness explicado: Un valor de 60 significa que el kernel comenzará a usar swap cuando la RAM esté al 40% de utilización. Para servidores de bases de datos (MySQL, PostgreSQL, Redis), establecer esto en 10 mantiene los datos en RAM durante mucho más tiempo, reduciendo drásticamente la latencia de E/S. Para sistemas de escritorio o sistemas con RAM limitada, el valor predeterminado es más apropiado.

Errores comunes e interpretaciones incorrectas

Error 1: Entrar en pánico por poca memoria "libre"

Como se explicó anteriormente, Linux usa intencionalmente la RAM libre como caché. Un sistema con 200 MB libres pero 8 GB disponibles está sano. Lee siempre la columna Available.

Error 2: Sumar RSS para estimar el uso total de memoria

Sumar los valores RSS de ps en todos los procesos típicamente superará la RAM física total debido al doble conteo de bibliotecas compartidas. Usa smem -t para un total preciso del sistema.

Error 3: Ignorar la caché Slab

En clientes NFS activos o servidores con muchos archivos pequeños, el asignador Slab del kernel puede consumir gigabytes de RAM. Verifica cat /proc/meminfo | grep Slab — esta memoria es técnicamente recuperable pero no aparece en las herramientas a nivel de proceso.

Error 4: Confundir VSZ con el uso real de memoria

Una aplicación Java puede mostrar 4 GB de VSZ pero solo 512 MB de RSS. VSZ incluye archivos mapeados en memoria, heap reservado pero no asignado y bibliotecas compartidas — la mayoría de los cuales nunca se cargan realmente en la RAM física.

Error 5: Pasar por alto la memoria en cargas de trabajo en contenedores

Dentro de un contenedor Docker, free muestra la memoria total del host, no el límite de cgroup del contenedor. Usa cat /sys/fs/cgroup/memory/memory.usage_in_bytes y cat /sys/fs/cgroup/memory/memory.limit_in_bytes para métricas precisas a nivel de contenedor.

Configurar el monitoreo persistente de RAM

Para entornos de producción, los comandos puntuales son insuficientes. Considera estos enfoques para visibilidad continua:

• sysstat con cron: Habilita la recopilación automática de datos históricos de sar.
• Prometheus + Node Exporter: Extrae métricas de /proc/meminfo y las expone para paneles de Grafana.
• Netdata: Monitoreo en tiempo real sin configuración con granularidad por segundo y detección integrada de anomalías de memoria.
• Zabbix o Nagios: Alertas de nivel empresarial con umbrales de memoria configurables y políticas de escalada.

Al ejecutar cargas de trabajo en infraestructura de Hosting GPU, también monitorea la VRAM de GPU junto con la RAM del sistema — nvidia-smi --query-gpu=memory.used,memory.free --format=csv proporciona las métricas equivalentes para la memoria GPU.

Para entornos de hosting web gestionados a través de Paneles de Control VPS, la mayoría de los paneles incluyen gráficos de memoria integrados — pero estos típicamente sondean a intervalos de 1 a 5 minutos y perderán picos de corta duración que vmstat o sar capturarían.

Matriz de decisión técnica: Qué herramienta usar y cuándo

Lista de verificación de conclusiones clave

• Verifica siempre la memoria Available de free -h, no la columna Free, para evaluar el margen real disponible.
• Usa vmstat 1 5 para confirmar o descartar el intercambio activo antes de escalar una investigación.
• Usa smem -s pss -r en lugar de ps aux --sort=-%mem cuando necesites cifras de memoria precisas por proceso — especialmente en servidores con muchos procesos que comparten bibliotecas.
• Instala sysstat en cada servidor de producción inmediatamente después del aprovisionamiento para habilitar la recopilación histórica de datos de sar.
• Establece vm.swappiness=10 de forma persistente en /etc/sysctl.conf en servidores de bases de datos para minimizar el uso de swap.
• Verifica /proc/meminfo para los valores de Slab y Dirty cuando las herramientas estándar no explican la presión de memoria observada.
• Para cargas de trabajo en contenedores, lee los archivos de memoria de cgroup — no free — para obtener límites y uso precisos.
• En entornos de hosting compartido o VPS, establece líneas base de memoria durante la operación normal para que las anomalías sean inmediatamente reconocibles.

—

Preguntas frecuentes

¿Cuál es la diferencia entre memoria "free" y "available" en Linux?

"Free" es RAM sin ningún uso actual. "Available" es la estimación realista de memoria que puede asignarse a nuevos procesos sin activar el intercambio — incluye caché de páginas recuperable y búferes. En un servidor Linux saludable, "free" suele estar cerca de cero mientras que "available" permanece alto. Usa siempre "available" para evaluaciones de capacidad.

¿Por qué la suma de todos los valores RSS de los procesos supera la RAM física total?

RSS (Resident Set Size) cuenta la memoria compartida — como las bibliotecas compartidas — una vez por cada proceso que la mapea. Si 50 procesos mapean una biblioteca compartida de 100 MB, la suma total de RSS se infla en 4.900 MB más allá del costo físico real. Usa smem con informes PSS para eliminar este doble conteo.

¿Cómo encuentro qué proceso activó el eliminador OOM de Linux?

Ejecuta dmesg | grep -i "oom|killed process" o journalctl -k | grep -i oom. El kernel registra el nombre exacto del proceso, PID y estadísticas de memoria en el momento del evento de eliminación, incluyendo el oom_score de todos los procesos evaluados.

¿Qué indica el alto uso de swap y qué tan grave es?

El uso sostenido de swap significa que el conjunto de trabajo del sistema supera la RAM física. El kernel compensa paginando datos al disco, que típicamente es entre 100 y 1.000 veces más lento que el acceso a RAM. Incluso una actividad de swap modesta causa latencia de aplicación medible. Es una señal definitiva para reducir el consumo de memoria, aumentar la RAM o redistribuir las cargas de trabajo.

¿Puedo monitorear el uso de RAM dentro de un contenedor Docker usando comandos estándar de Linux?

Los comandos estándar como free dentro de un contenedor muestran la RAM total del host, no el límite de cgroup del contenedor. Para métricas precisas a nivel de contenedor, lee /sys/fs/cgroup/memory/memory.usage_in_bytes para el uso actual y /sys/fs/cgroup/memory/memory.limit_in_bytes para el límite configurado. Alternativamente, usa docker stats <container_name> desde el host para una vista formateada.