"Usar mucha memoria" y "tener una fuga de memoria" son problemas distintos. Una fuga es un proceso cuyo RSS sube de forma constante y nunca baja, incluso con la máquina inactiva. Una sola instantánea no te lo puede decir — necesitas dos, tomadas con distancia.
1. Quién es el más grande ahora mismo
$ clai lista los procesos ordenados por uso de memoria→ ps -eo pid,comm,rss,%mem --sort=-rss | head -4 PID COMMAND RSS %MEM 218979 firefox 2089376 3.1 269458 verba 1257196 1.9 727108 telegram 1249824 1.9RSS está en kilobytes y es el número que importa: memoria física realmente residente. Esta es tu lista de sospechosos, no tu respuesta.
2. Observa un proceso a lo largo del tiempo
$ clai muestrea la memoria del pid 269458 cada 10 segundos, 6 veces→ pidstat -r -p 269458 10 6Esta es la prueba real. Si el RSS sube en las seis muestras con la carga estable, es una fuga. Si sube y luego se aplana, es una caché llenándose, algo normal que se detendrá solo.
3. Muestreo barato sin paquetes extra
$ clai guarda la memoria de este proceso cada minuto en un archivo→ while sleep 60; do printf '%s %s\n' "$(date +%T)" "$(grep VmRSS /proc/269458/status)"; done | tee mem.logVmRSS: 1257196 kBpidstat vive en el paquete sysstat y no siempre está instalado. /proc/<pid>/status siempre lo está. Déjalo corriendo una hora y la forma de la respuesta será obvia.
4. A dónde fue la memoria dentro del proceso
$ clai muestra el mapa de memoria del pid 269458 ordenado por tamaño→ sudo pmap -x 269458 | sort -k3 -rn | headUna sola asignación anónima que crece entre dos ejecuciones de pmap es el heap. Muchas asignaciones pequeñas que siguen multiplicándose suelen ser pilas de hilos filtradas o archivos mapeados con mmap sin cerrar.
5. Descarta primero la caché de archivos
$ clai muestra el uso de memoria sin contar caché ni buffers→ free -h total used free shared buff/cache availableMem: 62Gi 18Gi 2.1Gi 1.2Gi 42Gi 43GiMira available, no free. Linux llena a propósito la RAM libre con caché de páginas y la devuelve bajo demanda. "Solo 2 GB libres" con 43 GB disponibles es un sistema sano, no una fuga.
6. Confirma que es el proceso, no la máquina
$ clai revisa si el kernel ha estado matando procesos por falta de memoria→ sudo dmesg -T | grep -i 'killed process'Si el OOM killer se activó, el kernel indica qué proceso eligió y su memoria en ese momento. Es la confirmación más sólida que vas a conseguir, y ya está escrita para ti.
Problemas comunes
- RSS cuenta dos veces la memoria compartida. Dos procesos que comparten una librería reportan ambos sus páginas. Para una cifra real por proceso usa PSS de
smemo/proc/<pid>/smaps_rollup. - Reiniciar es un parche, no un diagnóstico. Borra el historial y oculta la evidencia. Primero mide, luego reinicia.
- Los límites del contenedor no se ven desde dentro. Un proceso en un contenedor ve la memoria total del host en
free; el límite real está en/sys/fs/cgroup/memory.max.
Preguntas relacionadas
¿Cuánto crecimiento es una fuga? Cualquier pendiente ascendente sostenida con carga estable. Un proceso que gana 50 MB por hora y nunca los suelta terminará topando con el OOM killer, sin importar cuánta RAM añadas.
¿Es malo un uso alto de memoria en Linux? No por sí solo. La RAM sin usar es RAM desperdiciada — el kernel la usa como caché y la reclama bajo presión. Vigila available y la actividad de swap en su lugar.
¿Qué herramienta encuentra la línea de código que filtra? Valgrind (--leak-check=full) para C y C++, o el perfilador de heap propio de tu lenguaje. Los comandos de aquí encuentran qué proceso; arreglarlo es otra herramienta.
Ver también
- "¿Quién se está comiendo mi CPU ahora mismo?" — monitoreo del sistema en lenguaje sencillo
- Mata el proceso en el puerto 8080 — y otras cosas que siempre buscas en Google
- df dice que el disco está lleno, du dice que no
Dinos qué quieres medir, y CliAI escribe la invocación de pidstat que de otro modo tendrías que buscar. Instálalo en una línea.