Debian 12 en un VPS con poca RAM: Cómo reducir los fallos por falta de memoria de MySQL

Puedes reducir el riesgo de que el mecanismo de eliminación de memoria por falta de memoria (OOM killer) detenga MySQL en un VPS Debian 12 con poca RAM confirmando la causa, distribuyendo la memoria entre todos los servicios, limitando la concurrencia de la base de datos y proporcionando memoria de intercambio (swap) cuando el VPS lo permita. Reducir el tamaño del grupo de búferes de InnoDB por sí solo no soluciona el problema por completo. Ni la memoria de intercambio ni la configuración de protección contra errores de memoria por falta de memoria garantizan que una carga de trabajo excesiva siga ejecutándose.

Esta guía se elaboró ​​el 9 de octubre de 2026, utilizando Debian 12 “bookworm”, Linux 6.1 y la documentación de Oracle MySQL 8.0/8.4. La configuración que se muestra a continuación es solo un ejemplo, no resultados de pruebas de rendimiento ni una configuración universal. Realice copias de seguridad de la base de datos y la configuración antes de realizar cualquier cambio, y programe reinicios de la base de datos cuando el tiempo de inactividad sea aceptable.

1. Identifique el servidor antes de copiar la configuración de MySQL.

Verificado: El paquete default-mysql-server de Debian 12 depende de MariaDB. Un VPS descrito como que ejecuta "MySQL" puede que en realidad ejecute MariaDB, mientras que otro puede tener Oracle MySQL desde un repositorio o contenedor independiente.

mysql --version
systemctl status mysql mariadb

El primer comando identifica al cliente, no necesariamente al servidor en ejecución. Conéctese usando su cuenta de administrador de base de datos y ejecute:

SELECT VERSION(), @@version_comment;

Utilice su método de autenticación existente; las instalaciones de Debian MariaDB pueden permitir la administración local con sudo mysql. Anote la versión del servidor y el nombre real del servicio. Los comandos de servicio subsiguientes utilizan mysql.service; sustituya mariadb.servicecuando corresponda. No añada variables exclusivas de Oracle a la configuración de MariaDB.

2. Confirme que el apagado fue un evento OOM.

Error común: Se cree erróneamente que cualquier reinicio inexplicable de la base de datos se debe a un error de memoria insuficiente (OOM). Los errores de autenticación, el agotamiento del disco, la configuración no válida, los fallos del sistema y los reinicios del administrador también pueden interrumpir el servicio.

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

Busque mensajes del kernel que indiquen una condición de falta de memoria y el proceso finalizado en el momento del incidente, y luego correlacione esos mensajes con el registro de servicio. Inspeccione también el registro de errores de la base de datos si su paquete lo escribe en un archivo en lugar del registro de transacciones. Si el incidente ocurrió antes de un reinicio, inspeccione el arranque anterior journalctl -k -b -1cuando haya registros retenidos disponibles. La falta de registros históricos impide confirmar la causa.

Un gestor de espacio de usuario también puede finalizar cargas de trabajo. El manual de systemd-oomd de Debian describe la intervención basada en la presión de memoria antes de un evento OOM del kernel. Compruebe si está instalado y activo en lugar de asumir que todos los VPS Debian lo utilizan.

Inspeccione también los límites de systemd:

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

En un sistema cgroup v2, utilice la ruta ControlGroup informada para leer memory.events, memory.max, y memory.swap.maxen /sys/fs/cgroup. Compruebe también los cgroups principales. La documentación de Linux cgroup v2 explica estos contadores y límites. Un cgroup puede quedarse sin su memoria permitida incluso cuando el host tiene capacidad. Un oom_killcontador registra los kills, pero debe interpretarse con límites y registros para establecer la causa.

3. Mida todo el VPS, no solo el grupo de búferes.

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

Recopile observaciones durante el tráfico normal y las tareas asociadas con fallos. En free, concéntrese en la memoria disponible, no solo en la columna libre. El manual libre de Debian describe la memoria disponible como una estimación de lo que se puede usar sin intercambio. Los valores RSS en el listado de procesos están en KiB; sumarlos puede duplicar el conteo de la memoria compartida.

Verificado: MySQL asigna memoria más allá del grupo de búferes de InnoDB, incluyendo asignaciones relacionadas con conexiones y consultas. La documentación de referencia sobre el uso de memoria de MySQL describe estos componentes. Considere una fórmula basada en búferes configurados como una estimación, no como un límite superior preciso.

Acción: Reserve capacidad para el kernel, los procesos web, la monitorización, las copias de seguridad y las operaciones transitorias de la base de datos. La recomendación habitual de dedicar la mayor parte de la RAM a InnoDB no es viable sin ajustes en un VPS compartido. Si los procesos PHP o una tarea de compilación consumen la capacidad disponible, optimice o mueva esa carga de trabajo en lugar de reducir repetidamente MySQL.

4. Añadir la memoria de intercambio como búfer, no como RAM de reemplazo.

Depende del contexto: el intercambio de memoria puede absorber cierta presión temporal de memoria anónima, pero el intercambio sostenido puede ralentizar demasiado las consultas. Un VPS basado en contenedores puede restringir el intercambio de memoria, y un servicio MemorySwapMaxpuede impedir su uso incluso cuando el host dispone de él.

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

Si no hay espacio de intercambio, el proveedor lo permite y dispone de suficiente espacio en disco, el siguiente comando crea un archivo de intercambio de 1 GiB en un sistema de archivos local adecuado, como ext4. No lo ejecute si el archivo /swapfile ya existe. Revise primero los requisitos específicos del sistema de archivos; Btrfs necesita una configuración de archivo de intercambio sin copia en escritura.

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Solo después de que la activación sea exitosa, agregue esta entrada una sola vez a /etc/fstab:

/swapfile none swap sw 0 0

El manual de swapon de Debian documenta las limitaciones del archivo de intercambio. Si el entorno VPS deniega la activación, consulte con el proveedor sobre el intercambio compatible o aumente la memoria del plan; no persista una configuración fallida.

No copie la modificación "set swappiness to zero" como protección contra errores de memoria insuficiente (OOM). La documentación de la máquina virtual del kernel define swappiness como una preferencia de costo de recuperación. No crea memoria ni impone un límite de memoria a la base de datos. Déjelo sin cambios inicialmente y observe su comportamiento.

5. Establezca una base de datos modesta.

A modo de ejemplo, consideremos un VPS de 1 GiB con una pequeña carga de trabajo InnoDB y algunos procesos de aplicación. Los siguientes valores son candidatos para evaluar, pero no constituyen una prueba de que esta carga de trabajo sea adecuada:

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

Coloque las opciones del servidor en un archivo de configuración incluido en su instalación. Un paquete de Oracle MySQL puede incluir /etc/mysql/mysql.conf.d/; Debian MariaDB suele usar /etc/mysql/mariadb.conf.d/. Verifique las directivas include existentes y guarde una copia de seguridad. La documentación de MySQL sobre archivos de opciones explica los grupos de opciones del servidor y el manejo de archivos.

Un grupo de búferes de 128 MiB limita la caché, no la memoria total de la base de datos. Un límite de 20 conexiones puede ser demasiado restrictivo si varias instancias de la aplicación mantienen un grupo cada una. Por otro lado, 20 consultas pesadas concurrentes aún podrían sobrecargar el VPS. Mantenga el número total de conexiones del grupo de aplicaciones por debajo del límite previsto del servidor, con espacio para el acceso administrativo, y observe si se rechazan las conexiones.

Las variables comunes mencionadas anteriormente también aparecen en la referencia de variables del sistema de MariaDB , pero el comportamiento de las tablas temporales difiere según el producto y la versión. Evite aumentar los búferes globales de ordenación, unión o lectura como solución genérica para mejorar el rendimiento en una máquina con recursos limitados.

6. Controlar las tablas temporales y la concurrencia de forma conjunta.

Error común: Se cree que la configuración tmp_table_size=16Mlimita la memoria de consulta a 16 MiB. Esto no es cierto. Varias sesiones, varias tablas temporales y otras asignaciones de ejecución pueden coexistir.

Para Oracle MySQL 8.4 , un punto de partida ilustrativo adicional es:

temptable_max_ram=64M
temptable_max_mmap=0

Agregue estos parámetros al [mysqld]grupo existente solo después de confirmar la compatibilidad del producto. Controlan el umbral de RAM compartida del motor TempTable y el uso de archivos temporales mapeados en memoria. No limitan todo el proceso mysqld ni todas las asignaciones locales de subprocesos. Umbrales más bajos pueden generar más trabajo en disco.

La documentación de tablas temporales de MySQL 8.4 explica estos límites. MySQL 8.0 presenta un comportamiento dependiente de la versión: temptable_max_mmapse introdujo en la versión 8.0.23 y tmp_table_sizese convirtió en un límite individual para las tablas temporales en la versión 8.0.28. Consulte la documentación de referencia de MySQL 8.0 antes de aplicar la misma configuración. No copie estas opciones específicas de Oracle a MariaDB.

Acción: Limite las consultas de informes superpuestas, los procesos en segundo plano y las tareas de copia de seguridad o importación. Revise los planes de consulta y los índices cuando una operación específica genere sobrecarga. Mover las tareas de gran tamaño fuera de los picos de tráfico puede ser útil; si la demanda concurrente normal aún supera la capacidad, la siguiente medida apropiada es aumentar la memoria RAM o separar la base de datos.

7. Validar los cambios y reiniciar deliberadamente

Para las versiones de Oracle MySQL que admiten esta opción, compruebe la configuración antes de reiniciar:

sudo mysqld --validate-config

Utilice la misma ruta de archivo de configuración predeterminada y los mismos argumentos de inicio que el servicio si este no utiliza la detección de configuración predeterminada. La documentación de referencia de validación de MySQL indica que la validación no inicializa todos los subsistemas. Superarla no constituye una prueba de capacidad de carga de trabajo. No asuma que MariaDB admite esta opción de Oracle.

Reinicie el servicio durante el período previsto, luego inspeccione el inicio y consulte los valores efectivos:

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

Las variables no compatibles no aparecerán en los resultados. Verifique la configuración prevista en lugar de asumir que el nuevo archivo tiene prioridad. Si el inicio falla debido al cambio, restaure la configuración guardada o elimine solo la nueva modificación y reinicie. Conserve los detalles del error para su posterior diagnóstico.

8. Defina el éxito bajo una carga representativa.

free -h
vmstat 1
cat /proc/pressure/memory

Compara el mismo tráfico y las tareas programadas antes y después de los cambios. Realiza un seguimiento de los nuevos eventos OOM, los reinicios de la base de datos, la memoria disponible, los rechazos de conexión, la actividad de intercambio y la latencia de las consultas. En vmstat, el intercambio sostenido de entrada/salida merece ser investigado. El manual de vmstat de Debian explica que el primer informe promedia la actividad desde el arranque; utiliza los informes posteriores para conocer las tasas actuales.

La referencia PSI del kernel describe las mediciones de bloqueo por presión. Un tiempo de bloqueo de memoria cada vez mayor puede revelar problemas incluso antes de que se produzca otro fallo. Que un sistema inactivo sobreviva diez minutos no garantiza que la siguiente copia de seguridad o ráfaga de tráfico sea segura.

Ideas erróneas que pueden empeorar el problema

El manual de control de recursos de systemd de Debian explica que MemoryMaxse puede invocar el manejo de errores de memoria insuficiente (OOM) dentro de una unidad. No elimine los límites del proveedor o del contenedor indiscriminadamente. La aplicación necesita un presupuesto de memoria que se ajuste a esos límites, o bien, los límites requieren un cambio de capacidad autorizado.

No existe un tamaño mínimo de VPS verificado que garantice la ejecución de esta carga de trabajo en particular. Si el rendimiento útil requiere intercambio continuo de memoria, si las tareas programadas siguen provocando interrupciones o si las cachés más pequeñas generan una latencia inaceptable, deje de considerar la configuración como un sustituto de la capacidad. Actualice la RAM, reduzca la concurrencia de la aplicación o traslade la base de datos a un servicio independiente.