Su VPS tiene espacio libre: ¿por qué falló? RAM, swap y el OOM killer de Linux

La alerta llega a las 2:17 de la madrugada.

Su sitio web está caído.

Inicias sesión en el VPS y compruebas lo obvio:

df -h

El disco está lleno sólo en un 38 por ciento.

Entonces, ¿por qué se detuvo PHP? ¿Por qué desapareció la base de datos? ¿Por qué el registro del sistema dice que un proceso fue "eliminado"?

Porque el espacio en disco y la memoria de trabajo son recursos diferentes.

Un servidor puede tener cientos de gigabytes de almacenamiento libre y aun así quedarse sin RAM. Cuando la presión de la memoria se vuelve severa, Linux tiene que tomar decisiones difíciles. Puede recuperar memoria, mover algunas páginas inactivas para intercambiar, rechazar asignaciones o, cuando la situación se vuelve crítica, invocar al OOM killer.

El OOM killer suena dramático porque lo es.

Su trabajo es sacrificar un proceso para que el sistema operativo tenga la oportunidad de sobrevivir.

Si ejecuta un VPS, un servidor dedicado, una pila web, una base de datos, contenedores o un panel de control ocupado, comprender este comportamiento es una de las habilidades de resolución de problemas más útiles que puede aprender. Convierte una misteriosa "caída del servidor" en un problema de recursos mensurable.

Esta guía mantiene la explicación práctica.

Compare la memoria asignada en nuestros planes VPS con las necesidades conjuntas de su aplicación, base de datos y tareas en segundo plano. Nuestra guía de VPS y la comparación de hosting ayudan a elegir una plataforma inicial adecuada.

Capítulo 1: El espacio en disco es el almacén, la RAM es el banco de trabajo

Imagínate un taller.

El almacén tiene capacidad para diez mil cajas. Ese es su disco.

En el banco de trabajo sólo caben diez cajas a la vez. Esa es su RAM.

Puede que tengas una enorme capacidad de almacenamiento, pero el trabajo se detiene si el banco está completamente cubierto y cada nueva tarea necesita más espacio de trabajo.

Las aplicaciones utilizan RAM para datos activos.

Un servidor web mantiene procesos, conexiones, buffers y cachés en la memoria.

Los trabajadores de PHP necesitan memoria mientras ejecutan solicitudes.

Una base de datos mantiene índices, búferes de consultas, conexiones, estructuras temporales y páginas almacenadas en caché en la memoria.

El sistema operativo también utiliza RAM.

También lo hace su agente de monitoreo, panel de control, herramienta antivirus, software de respaldo, tiempo de ejecución del contenedor, servicio DNS, servidor de correo y todo lo demás que se ejecuta en la máquina.

El espacio libre en disco no soluciona la escasez en el banco de trabajo.

Capítulo 2: Qué hace Linux con la RAM

Linux intenta utilizar la memoria de manera eficiente.

Esto crea otro malentendido común.

Un administrador ejecuta:

free -h

y ve un pequeño número debajo de free.

El pánico sigue.

Pero Linux utiliza intencionalmente RAM que de otro modo estaría inactiva para cachés útiles. La memoria utilizada para el caché de archivos a menudo se puede recuperar cuando las aplicaciones la necesitan.

El número más útil a tener en cuenta suele ser la memoria disponible en lugar de esperar que la mayor parte de la RAM quede completamente sin utilizar.

Una salida simplificada puede verse así:

total        used        free      shared  buff/cache   available
Mem:            8Gi         5Gi       400Mi       300Mi        2.6Gi        2.2Gi
Swap:           2Gi       200Mi        1.8Gi

Solo 400 MiB están etiquetados como gratuitos, pero es posible que aún haya alrededor de 2,2 GiB disponibles para nuevas cargas de trabajo.

Ese servidor no está automáticamente en problemas.

La resolución de problemas de memoria tiene que ver con la presión, el crecimiento y el comportamiento a lo largo del tiempo, no con un número aterrador sacado de contexto.

Capítulo 3: ¿Qué hace realmente el swap?

El swap es espacio en disco que Linux puede usar como una extensión para las páginas de memoria que no necesitan permanecer en la RAM física en todo momento.

El swap puede ser una partición o un archivo.

Compruébalo con:

swapon --show

y:

free -h

Red Hat describe el swap como almacenamiento temporal para procesos y datos inactivos cuando la memoria física está llena. Puede ayudar a prevenir condiciones de falta de memoria, pero es más lenta que la RAM y no debe considerarse como un reemplazo de una memoria del tamaño adecuado.

Ese punto importa.

Un pequeño cambio puede darle al servidor un respiro durante un breve pico.

Un servidor que envía constantemente grandes cantidades de datos activos al swap puede volverse terriblemente lento.

La máquina no ha solucionado su problema de memoria. Ha cambiado el síntoma de "falta de memoria" a "todo se siente congelado".

Capítulo 4: El momento en que Linux se queda sin opciones

Las aplicaciones solicitan memoria al kernel.

La mayoría de las veces, el kernel satisface esas solicitudes.

Cuando la memoria se agota, Linux puede recuperar cachés e intentar otras estrategias de administración de memoria. Si existe un swap, las páginas de memoria inactivas se pueden mover allí.

Pero los recursos son finitos.

Con el tiempo, el sistema puede llegar a un punto en el que no pueda satisfacer una asignación de memoria importante.

Aquí es donde el mecanismo Out Of Memory cobra relevancia.

Linux puede invocar al OOM killer para seleccionar un proceso y finalizarlo, liberando memoria para que el resto del sistema pueda continuar.

La documentación del kernel describe un proceso de selección de OOM que utiliza heurísticas para decidir qué tarea es una víctima adecuada. Linux también expone controles como oom_score_adj que pueden influir en la probabilidad de que se seleccione un proceso.

Un contenedor o servicio systemd también puede alcanzar su propio límite de memoria de cgroup mientras el host todavía tiene RAM disponible. En sistemas que utilizan systemd-oomd, una política de presión de memoria en el espacio de usuario puede detener un cgroup antes de que el kernel informe un OOM global; inspeccionar los límites del servicio/contenedor y el diario systemd-oomd, así como los mensajes del kernel cuando la evidencia apunte en esa dirección.

Para la mayoría de los administradores de hosting, la idea clave no es el algoritmo de puntuación.

La idea clave es esta:

Cuando Linux cancela un servicio durante un evento OOM, el proceso cancelado puede ser víctima de la escasez, no la causa original de la escasez.

Esa distinción cambia la forma de investigar.

Capítulo 5: El problema de la víctima inocente

Supongamos que una aplicación PHP tiene una pérdida de memoria.

El tráfico aumenta.

Cientos de trabajadores PHP crecen con el tiempo.

MySQL está utilizando una cantidad razonable de memoria.

Finalmente, el servidor se agota.

El OOM killer elige a mysqld como víctima porque matarlo liberaría rápidamente una gran cantidad de memoria.

Su seguimiento informa entonces:

El servicio de base de datos se detuvo.

Es tentador concluir:

MySQL causó el incidente.

Quizás así fue.

Quizás no fue así.

La base de datos podría haber sido simplemente el objetivo útil más grande disponible cuando el sistema ya estaba en problemas.

Es por eso que un incidente OOM requiere un análisis del cronograma.

Necesita saber qué cargas de trabajo estaban creciendo antes de la eliminación, no solo qué proceso murió al final.

Una captura actual de memoria no permite reconstruir por sí sola un incidente anterior. Utilice las marcas de tiempo y el historial de servicios descritos en nuestra guía de logs VPS y mantenga un historial de monitorización.

Capítulo 6: Cómo confirmar un evento OOM

En un sistema moderno que utilice systemd, comience con el diario del kernel.

Prueba:

sudo journalctl -k | grep -Ei 'out of memory|oom|killed process'

También puede utilizar:

sudo dmesg -T | grep -Ei 'out of memory|oom|killed process'

Dependiendo de los permisos, la rotación de registros y la configuración del sistema, una fuente puede ser más útil que la otra.

Un evento OOM a menudo deja mensajes que indican que el kernel invocó al OOM killer y finalizó un proceso.

No se detenga después de encontrar la línea.

Registro:

• la marca de tiempo
• El proceso muerto
• La identificación del proceso
• Los valores relacionados con la memoria que se muestran en el evento.
• Los servicios activos en ese momento.
• Tráfico o actividad laboral aproximadamente en el mismo minuto
• Trabajos cron, copias de seguridad, escaneos, importaciones o procesos por lotes que se ejecutan cerca
• Eventos de contenedor o panel de control

La muerte final es la última página de la historia.

su trabajo es encontrar la primera página.

Capítulo 7: Los primeros cinco comandos que ejecutaría

Si el servidor es lo suficientemente estable como para inspeccionarlo, estos comandos proporcionan una primera imagen útil.

1. Memoria actual

free -h

Mire la memoria total disponible y el uso de swap.

2. Cambiar configuración

swapon --show

Ninguna salida normalmente significa que el swap no está activo.

3. Principales consumidores de memoria

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

Esto proporciona una lista rápida de procesos que utilizan el mayor porcentaje de RAM.

4. Actividad del sistema en vivo

vmstat 1 10

vmstat puede ayudar a mostrar la memoria, ejecutar colas, E/S e intercambiar actividad durante varios segundos.

En vmstat, si indica la entrada desde swap y so la salida hacia swap; ambas tasas ayudan a evaluar si el sistema está moviendo páginas de forma sostenida.

5. Evidencia OOM del núcleo

sudo journalctl -k | grep -Ei 'out of memory|oom|killed process'

Estos comandos no reemplazan el monitoreo, pero ayudan a responder la pregunta inmediata:

¿Es esto realmente un incidente de memoria?

Capítulo 8: Causas comunes en servidores de hosting

Demasiados trabajadores PHP

Cada proceso PHP-FPM consume memoria.

Una configuración que permita muchos más trabajadores de los que el VPS puede soportar puede comportarse bien en condiciones de tráfico ligero y colapsar durante una ráfaga.

Si un trabajador usa 120 MB y usted permite 80 trabajadores, el grupo de procesos teórico puede resultar muy costoso en un VPS pequeño.

No mida el número de trabajadores basándose en ilusiones. Mida la memoria del proceso real bajo una carga realista.

MySQL o MariaDB dimensionados para una máquina más grande

Los ejemplos de ajuste de bases de datos de Internet son peligrosos cuando se copian a ciegas.

Un grupo de buffer o un tamaño de caché que sea razonable en un servidor de 64 GB puede sofocar un VPS de 4 GB.

Trabajos de copia de seguridad y compresión.

Una copia de seguridad nocturna puede aumentar la CPU, la E/S del disco, el recuento de procesos y el uso de la memoria al mismo tiempo.

Si sus incidentes ocurren según un cronograma, inspeccione las tareas cron y las ventanas de respaldo.

Escáneres de malware y agentes de seguridad.

Las herramientas de seguridad son importantes, pero algunos análisis requieren muchos recursos.

Prográmelos y dimensione teniendo en cuenta el resto de la carga de trabajo del servidor.

Picos de tráfico

Una promoción, una oleada de bots, una ráfaga de rastreadores, un ataque o un vínculo viral pueden multiplicar los trabajadores de aplicaciones concurrentes.

El problema puede ser la concurrencia en lugar de que una solicitud consuma mucha memoria.

Fugas de memoria

Un proceso crece lentamente y nunca devuelve la memoria como se esperaba.

Un reinicio elimina el síntoma, razón por la cual las fugas pueden ocultarse durante semanas.

Si la memoria sube en forma de escalera entre reinicios, investigue la aplicación o demonio en lugar de agregar RAM infinita.

Contenedores sin límites sensatos

Una plataforma de contenedores puede hacer que una carga de trabajo parezca aislada mientras aún compite por una memoria de host finita.

Los límites, las reservas y el seguimiento son importantes.

Capítulo 9: ¿El swap es bueno o malo?

La respuesta útil es: depende de la carga de trabajo y del objetivo.

El swap no es malo.

El swap tampoco es RAM libre.

Un área de swap modesta puede evitar que un pico corto se convierta en una terminación por OOM inmediata. Puede dar a las páginas inactivas un lugar al que ir y darle al administrador un poco de tiempo para reaccionar.

Pero un servidor que depende constantemente de un gran swap está bajo presión de memoria.

Para cargas de trabajo sensibles a la latencia, el swap puede ser especialmente notable porque el almacenamiento es mucho más lento que la RAM.

La pregunta correcta no es:

¿Linux debería alguna vez usar swap?

Las mejores preguntas son:

• ¿La actividad swap es ocasional o constante?
• ¿Los usuarios ven latencia cuando aumenta el swap?
• ¿El conjunto de trabajo es mayor que la RAM física?
• ¿Hay algún servicio mal configurado?
• ¿El VPS simplemente tiene un tamaño insuficiente?
• ¿Agregar RAM resolvería la causa raíz o solo retrasaría una fuga?

La guía de Red Hat es directa: el swap puede ayudar cuando la RAM está llena, pero no debe considerarse un reemplazo de más memoria física.

Capítulo 10: Por qué borrar la caché no suele ser la verdadera solución

Durante los incidentes de memoria, los administradores a veces buscan comandos que "liberan RAM".

Esto puede provocar una limpieza agresiva de la caché o reinicios repetidos del servicio.

Un reinicio puede restaurar temporalmente el servicio.

También puede borrar evidencia útil y ocultar el patrón de crecimiento que necesitaba diagnosticar.

Linux ya sabe cómo recuperar el caché cuando las aplicaciones realmente necesitan memoria.

Si el sistema llega repetidamente a OOM, la verdadera investigación pertenece a:

• Dimensionamiento de la carga de trabajo
• El proceso cuenta
• Comportamiento de la aplicación
• Fugas de memoria
• Configuración de base de datos
• Límites de contenedores
• Patrones de tráfico
• Trabajos programados
• Capacidad de RAM física

Trate el borrado manual de caché como una acción de solución de problemas que necesita un motivo específico, no un ritual de mantenimiento.

Si una carga optimizada sigue superando sus recursos, compare un VPS mayor con nuestros servidores dedicados. Para un sitio que no necesita controlar el sistema operativo, el hosting compartido puede reducir las tareas administrativas. La elección debe basarse en las necesidades medidas de la carga.

Capítulo 11: Planificación de la capacidad en números simples

No necesita un modelo de rendimiento avanzado para evitar errores obvios.

Comience con un presupuesto de memoria.

Supongamos que un VPS tiene 8 GB de RAM.

Capacidad de reserva para el sistema operativo y servicios en segundo plano.

Luego estime los principales consumidores:

Operating system and base services     1.2 GB
Database                                2.5 GB
Web server                              0.4 GB
PHP workers                             2.4 GB
Security and monitoring                 0.5 GB
Safety margin                           1.0 GB

Totales:

8.0 GB

Eso ya es difícil porque las cargas de trabajo reales se mueven.

Si la memoria de trabajo de PHP se duplica bajo ciertas solicitudes, o la base de datos necesita un aumento temporal, el presupuesto se rompe.

Un margen de seguridad no es RAM desperdiciada. Es lo que evita que una explosión normal se convierta en un incidente.

Si todavía está eligiendo el tamaño de la plataforma, nuestra guía Comparación de hosting compartido, VPS, dedicado y en la nube le ayudará a tomar la decisión sobre la infraestructura antes de que comience el ajuste.

Capítulo 12: Considere la memoria como una tendencia, no como una emergencia

El mejor momento para investigar la presión de la memoria es antes de que aparezca el OOM killer.

Pista:

• RAM usada y disponible
• Intercambiar uso
• Tasa de swap-in y swap-out
• Memoria por proceso
• Recuento de trabajadores PHP-FPM
• Memoria de base de datos
• Memoria del contenedor
• Solicitar simultaneidad
• Carga promedio
• E/S espera
• Reiniciar eventos
• eventos OOM

Establezca alertas con tiempo suficiente para actuar.

Una alerta al 95 por ciento puede llegar demasiado tarde si la carga de trabajo puede consumir la memoria restante en segundos.

Un diseño de seguimiento útil suele tener múltiples umbrales y se centra en la presión sostenida en lugar de en una muestra breve.

Por ejemplo, un breve período de uso elevado de la memoria puede ser inofensivo si la memoria disponible se recupera inmediatamente. Un lento aumento diario del 45 por ciento al 90 por ciento es más sospechoso aunque parezca tranquilo.

Capítulo 13: Qué hacer después de un incidente OOM

Una buena respuesta a incidentes es más que "reiniciar el servicio".

1. Restaurar el servicio de forma segura

Si se eliminó un proceso crítico, recupérelo de forma controlada.

2. Preservar la evidencia

Guarde los registros del kernel, registros de servicio, gráficos y marcas de tiempo relevantes antes de que la rotación de registros los elimine.

3. Identificar la fuente de crecimiento de la memoria.

Compara las horas previas al incidente, no sólo el último minuto.

4. Revisar los límites de configuración

Verifique los trabajadores de aplicaciones, los búferes de bases de datos, los montones de Java, los límites de los contenedores y configuraciones similares.

5. Revisar la actividad programada

Es posible que se hayan superpuesto las copias de seguridad, los análisis de malware, las importaciones, el procesamiento de registros y las tareas cron.

6. Decida si el problema es de configuración o de capacidad.

Si el tráfico legítimo normal requiere más memoria de la que tiene el servidor, el ajuste no puede fabricar RAM física.

Escale la instancia o rediseñe la carga de trabajo.

7. Pruebe la solución

No espere hasta la próxima interrupción real para saber si su cambio funcionó.

Utilice pruebas de carga controlada cuando corresponda.

Capítulo 14: Cuando agregar RAM es la respuesta correcta

Los ingenieros a veces se resisten a escalar porque quieren "optimizar primero".

La optimización es valiosa.

Pero no todos los problemas de capacidad son un error de software.

Si una base de datos en buen estado, el tráfico esperado, las herramientas de seguridad necesarias y los trabajadores de aplicaciones del tamaño adecuado realmente necesitan 12 GB de memoria de trabajo, ejecutarlos en un VPS de 4 GB no es eficiente. Es denegación con panel de control.

Agregue RAM cuando la carga de trabajo medida lo justifique.

Pase a un VPS más grande, un servidor dedicado o un diseño de nube cuando los requisitos operativos hayan superado la máquina actual.

El objetivo no es mantener vivo el servidor más pequeño a cualquier precio.

El objetivo es ejecutar el servicio de forma fiable.

Capítulo 15: Una lista práctica de verificación de la memoria

Antes de declarar que un VPS Linux está en buen estado, verifique:

• free -h muestra una cantidad razonable de memoria disponible durante la carga normal.
• El swap se configura según su carga de trabajo y el diseño del proveedor.
• La actividad de swap no es constantemente intensa.
• Los límites de los trabajadores de la aplicación se ajustan al presupuesto de RAM.
• La configuración de la memoria de la base de datos se ajusta al tamaño real de la máquina.
• Las copias de seguridad y los análisis se programan teniendo en cuenta la superposición de recursos.
• Ya sabes cómo encontrar mensajes OOM en el diario del kernel.
• Monitoreo de registros por proceso o tendencias por servicio.
• Las alertas se activan antes de que el servidor alcance un estado crítico.
• Existe una respuesta documentada ante la presión repetida de la memoria.
• La capacidad se revisa a medida que crece el tráfico.

Un servidor no debería necesitar suerte para permanecer en línea.