Exécuter Debian 12 sur un VPS à faible RAM sans plantages dus à une surcharge de mémoire (OOM) et sans interruption de MySQL

Un VPS à faible capacité de mémoire peut faire tourner Debian 12 et une base de données, mais sa stabilité dépend de l'ensemble de la charge de travail, et pas seulement du cache configuré de MySQL. Lorsque la mémoire disponible est saturée, Linux peut déclencher le processus de gestion de la mémoire insuffisante (OOM killer), qui interrompt un processus pour protéger le reste du système. Si ce processus est la base de données, cela peut se traduire par un plantage aléatoire. L'objectif pratique est d'éviter une saturation de la mémoire et de vérifier quel processus a été interrompu par le noyau ; aucun paramètre de configuration ne peut garantir l'absence totale d'incidents de type OOM.

Debian 12 utilise-t-il MySQL ou MariaDB ?

Vérifiez le serveur avant de modifier sa configuration. Debian 12 (Bookworm) utilise MariaDB comme default-mysql-serverpaquet par défaut ; Oracle MySQL est installé séparément. Les informations du paquet Debian indiquent que MariaDB est une dépendance serveur de ce métapaquet. Exécutez :

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

Utilisez les instructions MariaDB ci-dessous uniquement si le service installé est MariaDB. Oracle MySQL utilise souvent des noms d'options similaires, mais l'organisation des packages, les noms de services, les variables disponibles et les valeurs par défaut peuvent différer. Consultez le manuel pour connaître la version exacte de MySQL installée.

Références principales : le paquet default-mysql-server de Debian Bookworm et le manuel d’utilisation de la mémoire de MySQL 8.0 .

Comment savoir si une erreur de mémoire insuffisante (OOM) a provoqué l'arrêt de la base de données ?

Commencez par distinguer une erreur de mémoire insuffisante du noyau d'une erreur de base de données, d'un redémarrage de service, d'un redémarrage système ou d'un problème de disque. Sous Debian, journalctlconsultez le journal de systemd. Recherchez dans le journal de démarrage actuel et examinez le journal du service 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 le journal du noyau mentionne mariadbdun mysqldmessage d'erreur de mémoire insuffisante (OOM) après celui-ci, cela indique une occurrence de « mémoire brûlée ». En l'absence d'entrée correspondante, consultez le journal d'erreurs du service ainsi que l'historique de redémarrage ou de surveillance de votre fournisseur. Les journaux peuvent être indisponibles après un redémarrage si la journalisation n'est pas persistante, et un fournisseur de VPS géré peut n'exposer qu'une partie des diagnostics de l'hôte.

Établissez une valeur de référence lorsque le serveur est soumis à un trafic représentatif, et pas seulement lorsqu'il est inactif :

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

Dans ` journalctl` vmstat, surveillez les sicolonnes so`swap-in` et `swap-out` pour détecter une activité soutenue d'échange de mémoire. Une allocation d'espace d'échange non nulle en soi n'indique pas de problème ; un échange continu associé à des temps de réponse lents signale une saturation de la mémoire. Linux décrit la gestion de la mémoire insuffisante (OOM) comme une solution de dernier recours lorsque la mémoire ne peut être récupérée en quantité suffisante. Consultez la documentation sur la gestion de la mémoire du noyau Linux et le manuel de `journalctl` de Debian .

Que faut-il mesurer avant le réglage ?

Enregistrez la RAM totale, l'utilisation actuelle et maximale du swap, les processus résidents les plus gourmands en ressources, les connexions à la base de données et le pic d'utilisation habituel de l'application web. La base de données partage la mémoire avec Debian, le serveur web, les processus de l'application, les agents de surveillance et le cache du système de fichiers. Un VPS peut également avoir une limite de mémoire pour un conteneur ou un cgroup inférieure à la RAM physique de l'hôte ; dimensionnez les caches de la base de données en fonction de la limite de mémoire visible par le service, et non d'une limite supérieure pour l'hôte.

Pour MariaDB, examinez les paramètres actuels liés à la mémoire et le pic de connexion :

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';"

Le pool de mémoire tampon InnoDB met en cache les pages de tables et d'index. Les limites de connexions et les tampons de requêtes peuvent augmenter la demande en mémoire lorsque le volume de requêtes simultanées augmente. Évitez de multiplier chaque tampon par connexion max_connectionscomme s'il était toujours entièrement alloué, mais considérez un plafond de connexions très élevé comme un risque en cas de pics de charge. Le guide de gestion de la mémoire de MariaDB recommande de dimensionner conjointement les caches globaux, les tampons par connexion et les paramètres du moteur, et mentionne spécifiquement les pools de connexions applicatifs. Consultez le guide d'allocation de mémoire de MariaDB et son guide sur la gestion d'un trop grand nombre de connexions .

Comment dimensionner correctement MariaDB sur un petit VPS ?

Effectuez une modification à la fois, conservez une copie de la configuration d'origine et testez, lors d'une fenêtre de maintenance, si un redémarrage impacte les utilisateurs. La configuration MariaDB fournie par Debian inclut généralement des fichiers dans le répertoire `/etc/mariaDB`/etc/mysql/mariadb.conf.d/ ; vérifiez les répertoires d'inclusion actifs sur votre installation avant toute modification. Il est plus facile de supprimer un petit fichier de configuration que de remplacer le fichier principal du fournisseur.

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

Pour un VPS partagé avec environ 1 Gio de RAM, l'exemple suivant est une recommandation initiale prudente et non un profil sûr universel. Ajustez les valeurs en fonction de la consommation mémoire maximale mesurée, de la taille de la base de données, de la charge de travail et de la RAM disponible pour le système d'exploitation et les applications.

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

MariaDB lit les paramètres depuis des fichiers d'options au démarrage ; vérifiez les noms de sections et les valeurs effectives pris en charge par votre version. Si ce fichier ne se charge pas, supprimez le fichier d'extension et consultez le journal. Le redémarrage de la base de données interrompt les connexions existantes ; planifiez-le donc en conséquence.

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;"

Évaluez le résultat en fonction de la stabilité et de la qualité du service. Un pool de mémoire tampon plus petit peut réduire les accès au cache et augmenter les lectures disque. À l'inverse, une réduction max_connectionsexcessive peut entraîner des erreurs de type « Trop de connexions ». Comparez Max_used_connectionsavec la limite configurée et examinez la taille du pool d'applications avant de modifier à nouveau cette limite. Si la base de données est toujours interrompue lors des pics de trafic normaux, ou si le temps de réponse se dégrade en raison d'une activité d'échange disque soutenue, passez à une couche de RAM plus importante ou séparez la base de données de l'application.

La commutation peut-elle empêcher un plantage dû à une erreur de mémoire insuffisante (OOM) ?

L'espace d'échange (swap) offre à Linux un espace de stockage plus lent pour certaines pages mémoire et peut absorber un pic de charge passager. Il n'ajoute pas de RAM rapide, ne corrige pas les fuites de mémoire et ne permet pas à un VPS sous-dimensionné de supporter une charge de travail soutenue. Un usage excessif de l'espace d'échange peut rendre la base de données et les applications non réactives. Avant de créer un fichier d'échange, vérifiez si votre fournisseur prend en charge ce type de fichiers et si votre VPS dispose de suffisamment d'espace disque.

Si votre système le permet, un fichier d'échange de 1 Gio peut être créé comme suit. Adaptez la taille aux recommandations de votre fournisseur et à l'espace disque disponible, puis vérifiez le résultat de chaque commande :

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

Pour l'activer après le redémarrage, ajoutez cette entrée /etc/fstabaprès avoir vérifié qu'une entrée équivalente n'est pas déjà présente :

/swapfile none swap sw 0 0

Validez ensuite le fichier sudo findmnt --verify --verboseet vérifiez sa présence swapon --show. Si fallocatele système de fichiers ne le prend pas en charge ou si le fournisseur bloque l'espace d'échange, arrêtez le processus et utilisez la procédure recommandée par le fournisseur. Ne désactivez pas le processus OOM killer et n'attribuez pas un score de protection OOM extrême à MySQL : cela ne libère pas de mémoire et peut exposer le reste d'un petit VPS à des risques accrus.

Comment savez-vous que les changements ont fonctionné ?

Surveillez le VPS pendant au moins une période de forte activité normale. Un résultat utile présente plusieurs signes :

• Aucune nouvelle entrée OOM-kill du noyau pendant la charge de travail qui avait précédemment déclenché l'incident.
• MariaDB reste actif et son nombre de redémarrages n'augmente pas de manière inattendue.
• vmstat 1ne présente pas d'échange continu en conditions de trafic normal.
• L'application reste réactive et les pics de connexion à la base de données restent inférieurs au nouveau seuil sans erreurs de connexion.
• Les sauvegardes sont terminées et les requêtes de base de données continuent de respecter la latence acceptable de l'application.

Ne vous fiez pas uniquement au démarrage du service pour évaluer sa réussite. Une configuration qui maintient MariaDB en fonctionnement mais qui provoque un échange constant de données ne résout pas le problème de capacité sous-jacent. De même, une journée sans activité ne suffit pas à valider une importation mensuelle, une sauvegarde, un pic de trafic ou un traitement par lots non encore exécuté.

Quand le réglage n'est-il plus la solution adéquate ?

Choisissez un VPS plus puissant ou répartissez les charges de travail si la mémoire reste saturée malgré des ajustements raisonnables du cache et de la concurrence, si l'activité du swap est soutenue, si la latence des requêtes devient inacceptable ou si l'application atteint régulièrement la nouvelle limite de connexions. La taille de la base de données est également importante : un pool de mémoire tampon trop petit peut éviter un pic de mémoire tout en transformant les E/S disque en goulot d'étranglement. Si l'application et la base de données présentent des pics d'activité importants mais prévisibles, commencez par déterminer si l'application ouvre un nombre excessif de connexions ou exécute simultanément des tâches gourmandes en mémoire.

Sur Oracle MySQL plutôt que sur MariaDB (la base de données par défaut de Debian), vérifiez le nom du service, le chemin du fichier d'options et les variables de mémoire dans le manuel de votre serveur avant d'appliquer ces exemples. Quel que soit le système, conservez des sauvegardes testées et modifiez une variable à la fois. Un résultat fiable ne garantit pas que Linux n'aura jamais recours à la gestion de la mémoire insuffisante (OOM) ; il indique simplement que le VPS dispose d'une marge suffisante pour sa charge de travail maximale réelle et que MySQL ou MariaDB n'est plus la source récurrente des problèmes.

Références principales supplémentaires : le guide de dépannage au démarrage de MariaDB , qui indique que le serveur a également besoin de mémoire pour d’autres moteurs, des tampons par connexion et le système d’exploitation, ainsi que le manuel de référence de MySQL 8.0 .