Calcular la RAM de un servidor exige saber qué procesos están activos al mismo tiempo y cómo varía su consumo. La cifra de memoria instalada es solo el límite; la planificación necesita observar workers, base de datos, cachés, tareas y picos de concurrencia.
Un servidor puede mostrar una media cómoda y fallar durante unos minutos cuando coinciden tráfico web, una importación y una copia. La media no describe ese máximo.
Qué ocupa memoria
El sistema operativo y sus servicios necesitan una base de memoria. Sobre ella se ejecutan servidor web, runtime, workers de aplicación, base de datos, agentes, contenedores y procesos de mantenimiento. Cada worker puede tener un tamaño distinto según código, extensiones, consultas y datos manejados.
Redis o Valkey y otras cachés también consumen memoria. Guardar más datos en caché puede reducir lecturas, pero deja menos margen para procesos que deben ejecutarse fuera de ella.
Buffers y caché del sistema
Linux utiliza memoria libre para caché de archivos y puede liberarla cuando otro proceso la necesita. Ver “caché” en una métrica no significa automáticamente que exista una fuga. Hay que distinguir memoria anónima de procesos, páginas cacheadas, buffers y memoria disponible para nuevas asignaciones.
Una base de datos mantiene sus propios buffers y puede competir con workers PHP por el mismo recurso. Ajustar ambos sin observar la presión total puede desplazar el problema a swap u OOM.
Concurrencia y picos
El consumo depende del número de procesos simultáneos, no solo del volumen diario. Si cada worker usa una cantidad aproximada de memoria, duplicar workers puede acercar el límite aunque la CPU esté libre. Las conexiones de base de datos y tareas de fondo añaden su propio consumo.
Un ejemplo: el tráfico ordinario utiliza pocos workers, pero una campaña activa muchas peticiones mientras un proceso genera miniaturas. El promedio del día puede ocultar el pico que desencadena la terminación de un proceso.
Swap: red de seguridad, no sustituto
La swap permite mover páginas menos activas a almacenamiento cuando falta RAM, pero es mucho más lenta que la memoria. Puede evitar un fallo inmediato en algunos escenarios y, a la vez, aumentar latencia si el sistema empieza a intercambiar de forma continua. No debe usarse para justificar una configuración que necesita más memoria.
Monitoriza presión de memoria, actividad de swap y latencia de disco. Un servidor que sobrevive gracias a swap puede estar degradado.
Entender un OOM
El kernel o un supervisor puede terminar procesos cuando no hay memoria suficiente. Revisa qué ocurrió antes, qué proceso creció, qué tareas coincidieron y si existe un límite impuesto por contenedor o servicio. Aumentar RAM sin corregir una fuga o una configuración de workers puede retrasar, no resolver, la siguiente incidencia.
Medir el uso que importa
Observa percentiles y picos de memoria disponible, memoria anónima, caché, swap, número de workers, conexiones de base de datos y duración de tareas. Correlaciona las métricas con logs y horarios de cron. Una fotografía tomada en reposo no sirve para decidir capacidad.
Crear margen sin desperdiciar recursos
El margen debe permitir actualizaciones, tareas extraordinarias y pequeñas variaciones de carga. No hay una cantidad universal: un servidor de contenidos, una tienda y una base de datos analítica tienen perfiles distintos. Ajusta workers, límites de conexión y tamaño de caché junto con la memoria disponible.
Qué métricas observar antes de añadir memoria
Comprueba si el límite real es RAM, CPU, I/O o una consulta externa. Si hay presión sostenida y procesos correctamente configurados, ampliar memoria puede ser razonable. Si solo aparece un proceso anómalo, investígalo antes. La capacidad adecuada se deriva del comportamiento observado y de la carga que se espera operar.
Procesos que suelen quedar fuera
Los agentes de seguridad, copias, compilaciones, generación de imágenes y tareas de mantenimiento pueden coincidir con la carga web. En contenedores, los límites y reservas también modifican lo que el proceso cree disponible. Inventaría estos consumidores antes de atribuir una presión de memoria a la aplicación principal.
Una fuga de memoria se reconoce por un crecimiento sostenido que no vuelve a bajar después de terminar peticiones o tareas. Aumentar la RAM puede retrasar el fallo, pero hay que revisar el proceso, sus límites y la versión del componente.
Interpretar las métricas con contexto
Compara memoria disponible y presión con workers, conexiones, swap, I/O y tiempos de respuesta. Una caída puntual puede ser normal si el sistema libera caché; una presión mantenida junto a intercambio y latencia indica otro escenario. Define umbrales distintos para aviso y acción para no reaccionar a cada oscilación.
Planificar cambios
Antes de ampliar memoria, conserva una medición de referencia y revisa que la aplicación puede aprovecharla. Después del cambio comprueba que no se han aumentado workers o buffers sin control. Más RAM puede permitir mayor concurrencia, pero también puede esconder una consulta o proceso que sigue siendo ineficiente.
Corregir antes de ampliar
Antes de comprar memoria, revisa workers que superan su límite, conexiones que no se liberan, cachés sin tamaño máximo y tareas que acumulan datos. Una configuración más pequeña y controlada puede ser más estable que una ampliación que permite que el proceso siga creciendo sin límite.
Después de ajustar, repite la prueba bajo el mismo pico y comprueba memoria disponible, swap, OOM, latencia y errores. El objetivo es recuperar margen operativo, no solo cambiar una cifra del panel.