Cómo analizar el consumo de memoria de un servidor Linux

Introducción

Analizar el consumo de memoria de un servidor Linux no consiste en mirar una cifra de RAM utilizada y concluir que el equipo necesita una ampliación. Linux aprovecha la memoria disponible para acelerar lecturas, mantener cachés, reducir accesos a disco y mejorar el rendimiento general. Por eso, un servidor puede mostrar casi toda la RAM ocupada y seguir funcionando con margen suficiente.

La interpretación incorrecta de la memoria provoca dos errores opuestos. El primero es ampliar hardware sin necesidad porque la columna de memoria usada parece demasiado alta. El segundo es ignorar señales reales de presión hasta que aparecen latencia, procesos terminados por el sistema, reinicios inesperados, intercambio intensivo con disco o degradación del servicio.

La memoria debe analizarse como un sistema dinámico. Hay que distinguir memoria disponible, caché recuperable, páginas anónimas, memoria compartida, buffers, swap, actividad de intercambio, procesos dominantes, límites de servicios y evolución temporal. Ningún indicador aislado explica por sí solo si existe un problema.

Además, el consumo puede responder a situaciones muy distintas: una base de datos que utiliza caché de forma deliberada, un servidor web con demasiados procesos, una aplicación con fuga de memoria, una máquina virtual sobredimensionada, un contenedor sin límites, una tarea puntual que procesa un lote grande o un servidor que simplemente dispone de poca RAM para su carga habitual.

Este artículo desarrolla un método práctico para analizar memoria en servidores Linux utilizados por profesionales, microempresas, PYMES, sitios WordPress, aplicaciones internas y plataformas LMS. El objetivo es entender qué está ocurriendo, diferenciar uso normal de presión real y decidir con criterio si conviene optimizar, limitar, reconfigurar o ampliar memoria.

Índice

• Por qué la memoria en Linux suele interpretarse mal
• Conceptos básicos que conviene distinguir
• Método de análisis en cinco niveles
• Interpretar correctamente el comando free
• Analizar /proc/meminfo
• Cómo reconocer presión real de memoria
• Interpretar el uso de swap sin alarmismo
• Analizar actividad con vmstat
• Identificar los procesos que más memoria consumen
• Diferencia entre RSS, VSZ, USS y PSS
• Usar top y htop con criterio
• Medir memoria compartida con smem
• Analizar tendencias con sar y registros históricos
• Comprender el OOM killer
• Cómo detectar una posible fuga de memoria
• Analizar memoria por servicio systemd
• Memoria en contenedores y cgroups
• Bases de datos y cachés deliberadas
• Servidores web, WordPress y plataformas LMS
• Máquinas virtuales y sobreasignación
• Diferenciar picos legítimos de problemas estructurales
• Definir umbrales y alertas útiles
• Qué hacer cuando falta memoria
• Cuándo merece la pena ampliar RAM
• Procedimiento práctico de diagnóstico
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Por qué la memoria en Linux suele interpretarse mal

En muchos sistemas operativos se asocia memoria libre con margen disponible. En Linux esa lectura es incompleta. El kernel intenta utilizar la RAM que no necesitan directamente las aplicaciones para almacenar datos que pueden volver a utilizarse, como páginas de archivos, metadatos y bloques leídos recientemente.

Esta política es eficiente: la RAM sin utilizar no aporta rendimiento. Si una aplicación necesita más memoria, parte de la caché puede liberarse. Por tanto, observar poca memoria completamente libre no demuestra que el servidor esté saturado.

La pregunta útil no es “¿cuánta memoria está usada?”, sino:

• ¿cuánta memoria puede asignarse sin empezar a degradar el sistema?;
• ¿la caché puede recuperarse con normalidad?;
• ¿existe intercambio continuo con swap?;
• ¿aumentan las esperas o la latencia?;
• ¿algún proceso crece sin estabilizarse?;
• ¿el kernel está reclamando memoria de forma agresiva?;
• ¿se han terminado procesos por falta de memoria?;
• ¿el problema aparece siempre o solo durante tareas concretas?

La memoria debe correlacionarse con carga, actividad de disco, procesos y tiempos de respuesta. Un servidor puede tener poca memoria disponible y funcionar correctamente. Otro puede mostrar margen aparente y sufrir una tarea que agota rápidamente la RAM en pocos segundos.

Por eso, la revisión debe integrarse dentro de una visión más amplia de monitorización de recursos del servidor, pero con métricas y criterios específicos para memoria.

Conceptos básicos que conviene distinguir

Memoria física total

Es la RAM instalada y disponible para el sistema, descontando pequeñas reservas de hardware o kernel.

Memoria libre

Es la RAM que no se está utilizando en ese momento. Puede ser baja sin que exista un problema.

Memoria disponible

Es una estimación de la memoria que puede asignarse a nuevas aplicaciones sin necesidad de intercambiar de forma significativa. Suele ser más útil que la memoria libre.

Page cache

Contiene datos de archivos y bloques utilizados recientemente. Acelera el sistema y puede reducirse cuando otra carga necesita memoria.

Buffers

Son estructuras relacionadas con operaciones de entrada y salida y metadatos. En sistemas modernos suelen representar una parte menor que la caché.

Memoria anónima

Es memoria que no está respaldada directamente por archivos, como heap y stack de procesos. Cuando falta RAM, puede enviarse a swap.

Memoria compartida

Varias aplicaciones o procesos pueden utilizar las mismas páginas. Sumar la memoria residente de todos ellos puede contar varias veces la misma memoria.

Swap

Es espacio de disco utilizado para desplazar páginas que no necesitan permanecer en RAM. Su mera utilización no demuestra una incidencia; la actividad continua y el efecto en rendimiento sí pueden hacerlo.

Presión de memoria

Describe el esfuerzo que realiza el sistema para encontrar memoria utilizable. Puede manifestarse mediante reclamación frecuente, intercambio, compactación, latencia o terminación de procesos.

Método de análisis en cinco niveles

Un diagnóstico fiable puede organizarse en cinco niveles.

1. Estado global: comprobar memoria total, disponible, caché y swap.
2. Actividad: observar si existe intercambio, reclamación o espera.
3. Responsables: identificar procesos, servicios, contenedores o máquinas virtuales que consumen memoria.
4. Evolución: comparar el comportamiento durante horas, días y cargas representativas.
5. Impacto: relacionar las métricas con latencia, errores, OOM, reinicios o degradación del servicio.

Este orden evita dos problemas. El primero es culpar al proceso que ocupa más memoria aunque su uso sea normal. El segundo es perder tiempo en detalles de procesos cuando el sistema no presenta presión real.

La memoria debe diagnosticarse desde el sistema completo hacia el proceso concreto, y desde la tendencia hacia el evento puntual.

Interpretar correctamente el comando free

El comando más rápido para obtener una visión general es:

free -h

La opción -h presenta los valores en unidades legibles. Una salida habitual contiene columnas como:

• total;
• used;
• free;
• shared;
• buff/cache;
• available.

La columna clave: available

available estima cuánta memoria puede utilizarse para iniciar nuevas aplicaciones sin intercambio significativo. Incluye memoria libre y una parte recuperable de cachés y estructuras del kernel.

Por ejemplo, un servidor con 16 GB puede mostrar 14 GB utilizados, 500 MB libres y 6 GB disponibles. En ese caso no está necesariamente al límite: una parte importante del uso corresponde a memoria recuperable.

La columna used no equivale a consumo irreversible

La forma exacta de calcular used depende de la versión de las herramientas, pero no debe interpretarse como “memoria que ya no puede liberarse”. Para decisiones operativas es preferible observar available, actividad de swap y comportamiento temporal.

Repetir la observación

Una captura aislada puede coincidir con una copia, una actualización o un proceso de mantenimiento. Conviene repetir:

watch -n 2 free -h

Esto permite comprobar si la memoria se recupera al terminar la carga o si continúa disminuyendo.

Analizar /proc/meminfo

/proc/meminfo ofrece una visión más detallada de la memoria gestionada por el kernel:

cat /proc/meminfo

Entre los campos más útiles están:

• MemTotal: memoria física utilizable;
• MemFree: memoria completamente libre;
• MemAvailable: estimación de memoria disponible;
• Buffers: buffers del kernel;
• Cached: caché de páginas;
• SwapCached: páginas presentes en swap y también en RAM;
• Active e Inactive: páginas según actividad reciente;
• AnonPages: memoria anónima;
• Mapped: archivos mapeados;
• Shmem: memoria compartida y sistemas temporales como tmpfs;
• Slab: estructuras internas del kernel;
• SReclaimable: parte del slab potencialmente recuperable;
• Dirty: páginas pendientes de escritura;
• Writeback: páginas que se están escribiendo;
• PageTables: memoria utilizada por tablas de páginas;
• CommitLimit y Committed_AS: compromiso de memoria virtual.

Cuándo profundizar

No es necesario revisar todos los campos en cada comprobación. Conviene profundizar cuando:

• MemAvailable es bajo de forma sostenida;
• AnonPages crece continuamente;
• Shmem aumenta por tmpfs o aplicaciones;
• Slab ocupa una cantidad anormal;
• Dirty permanece alto;
• existen dudas sobre sobrecompromiso de memoria.

Para seleccionar campos concretos:

grep -E 'MemTotal|MemAvailable|Cached|AnonPages|Shmem|Slab|SwapTotal|SwapFree' /proc/meminfo

Cómo reconocer presión real de memoria

La presión real aparece cuando el sistema necesita dedicar esfuerzo creciente a liberar memoria o no puede satisfacer nuevas asignaciones con normalidad.

Señales técnicas

• MemAvailable bajo durante periodos prolongados;
• entrada y salida continua de swap;
• aumento de fallos de página mayores;
• reclamación agresiva de cachés;
• latencia de disco asociada al intercambio;
• procesos bloqueados o muy lentos;
• invocaciones del OOM killer;
• reinicios de servicios por falta de memoria;
• errores de asignación;
• tiempos de respuesta que empeoran al aumentar la carga.

Indicadores PSI

En sistemas compatibles, Pressure Stall Information muestra cuánto tiempo las tareas permanecen detenidas por falta de recursos:

cat /proc/pressure/memory

Los valores some indican periodos en los que al menos alguna tarea está esperando por memoria. Los valores full representan una situación más grave, donde todas las tareas no inactivas afectadas están detenidas simultáneamente.

PSI resulta especialmente útil porque mide el efecto operativo de la presión, no solo cantidades de memoria.

Interpretar el uso de swap sin alarmismo

Que Linux utilice swap no significa automáticamente que falte RAM. El kernel puede trasladar páginas poco utilizadas para reservar memoria física a cachés y cargas activas.

Hay que distinguir entre:

• swap ocupada pero estable: puede ser normal;
• entrada ocasional en swap: puede coincidir con un pico;
• intercambio continuo de entrada y salida: suele indicar presión;
• swap casi llena con latencia: requiere investigación;
• servidor sin swap: puede quedar sin margen ante picos y llegar antes al OOM.

Para ver el estado:

swapon --show
free -h

Swappiness

El parámetro vm.swappiness influye en la tendencia del kernel a intercambiar memoria anónima:

sysctl vm.swappiness

No conviene cambiarlo siguiendo recetas universales. Un valor adecuado depende de la carga, el almacenamiento, la latencia tolerable y la función del servidor. Reducirlo demasiado puede impedir que páginas inactivas salgan de RAM y presionar otras cachés útiles.

No vaciar swap como rutina

Ejecutar swapoff y swapon para “limpiar” la swap puede obligar a traer páginas a RAM, generar una carga intensa y provocar OOM si no existe margen suficiente. Debe hacerse solo con un motivo claro y tras evaluar capacidad.

Analizar actividad con vmstat

vmstat permite observar memoria, procesos, swap, entrada y salida, CPU y espera en intervalos regulares:

vmstat 2

Para memoria interesan especialmente:

• free: memoria libre;
• buff: buffers;
• cache: caché;
• si: datos leídos desde swap por segundo;
• so: datos enviados a swap por segundo;
• wa: tiempo de espera de entrada y salida.

La primera línea suele representar promedios desde el arranque. Las siguientes muestran cada intervalo, por lo que son más útiles para observar el momento actual.

Patrón preocupante

Si si y so permanecen activos, wa aumenta y el servicio se vuelve lento, existe una señal fuerte de intercambio perjudicial. Un valor aislado durante el arranque de una tarea no basta para diagnosticar falta estructural de RAM.

Identificar los procesos que más memoria consumen

Una vez comprobada la presión global, conviene localizar responsables.

ps aux --sort=-%mem | head -n 20

Otra salida centrada en PID, usuario, porcentaje y memoria residente:

ps -eo pid,user,comm,%mem,rss,vsz --sort=-rss | head -n 20

El valor RSS suele expresarse en KiB. Para convertirlo a MiB puede utilizarse una salida procesada, pero lo más importante es comparar procesos y observar su evolución.

Agrupar procesos relacionados

Servicios como PHP-FPM, Apache, PostgreSQL o servidores de aplicaciones utilizan múltiples procesos. Mirar solo el proceso individual más grande puede ocultar el consumo agregado.

Por ejemplo:

ps -C php-fpm -o rss= | awk '{sum+=$1} END {printf "%.1f MiB\n", sum/1024}'

El nombre real del proceso puede variar. Antes de agrupar conviene comprobarlo con ps o pgrep.

Relacionar proceso y función

El inventario técnico ayuda a saber por qué existe cada proceso. Un consumo elevado puede ser legítimo si corresponde a una base de datos crítica, o sospechoso si pertenece a un servicio olvidado. Por eso resulta útil mantener un inventario de servicios instalados en el servidor Linux.

Diferencia entre RSS, VSZ, USS y PSS

VSZ o VIRT

Representa el espacio de memoria virtual asociado al proceso. Puede incluir memoria reservada, archivos mapeados, bibliotecas y zonas que no están realmente en RAM. Un valor enorme no implica por sí solo consumo físico equivalente.

RSS o RES

Indica memoria residente en RAM. Incluye páginas compartidas, por lo que sumar RSS de muchos procesos puede contar varias veces las mismas bibliotecas.

USS

Es la memoria exclusiva del proceso. Si el proceso termina, esa memoria se libera directamente.

PSS

Distribuye proporcionalmente la memoria compartida entre los procesos que la utilizan. Suele ofrecer una estimación más realista del consumo total de conjuntos con muchos procesos similares.

Usar top y htop con criterio

top permite observar procesos en tiempo real:

top

Dentro de top puede ordenarse por memoria con la tecla M. Las columnas habituales incluyen:

• VIRT: memoria virtual;
• RES: memoria residente;
• SHR: parte potencialmente compartida;
• %MEM: porcentaje de RAM física.

htop ofrece una interfaz más cómoda cuando está instalado, pero sigue mostrando métricas que deben interpretarse. Las barras de memoria pueden diferenciar uso de procesos, buffers y caché según configuración.

No diagnosticar por el color de una barra

Una barra casi completa puede representar caché recuperable. Antes de concluir que falta RAM, hay que comprobar memoria disponible, swap, PSI y actividad de intercambio.

Medir memoria compartida con smem

smem permite analizar USS, PSS y RSS cuando está disponible:

smem -tk

Para ordenar por PSS:

smem -r -s pss

Esta herramienta resulta especialmente útil en:

• servidores con muchos procesos PHP-FPM;
• Apache en modo multiproceso;
• aplicaciones Java con procesos auxiliares;
• entornos gráficos;
• servicios que comparten bibliotecas o memoria.

Si smem no está instalado, puede consultarse información detallada en /proc/PID/smaps o /proc/PID/smaps_rollup, aunque su análisis manual es más laborioso.

Analizar tendencias con sar y registros históricos

La memoria debe analizarse durante periodos representativos. sar, incluido habitualmente en el paquete sysstat, puede mostrar históricos si la recopilación está habilitada.

sar -r

Para actividad de swap:

sar -W

Para paginación:

sar -B

Los nombres y campos pueden variar entre versiones, pero el objetivo es observar:

• mínimo de memoria disponible;
• horas en las que cae;
• uso y actividad de swap;
• coincidencia con copias, cron, informes o campañas;
• tendencia semanal o mensual;
• recuperación después del pico.

Conservar contexto

Una gráfica sin eventos operativos es difícil de interpretar. Conviene registrar despliegues, importaciones, matrículas, copias, actualizaciones y cambios de configuración.

Comprender el OOM killer

Cuando el sistema no puede satisfacer una asignación de memoria y no dispone de una salida suficiente, puede activar el Out Of Memory killer para terminar uno o varios procesos y recuperar memoria.

Para revisar eventos recientes:

journalctl -k | grep -i -E 'out of memory|oom|killed process'

También puede utilizarse:

dmesg -T | grep -i -E 'out of memory|oom|killed process'

Qué registrar

• fecha y hora;
• proceso terminado;
• servicio afectado;
• uso de memoria anterior;
• carga simultánea;
• swap disponible;
• si el proceso se reinició;
• impacto empresarial.

Un evento OOM no demuestra necesariamente una fuga. Puede deberse a un pico legítimo, límites mal configurados, demasiados workers, un contenedor sin control o ausencia de swap.

OOM dentro de cgroups

Un servicio o contenedor puede alcanzar su límite particular aunque el host conserve memoria. En ese caso hay que revisar el límite del grupo, no solo el estado global.

Cómo detectar una posible fuga de memoria

Una fuga aparece cuando un proceso conserva memoria que ya no necesita y su consumo crece con el tiempo sin estabilizarse.

Patrón típico

• RSS o PSS aumenta progresivamente;
• el crecimiento se relaciona con solicitudes o trabajos;
• la memoria no vuelve al nivel anterior tras terminar la carga;
• reiniciar el proceso recupera memoria temporalmente;
• el patrón se repite después del reinicio;
• el crecimiento termina en OOM o degradación.

Registrar un proceso

Una observación sencilla puede repetirse con:

watch -n 10 'ps -p PID -o pid,etime,rss,vsz,%mem,cmd'

Para un análisis serio conviene almacenar los valores con fecha y compararlos con volumen de trabajo.

No confundir fuga con caché de aplicación

Algunas aplicaciones aumentan memoria hasta alcanzar un tamaño objetivo y después se estabilizan. Otras retienen arenas o memoria asignada para reutilizarla. Eso puede parecer una fuga desde fuera, aunque el proceso la gestione deliberadamente.

La prueba clave es la tendencia sostenida, el impacto y el conocimiento del comportamiento esperado de la aplicación.

Analizar memoria por servicio systemd

En sistemas con systemd puede consultarse el estado de un servicio:

systemctl status nombre-servicio

Para ver métricas de un cgroup concreto:

systemctl show nombre-servicio -p MemoryCurrent -p MemoryPeak -p MemoryMax

La disponibilidad de propiedades concretas depende de la versión de systemd y de la configuración del sistema.

Límites de memoria

systemd permite establecer límites mediante opciones como MemoryMax. Sin embargo, aplicar un límite sin entender el consumo puede provocar terminaciones recurrentes.

Un límite debe basarse en:

• consumo normal;
• pico legítimo;
• margen de seguridad;
• comportamiento al alcanzar el límite;
• prioridad del servicio;
• capacidad global del host.

La configuración y los límites deberían quedar recogidos en la documentación operativa del servidor Linux.

Memoria en contenedores y cgroups

Los contenedores comparten el kernel del host, pero pueden tener límites propios. El análisis debe distinguir consumo del host, cgroup y proceso interno.

En Docker puede utilizarse:

docker stats --no-stream

Este resumen muestra consumo y límite de memoria por contenedor. También conviene revisar:

• si existe límite;
• si el límite es razonable;
• si el contenedor reinicia;
• si se produjo OOMKilled;
• si el consumo crece entre despliegues;
• si varios contenedores compiten en el mismo host.

Para inspeccionar un contenedor:

docker inspect nombre-contenedor

Memoria de caché y métricas

Las cifras de contenedores pueden presentar la caché de forma diferente según herramienta y versión. No conviene comparar directamente valores de Docker, free y procesos sin conocer qué incluye cada uno.

Sin límites no significa sin coste

Un contenedor sin límite puede consumir memoria del host hasta afectar a servicios no relacionados. En servidores pequeños, los límites proporcionados ayudan a contener errores, pero necesitan observación y pruebas.

Bases de datos y cachés deliberadas

Las bases de datos utilizan memoria para buffers, índices, conexiones, ordenaciones y cachés. Un consumo elevado puede ser intencionado y beneficioso.

Preguntas necesarias

• ¿qué tamaño de caché está configurado?;
• ¿cuántas conexiones simultáneas existen?;
• ¿cada conexión puede reservar memoria adicional?;
• ¿hay consultas grandes o temporales?;
• ¿la base comparte servidor con web, LMS y copias?;
• ¿el uso se estabiliza después del arranque?;
• ¿la caché mejora realmente el rendimiento?

Reducir la memoria de una base de datos únicamente para que free muestre más espacio puede empeorar el servicio y aumentar lecturas de disco.

Memoria por conexión

Algunos parámetros se aplican por conexión, operación o consulta. Multiplicar el máximo teórico por el número de conexiones ayuda a detectar configuraciones peligrosas, aunque el consumo real dependa de la actividad.

La decisión debe considerar la función del servidor y la arquitectura completa, no una cifra aislada.

Servidores web, WordPress y plataformas LMS

En un servidor web con WordPress o LMS, la memoria suele repartirse entre:

• servidor web;
• procesos PHP-FPM;
• base de datos;
• caché de objetos;
• tareas programadas;
• generación de informes;
• copias de seguridad;
• antivirus o seguridad;
• monitorización;
• sistema operativo y caché de archivos.

PHP-FPM

El consumo agregado depende del número de procesos y de la memoria de cada uno. Un valor excesivo de workers puede agotar RAM durante picos. Un valor demasiado bajo crea colas aunque quede memoria disponible.

Para dimensionar conviene medir varios procesos durante carga real, utilizar PSS cuando sea posible y reservar margen para base de datos, kernel, copias y tareas simultáneas.

LMS

Una plataforma LMS puede presentar picos durante matrículas, cuestionarios, informes, copias, importación de usuarios o procesos cron. El promedio diario puede ocultar estos momentos.

Debe observarse:

• alumnos concurrentes;
• procesos PHP activos;
• consultas de base de datos;
• tareas cron pendientes;
• generación de archivos;
• cachés;
• hora de las copias;
• memoria disponible en el peor pico.

Copias en el mismo servidor

Comprimir archivos y exportar bases puede consumir memoria y disco simultáneamente. Conviene programar estas tareas fuera de picos y evitar que coincidan con informes o campañas.

Máquinas virtuales y sobreasignación

En virtualización hay que analizar host y huésped. Un servidor virtual puede mostrar memoria disponible mientras el host está presionado, o al contrario.

Aspectos que deben revisarse

• RAM física del host;
• suma de memoria asignada a huéspedes;
• reservas y límites;
• ballooning;
• swap del host y de los huéspedes;
• picos simultáneos;
• memoria utilizada por el hipervisor;
• servicios adicionales del host.

La sobreasignación puede funcionar mientras las máquinas no utilicen simultáneamente su máximo. El riesgo aparece cuando coinciden copias, actualizaciones, informes o actividad de usuarios.

No conviene asignar toda la RAM física a huéspedes. El host necesita memoria para kernel, cachés, procesos de administración y recuperación.

Diferenciar picos legítimos de problemas estructurales

Pico legítimo

Suele cumplir varias condiciones:

• tiene una causa conocida;
• duración limitada;
• la memoria se recupera;
• no produce OOM;
• la latencia permanece aceptable;
• existe margen para otras funciones críticas.

Problema estructural

• la memoria disponible baja cada semana;
• el intercambio es frecuente;
• la carga normal ya alcanza el límite;
• los reinicios solo alivian temporalmente;
• el crecimiento de usuarios aumenta directamente la presión;
• las tareas de mantenimiento no pueden ejecutarse con seguridad;
• no existe margen para actualizaciones o fallos parciales.

Pico imprevisible

Algunos picos no son recurrentes, pero tienen suficiente impacto para justificar límites, colas, procesamiento por lotes o reserva de capacidad.

Definir umbrales y alertas útiles

No existe un porcentaje universal válido para todos los servidores. Los umbrales deben combinar cantidad, duración, actividad e impacto.

Umbral informativo

Memoria disponible menor de lo habitual o crecimiento de un proceso. Sirve para revisar tendencia.

Umbral de planificación

El margen se reduce durante picos y el crecimiento indica que se alcanzará un límite en los próximos meses.

Umbral operativo

Existe intercambio continuo, latencia o riesgo de que una tarea normal no termine.

Umbral crítico

OOM, procesos terminados, full PSI significativo o degradación grave.

Alertas combinadas

Una alerta puede requerir varias condiciones:

• memoria disponible baja durante varios minutos;
• swap-in o swap-out sostenido;
• presión PSI por encima del comportamiento normal;
• aumento de latencia;
• proceso dominante creciendo;
• evento OOM.

Las alertas deben tener responsable y procedimiento. De lo contrario solo generan ruido.

Qué hacer cuando falta memoria

La actuación depende de la causa. Las opciones incluyen:

Reducir concurrencia

Limitar workers, conexiones o tareas simultáneas puede reducir picos, aunque también puede crear colas.

Corregir una fuga

Actualizar, revisar código, aislar el componente o aplicar reinicios temporales mientras se resuelve la causa.

Ajustar cachés

Reducir cachés sobredimensionadas solo después de medir el efecto en rendimiento.

Separar tareas

Mover copias, informes, conversiones o procesos de datos a otro horario o servidor.

Eliminar servicios innecesarios

Desactivar componentes sin función real, después de validarlos en el inventario y comprobar dependencias.

Aplicar límites

Usar cgroups, systemd o límites de contenedor para evitar que una carga no crítica afecte a todo el host.

Añadir o ajustar swap

Puede aportar margen ante picos, pero no sustituye RAM cuando la carga activa necesita memoria continuamente.

Ampliar RAM

Es la solución adecuada cuando el consumo normal y justificado supera la capacidad disponible y la optimización no ofrece suficiente margen.

Cuándo merece la pena ampliar RAM

La ampliación está justificada cuando existe evidencia repetida:

• presión real durante cargas normales;
• swap activa con degradación;
• OOM o reinicios por falta de memoria;
• servicios correctamente configurados que necesitan más caché;
• crecimiento previsto de usuarios o datos;
• falta de margen para mantenimiento;
• coste de optimización superior a la ampliación;
• hardware compatible y capacidad de ampliación disponible.

Cuándo no ampliar todavía

• solo se ha observado una captura de free;
• la mayor parte es caché recuperable;
• un servicio olvidado consume memoria;
• existe una fuga conocida;
• los límites están mal configurados;
• el problema real es CPU, disco o consultas;
• la carga puntual puede programarse de otra forma.

La compra debe basarse en un margen objetivo y una previsión de crecimiento, no en llenar todos los zócalos disponibles por precaución.

Procedimiento práctico de diagnóstico

1. Registrar fecha, hora y síntoma.
2. Ejecutar free -h. Observar memoria disponible y swap.
3. Ejecutar vmstat 2. Revisar si, so y espera.
4. Consultar PSI. Revisar /proc/pressure/memory.
5. Listar procesos. Ordenar por RSS y agrupar servicios relacionados.
6. Revisar OOM. Consultar journal y mensajes del kernel.
7. Identificar el evento. Usuarios, cron, copia, importación o despliegue.
8. Comparar con histórico. Determinar si es nuevo, recurrente o creciente.
9. Separar causa y efecto. Confirmar si la presión coincide con degradación.
10. Aplicar una medida controlada. Ajuste, límite, horario, corrección o ampliación.
11. Volver a medir. Comprobar que el problema se reduce sin trasladarse a otro recurso.
12. Documentar. Registrar hallazgo, decisión y resultado.

Este procedimiento debe adaptarse a la distribución y herramientas instaladas. Los cambios de configuración deben probarse y poder revertirse.

Errores frecuentes

Considerar problemática toda la RAM usada

Ignora la caché recuperable y el diseño normal de Linux.

Mirar solo memoria libre

La memoria disponible ofrece una estimación más útil.

Alarmarse porque existe swap ocupada

Importa la actividad, no solo la ocupación.

Vaciar cachés manualmente

Puede empeorar el rendimiento y no resuelve la causa. El kernel gestiona la caché de forma automática.

Sumar RSS sin considerar memoria compartida

Puede sobreestimar el consumo total de procesos similares.

Culpar al proceso más grande

Puede estar utilizando memoria de forma legítima y aportar rendimiento.

Reiniciar como única solución

Recupera memoria temporalmente, pero oculta fugas y dificulta medir.

Cambiar swappiness por una receta genérica

El valor debe responder a la carga real.

Limitar servicios sin medir picos

Puede provocar OOM dentro del cgroup o reducir capacidad.

Ignorar el host de virtualización

La presión puede estar fuera del huésped.

No conservar histórico

Impide diferenciar un pico puntual de una tendencia.

Ampliar RAM sin revisar arquitectura

Puede posponer una fuga, una configuración incorrecta o un servicio innecesario.

Lista de comprobación

• ¿Se conoce la memoria total del servidor?
• ¿Se observa MemAvailable y no solo memoria libre?
• ¿Se distingue caché de memoria anónima?
• ¿Se conoce la cantidad y tipo de swap?
• ¿Se mide actividad de swap?
• ¿Se revisan si y so en vmstat?
• ¿Se consulta presión PSI cuando está disponible?
• ¿Se identifican procesos por RSS?
• ¿Se utiliza PSS cuando hay mucha memoria compartida?
• ¿Se agrupan procesos del mismo servicio?
• ¿Se revisan eventos OOM?
• ¿Se conoce qué servicio fue terminado?
• ¿Se conserva histórico?
• ¿Se registran picos operativos?
• ¿Se compara memoria con latencia y disco?
• ¿Se revisan límites systemd o cgroups?
• ¿Los contenedores tienen límites proporcionados?
• ¿Se analiza host y huésped en virtualización?
• ¿Se conoce la memoria configurada en la base de datos?
• ¿Se ha dimensionado la concurrencia de PHP-FPM o Apache?
• ¿Copias e informes coinciden con horas de uso?
• ¿Un proceso crece sin estabilizarse?
• ¿La memoria se recupera al terminar la carga?
• ¿Las alertas tienen duración y contexto?
• ¿Las decisiones están documentadas?
• ¿Se vuelve a medir después de cada ajuste?

Preguntas frecuentes

Conclusión

Analizar la memoria de un servidor Linux exige distinguir ocupación de presión. Una gran cantidad de RAM utilizada puede corresponder a caché útil y recuperable, mientras que una cantidad aparentemente moderada puede ocultar intercambio, límites de cgroups o un proceso que crece rápidamente.

La revisión debe comenzar por memoria disponible, continuar con actividad de swap y PSI, identificar procesos y servicios responsables, y terminar relacionando las métricas con el impacto real sobre aplicaciones, usuarios y tareas.

Ninguna cifra aislada —ni RAM usada, ni swap ocupada, ni RSS de un proceso— permite decidir por sí sola que un servidor necesita más memoria.

Los comandos free, vmstat, ps, top, smem, sar y los registros del kernel aportan perspectivas complementarias. Su valor está en utilizarlos dentro de un procedimiento repetible y con histórico.

En servidores WordPress y LMS, la memoria debe distribuirse entre procesos web, PHP, base de datos, cachés, copias, cron y sistema operativo. Dimensionar un solo componente sin considerar el conjunto suele desplazar el problema.

Cuando la causa es una fuga, un servicio innecesario, una concurrencia excesiva o un límite incorrecto, ampliar RAM puede ocultar temporalmente el problema. Cuando la carga normal y justificada supera la capacidad, la ampliación es una decisión correcta y normalmente rentable.

La disciplina recomendada es sencilla: medir, conservar contexto, identificar tendencia, actuar sobre la causa y volver a medir. Así la memoria deja de ser una cifra alarmante y se convierte en una capacidad gestionable.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en Linux, administración de sistemas, rendimiento, infraestructura y continuidad operativa.