Cómo usar IA para encontrar qué consume RAM en Linux

Antes de nada: la RAM "llena" casi nunca es un problema

Linux ocupa toda la RAM que puede a propósito, y eso es bueno. La memoria que no está en uso la aprovecha como caché de disco: guarda ahí los archivos que leíste hace poco para no volver a buscarlos en el disco, que es cientos de veces más lento. Cuando una aplicación pide memoria, el kernel libera esa caché al instante.

Por eso mirar solo "used" o "free" engaña. El primer comando siempre es:

free -h

Verás algo así:

               total        used        free      shared  buff/cache   available
Mem:            3.8Gi       1.4Gi       180Mi        60Mi       2.2Gi       2.1Gi
Swap:           1.0Gi        45Mi       979Mi

El número que importa es available: 2.1 Gi. Es la estimación del kernel de cuánta memoria puede entregar a un programa nuevo sin recurrir a la swap, e incluye la caché que se puede soltar. Aunque free marque solo 180 Mi, tienes 2.1 Gi disponibles. La regla práctica: si available es holgado, no tienes problema de RAM aunque el panel diga 95 %.

Los tres números que debes distinguir

RAM usada, buffers/cache y swap son tres cosas distintas y confundirlas lleva a decisiones equivocadas. Esta tabla las separa:

La conclusión honesta: si available está bajo y la swap entra y sale sin parar, ahí sí falta memoria. Si solo ves buff/cache alto, no pasa nada. Comprar más RAM en ese segundo caso es tirar el dinero.

Encontrar el proceso culpable con ps

El comando que responde "quién se come la RAM" es ps aux --sort=-%mem. Ordena todos los procesos por memoria, de mayor a menor:

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

Las columnas clave son %MEM (porcentaje de RAM física) y RSS (Resident Set Size, los kilobytes de memoria física real que ocupa el proceso). Para una lista más limpia y ordenada por RSS en megas:

ps -eo pid,ppid,user,rss,%mem,comm --sort=-rss | head -10

Aquí PID es el identificador del proceso, PPID el de su proceso padre, y RSS está en kilobytes: divide entre 1024 para tener megas. Si ves un proceso hijo consumiendo mucho, el PPID te lleva al servicio que lo creó. Un caso típico en un servidor web: no es php-fpm en general, sino un worker concreto que se disparó.

Ver el consumo en vivo con top

top sirve cuando el consumo sube en este momento y quieres verlo cambiar. Ejecútalo y pulsa la tecla M (mayúscula) para ordenar por memoria:

top

Fíjate en la columna %MEM y RES (equivalente a RSS). Arriba, la línea de memoria repite lo de free: total, libre, usada y buff/cache. La ventaja de top sobre ps es el tiempo: si un proceso trepa 50 MB cada pocos segundos y no baja, estás viendo una fuga de memoria (memory leak) en directo, algo que una foto fija de ps no revela. Pulsa q para salir.

Mirar el detalle real en /proc/meminfo

Cuando free no basta, /proc/meminfo es la fuente original de todas las cifras de memoria del sistema. Es un archivo virtual que el kernel genera al vuelo:

grep -E 'MemTotal|MemAvailable|Cached|Buffers|SwapTotal|SwapFree|Dirty' /proc/meminfo

Salida de ejemplo:

MemTotal:        3999000 kB
MemAvailable:    2201400 kB
Buffers:          120500 kB
Cached:          1980300 kB
SwapTotal:       1048572 kB
SwapFree:        1002100 kB
Dirty:             15400 kB

Cached alto confirma que esa memoria es caché recuperable. Dirty son datos aún sin escribir a disco; si es enorme, hay mucha escritura pendiente. Y comparar SwapTotal con SwapFree te dice cuánta swap está en uso ahora mismo.

Reparto justo por proceso con smem

Sumar el RSS de todos los procesos siempre da de más, porque varios comparten las mismas bibliotecas en memoria y ese peso se cuenta repetido. La herramienta que lo corrige es smem, que muestra la columna PSS (Proportional Set Size): reparte la memoria compartida entre los procesos que la usan.

sudo apt install -y smem
sudo smem -r -k -s pss | head -10

• -r ordena de mayor a menor.
• -k muestra las cifras en KB/MB legibles.
• -s pss ordena por PSS.

Para agrupar por aplicación en vez de por proceso suelto:

sudo smem -k -P nombre_del_servicio

PSS es el número que deberías usar para decidir qué proceso optimizar o limitar, porque es el que refleja el coste real de memoria de cada uno.

Confirmar si el kernel ya mató algo por falta de RAM

Cuando la memoria se agota del todo, el kernel activa el OOM killer y termina un proceso, dejando el rastro solo en su log. Si un servicio "se cayó solo", revisa esto antes que nada:

sudo journalctl -k --since "24 hours ago" | grep -i "out of memory\|oom-kill\|killed process"

Si aparece una línea como Out of memory: Killed process 2847 (mysqld), ya tienes la causa: te quedaste sin RAM y el kernel sacrificó MySQL para salvar el sistema. Ahí la solución no es reiniciar y rezar, sino decidir entre optimizar ese proceso, ponerle un límite o ampliar la memoria del servidor.

Cómo un agente de IA lo hace por ti

Todo el recorrido anterior —free, ps, /proc/meminfo, swap, el log del OOM— es exactamente lo que un agente de IA ejecuta y resume en segundos. En los VPS de Terranode viene incluido sin costo Cortex AI, un agente que se conecta por SSH a tu servidor. Le escribes en español:

> "¿Qué se está comiendo la RAM?"

Y hace el trabajo: corre la secuencia de comandos, ignora la caché para no darte una falsa alarma, identifica el proceso que crece de verdad, mira desde cuándo lo hace y si la swap está sufriendo, y te contesta algo concreto: "El proceso mysqld ocupa 1.2 GB de RSS y viene subiendo desde el despliegue de las 14:30; la swap empezó a entrar hace 20 minutos. Conviene limitar la caché de InnoDB o revisar una consulta pesada."

La diferencia con preguntarle a un chatbot genérico es que Cortex está dentro de tu máquina: no adivina, lee el estado real. Y con las garantías que importan en un servidor:

Cortex confirma antes de cualquier acción con consecuencias, bloquea lo destructivo, guarda un registro consultable de todo lo que ejecuta, mantiene su llave SSH cifrada con AES-256 y aísla a cada cliente del resto. Por ahora funciona solo sobre Linux (Ubuntu, Debian, Rocky, AlmaLinux, CentOS).