Ejecutar Debian 12 en un VPS con poca RAM sin fallos por falta de memoria que provoquen la caída de MySQL.

Un VPS con poca memoria puede ejecutar Debian 12 y una base de datos, pero la estabilidad depende de la carga de trabajo completa, no solo de la caché configurada de MySQL. Cuando se agota la memoria disponible, Linux puede activar el mecanismo de eliminación de procesos por falta de memoria (OOM killer), que finaliza un proceso para proteger el resto del sistema. Si ese proceso es la base de datos, el síntoma puede parecer un fallo aleatorio. El objetivo práctico es evitar una presión de memoria sostenida y confirmar qué proceso finalizó realmente el kernel; ninguna configuración de optimización puede garantizar que nunca se produzcan errores de memoria por falta de memoria.

¿Debian 12 utiliza MySQL o MariaDB?

Verifique el servidor antes de cambiar su configuración. Debian 12 (Bookworm) utiliza MariaDB como default-mysql-serverpaquete predeterminado; Oracle MySQL se instala por separado. La información del paquete de Debian indica que MariaDB es la dependencia del servidor de ese metapackage. Ejecute:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

Utilice las instrucciones de MariaDB que se indican a continuación solo si el servicio instalado es MariaDB. Oracle MySQL utiliza nombres de opciones que parecen compatibles en muchos casos, pero la estructura de los paquetes, los nombres de los servicios, las variables disponibles y los valores predeterminados pueden diferir. Consulte el manual para conocer la versión exacta de MySQL instalada.

Referencias principales: el paquete default-mysql-server de Debian Bookworm y el manual de uso de memoria de MySQL 8.0 .

¿Cómo se puede saber si un error de memoria insuficiente (OOM) provocó la destrucción de la base de datos?

Primero, distinga un error de memoria insuficiente (OOM kill) del kernel de un error de base de datos, un reinicio del servicio, un reinicio del sistema o un problema de disco. En Debian, journalctllea el registro de systemd. Busque en el arranque actual e inspeccione el registro del servicio de MariaDB:

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

Si el registro del kernel contiene mariadbdun mysqldmensaje de OOM, hay evidencia de un fallo de memoria. Si no hay ninguna entrada coincidente, revise el registro de errores del servicio y el historial de reinicios o monitorización del proveedor. Es posible que los registros no estén disponibles después de un reinicio si el registro de transacciones no es persistente, y un proveedor de VPS gestionado puede mostrar solo una parte de los diagnósticos del host.

Capture una línea base mientras el servidor esté bajo un tráfico representativo, no solo cuando esté inactivo:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

En vmstat, observe las columnas siy sopara detectar actividad sostenida de intercambio de entrada y salida. Una asignación de intercambio distinta de cero por sí sola no demuestra un problema; el intercambio continuo junto con tiempos de respuesta lentos indica presión de memoria. Linux documenta el manejo de OOM como una respuesta de último recurso cuando la memoria no se puede recuperar suficientemente. Consulte los conceptos de administración de memoria del kernel de Linux y el manual journalctl de Debian .

¿Qué debes medir antes de afinar?

Registra la RAM total, el uso actual y máximo de la memoria de intercambio, los procesos residentes más grandes, las conexiones a la base de datos y el pico normal de la aplicación web. La base de datos comparte memoria con Debian, el servidor web, los procesos de la aplicación, los agentes de monitorización y la caché del sistema de archivos. Un VPS también puede tener un límite de memoria para contenedores o cgroups inferior a la RAM física del host; ajusta el tamaño de las cachés de la base de datos al límite de memoria visible para el servicio, no a un total mayor del host.

Para MariaDB, inspeccione la configuración actual relacionada con la memoria y el pico de conexión:

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

El grupo de búferes de InnoDB almacena en caché las páginas de tablas e índices. Los límites de conexión y los búferes de consulta pueden aumentar la demanda de memoria a medida que aumenta el trabajo concurrente. Evite multiplicar cada búfer por conexión max_connectionscomo si cada búfer estuviera siempre completamente asignado, pero considere un límite de conexión muy alto como un riesgo en picos de tráfico. La guía de memoria de MariaDB recomienda dimensionar las cachés globales, los búferes por conexión y la configuración del motor en conjunto, y menciona específicamente los grupos de conexiones de la aplicación. Lea la guía de asignación de memoria de MariaDB y su guía para manejar demasiadas conexiones .

¿Cómo se dimensiona correctamente MariaDB en un VPS pequeño?

Realice un cambio a la vez, guarde una copia de la configuración original y pruebe durante una ventana de mantenimiento si un reinicio afectaría a los usuarios. La configuración de MariaDB empaquetada en Debian suele incluir archivos en /etc/mysql/mariadb.conf.d/; verifique los directorios de inclusión activos en su instalación antes de editar. Es más fácil eliminar un archivo pequeño que reemplazar el archivo principal del proveedor:

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

Para un VPS compartido con aproximadamente 1 GiB de RAM, el siguiente es solo un ejemplo inicial prudente, no un perfil seguro universal. Ajuste los valores según el consumo máximo de memoria, el tamaño de la base de datos, la carga de trabajo y la RAM disponible para el sistema operativo y la aplicación.

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB lee la configuración de los archivos de opciones al iniciarse; verifique los nombres de las secciones compatibles con su versión y los valores efectivos. Si este archivo no se carga, elimine el archivo de configuración adicional y revise el registro. Reiniciar la base de datos interrumpe las conexiones existentes, así que prográmelo adecuadamente.

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

Evalúe el resultado en función de la estabilidad y la calidad del servicio. Un grupo de búferes más pequeño puede reducir los aciertos de caché y aumentar las lecturas de disco. Reducirlo max_connectionsdemasiado puede generar errores de "Demasiadas conexiones". Compare Max_used_connectionscon el límite configurado y revise el tamaño del grupo de aplicaciones antes de volver a modificarlo. Si la base de datos sigue fallando durante el tráfico máximo habitual o el tiempo de respuesta se degrada debido al intercambio continuo de disco, aumente la capacidad de la memoria RAM o separe la base de datos de la aplicación.

¿Puede la función de intercambio evitar un fallo por falta de memoria?

El archivo de intercambio (swap) proporciona a Linux un espacio más lento para mover algunas páginas de memoria y puede absorber picos de carga breves. No añade RAM rápida, no corrige fugas de memoria ni adapta un VPS insuficiente para una carga de trabajo sostenida. Un uso intensivo del archivo de intercambio puede provocar que tanto la base de datos como la aplicación dejen de responder. Antes de crear uno, compruebe si su proveedor admite archivos de intercambio y si el VPS dispone de suficiente espacio en disco.

Si es compatible, se puede crear un archivo de intercambio de 1 GiB de la siguiente manera. Ajuste el tamaño según las indicaciones del proveedor y el espacio en disco disponible, y verifique el resultado de cada comando:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Para habilitarlo después de reiniciar, agregue esta entrada /etc/fstabdespués de verificar que no exista ya una entrada equivalente:

/swapfile none swap sw 0 0

Luego valide el archivo sudo findmnt --verify --verbosey confirme que aparece en swapon --show. Si fallocateno es compatible con el sistema de archivos o el proveedor bloquea el intercambio, deténgase y utilice el procedimiento compatible del proveedor. No desactive el OOM killer ni asigne una puntuación de protección OOM extrema a MySQL: esto no crea memoria y puede dejar el resto de un VPS pequeño en mayor riesgo.

¿Cómo sabes que los cambios funcionaron?

Observe el VPS durante al menos un período de actividad normal. Un resultado útil presenta varias características:

• No se registraron nuevas entradas OOM-kill del kernel durante la carga de trabajo que previamente desencadenó el incidente.
• MariaDB permanece activo y su contador de reinicios no aumenta inesperadamente.
• vmstat 1No muestra intercambio continuo de entrada y salida bajo tráfico normal.
• La aplicación sigue respondiendo correctamente y los picos de conexión a la base de datos se mantienen por debajo del nuevo límite sin errores de conexión.
• Las copias de seguridad se han completado y las consultas a la base de datos siguen cumpliendo con la latencia aceptable de la aplicación.

No utilice el hecho de que el servicio se inicie como única prueba de éxito. Una configuración que mantiene MariaDB activo, pero que fuerza al sistema a usar constantemente el intercambio de memoria, no ha resuelto el problema de capacidad subyacente. Del mismo modo, un día tranquilo no valida una importación mensual, una copia de seguridad, un pico de tráfico o un trabajo por lotes que aún no se haya ejecutado.

¿Cuándo deja de ser la solución adecuada el simple ajuste?

Elija un VPS más grande o separe las cargas de trabajo cuando la memoria siga bajo presión después de realizar ajustes razonables de caché y concurrencia, la actividad de intercambio sea constante, la latencia de las consultas sea inaceptable o la aplicación alcance repetidamente el nuevo límite de conexiones. El tamaño de la base de datos también importa: un grupo de búferes demasiado pequeño puede evitar un pico de memoria, pero convertir la E/S del disco en el nuevo cuello de botella. Si la aplicación y la base de datos presentan picos pronunciados pero predecibles, primero determine si la aplicación está abriendo conexiones excesivas o ejecutando tareas que consumen mucha memoria simultáneamente.

En Oracle MySQL, en lugar de MariaDB (el servidor predeterminado de Debian), verifique el nombre del servicio, la ruta del archivo de opciones y las variables de memoria con el manual de versiones del servidor antes de aplicar estos ejemplos. En ambos motores, conserve copias de seguridad probadas y modifique una variable a la vez. El resultado fiable no garantiza que Linux nunca genere errores de memoria insuficiente (OOM); simplemente demuestra que el VPS tiene suficiente capacidad para su carga de trabajo máxima real y que MySQL o MariaDB ya no son la causa recurrente de estos errores.

Referencias primarias adicionales: la guía de solución de problemas de inicio de MariaDB , que señala que el servidor también necesita memoria para otros motores, búferes por conexión y el sistema operativo, y el Manual de referencia de MySQL 8.0 .