Debian 12 sur un VPS à faible RAM : Comment réduire les plantages liés à l’erreur de mémoire insuffisante (OOM) de MySQL

Vous pouvez réduire le risque d'arrêt de MySQL par le processus OOM killer sur un VPS Debian 12 disposant de peu de RAM en identifiant la cause du problème, en répartissant la mémoire entre tous les services, en limitant la concurrence des bases de données et en allouant de l'espace d'échange lorsque le VPS le permet. Un pool de mémoire tampon InnoDB plus petit ne constitue pas une solution complète. Ni l'espace d'échange ni la protection contre les erreurs OOM ne garantissent le bon fonctionnement d'une charge de travail excessive.

Ce guide a été rédigé le 9 octobre 2026 à l'aide de la documentation relative à Debian 12 « bookworm », Linux 6.1 et Oracle MySQL 8.0/8.4. Les paramètres ci-dessous sont des exemples de configurations de départ et ne constituent ni des résultats de tests de performance ni une configuration universelle. Il est recommandé de sauvegarder la base de données et sa configuration avant toute modification et de planifier les redémarrages de la base de données lorsque la durée d'indisponibilité est acceptable.

1. Identifiez le serveur avant de copier les paramètres MySQL

Vérifié : le paquet default-mysql-server de Debian 12 dépend de MariaDB. Un VPS décrit comme exécutant « MySQL » peut en réalité exécuter MariaDB, tandis qu’un autre peut utiliser Oracle MySQL depuis un dépôt ou un conteneur distinct.

mysql --version
systemctl status mysql mariadb

La première commande identifie le client, mais pas nécessairement le serveur en cours d'exécution. Connectez-vous avec votre compte d'administrateur de base de données et exécutez :

SELECT VERSION(), @@version_comment;

Utilisez votre méthode d'authentification actuelle ; les installations Debian MariaDB peuvent autoriser l'administration locale sudo mysql. Notez la version du serveur et le nom réel du service. Les commandes de service suivantes utiliserontmysql.service ; remplacez ` mariadb.service<nom_du_service>` le cas échéant. N'ajoutez pas de variables spécifiques à Oracle à la configuration de MariaDB.

2. Confirmer que l'arrêt était dû à une erreur de mémoire insuffisante (OOM).

Idée reçue courante : tout redémarrage inexpliqué d’une base de données est un arrêt par manque de mémoire. Les erreurs d’authentification, l’épuisement de l’espace disque, une configuration invalide, les plantages et les redémarrages par l’administrateur peuvent également interrompre le service.

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

Recherchez, aux alentours de l'heure de l'incident, les messages du noyau identifiant une erreur de mémoire insuffisante et le processus interrompu, puis corrélez ces messages avec le journal des services. Consultez également le journal des erreurs de la base de données si votre paquet l'écrit dans un fichier plutôt que dans le journal système. Si l'incident s'est produit avant un redémarrage, examinez le démarrage précédent journalctl -k -b -1lorsque les journaux d'erreurs sont disponibles. L'absence de journaux d'erreurs historiques ne permet pas de confirmer la cause de l'incident.

Un gestionnaire d'espace utilisateur peut également interrompre les processus. Le manuel de systemd-oomd pour Debian décrit une intervention en cas de forte sollicitation de la mémoire avant un événement OOM (Out Of Memory) du noyau. Vérifiez s'il est installé et actif plutôt que de supposer que tous les VPS Debian l'utilisent.

Examinez également les limites de systemd :

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

Sur un système cgroup v2, utilisez le chemin du ControlGroup indiqué pour lire les compteurs `<cgroup>` memory.events, memory.max`<cgroup>` et ` <cgroup> memory.swap.max` sous ` /sys/fs/cgroup<cgroup>`. Vérifiez également les cgroups parents. La documentation Linux cgroup v2 explique ces compteurs et limites. Un cgroup peut manquer de mémoire allouée même si l'hôte dispose de capacité suffisante. Un oom_killcompteur enregistre les interruptions, mais ces valeurs doivent être interprétées à l'aide des limites et des journaux pour en déterminer la cause.

3. Mesurez l'ensemble du VPS, et pas seulement le pool de mémoire tampon.

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

Collectez les observations lors du trafic normal et des tâches associées aux pannes. Dans free, concentrez-vous sur la mémoire disponible, et non pas seulement sur la colonne « libre ». Le manuel de Debian définit la mémoire disponible comme une estimation de la mémoire utilisable sans recours à la pagination. Les valeurs RSS dans la liste des processus sont exprimées en KiB ; leur addition peut entraîner un double comptage de la mémoire partagée.

Vérifié : MySQL alloue de la mémoire au-delà du pool de tampons d’InnoDB, notamment pour les connexions et les requêtes. La documentation de référence sur l’utilisation de la mémoire de MySQL détaille ces composants. Une formule basée sur les tampons configurés doit être considérée comme une estimation et non comme une limite supérieure précise.

Action : Réservez de la capacité pour le noyau, les processus web, la surveillance, les sauvegardes et les opérations temporaires sur la base de données. Le conseil habituel de consacrer la majeure partie de la RAM à InnoDB est inadapté, sans ajustement, sur un VPS partagé. Si des processus PHP ou une tâche de compilation consomment la mémoire disponible, optimisez ou déplacez cette charge de travail au lieu de réduire constamment la taille de MySQL.

4. Ajoutez la mémoire d'échange comme tampon, et non comme remplacement de la RAM.

L'utilisation de la mémoire d' échange dépend du contexte : elle peut absorber une partie de la charge mémoire anonyme temporaire, mais une utilisation prolongée peut ralentir considérablement les requêtes. Un VPS basé sur des conteneurs peut limiter l'utilisation de la mémoire d'échange, et un service MemorySwapMaxpeut en interdire l'utilisation même si l'hôte dispose de cette mémoire.

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

Si l'espace d'échange est absent, que votre fournisseur le permet et que vous disposez d'un espace disque suffisant, la commande suivante crée un fichier d'échange de 1 Gio sur un système de fichiers local approprié, tel que ext4. Ne l'exécutez pas si le répertoire /swapfile existe déjà. Consultez d'abord les exigences spécifiques à votre système de fichiers ; Btrfs nécessite une configuration de fichier d'échange sans copie à l'écriture.

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

Une fois l'activation réussie, ajoutez cette entrée une seule fois à /etc/fstab:

/swapfile none swap sw 0 0

Le manuel Debian swapon documente les limitations du fichier d'échange. Si l'activation est refusée par l'environnement VPS, renseignez-vous auprès de votre fournisseur sur la capacité d'échange prise en charge ou augmentez la mémoire de votre forfait ; n'insistez pas sur une configuration défaillante.

N’utilisez pas la modification « set swappiness to zero » comme protection contre les erreurs de mémoire insuffisante (OOM). La documentation de la machine virtuelle du noyau définit swappiness comme une préférence de coût de récupération. Elle ne crée pas de mémoire et n’impose aucune limite de mémoire à la base de données. Laissez-la inchangée dans un premier temps et observez le comportement.

5. Établir une base de données de référence modeste

À titre d'exemple, prenons un VPS de 1 Gio avec une charge de travail InnoDB réduite et quelques processus applicatifs. Les valeurs suivantes sont des pistes d'évaluation, et ne constituent en aucun cas une preuve que cette charge de travail est adaptée :

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

Placez les options du serveur dans un fichier de configuration inclus dans votre installation. Un paquet Oracle MySQL peut inclure ce fichier/etc/mysql/mysql.conf.d/ ; Debian MariaDB utilise généralement /etc/mysql/mariadb.conf.d/un autre fichier. Vérifiez les directives d'inclusion existantes et conservez-en une copie. La documentation de MySQL sur les fichiers d'options explique les groupes d'options du serveur et la gestion des fichiers.

Un pool de mémoire tampon de 128 Mio limite la taille du cache, et non la mémoire totale de la base de données. Une limite de 20 connexions peut s'avérer trop restrictive si plusieurs instances d'application gèrent chacune un pool. À l'inverse, 20 requêtes lourdes simultanées peuvent saturer le VPS. Veillez à ce que le nombre total de connexions dans le pool d'applications reste inférieur à la limite prévue du serveur, en prévoyant une marge pour l'accès administratif, et surveillez les connexions refusées.

Les variables communes mentionnées ci-dessus figurent également dans la documentation système de MariaDB , mais le comportement des tables temporaires diffère selon le produit et la version. Évitez d'augmenter la taille des tampons de tri, de jointure ou de lecture globaux pour améliorer les performances sur une machine aux ressources limitées.

6. Contrôler simultanément les tables temporaires et la concurrence

Idée reçue courante : ce paramètre tmp_table_size=16Mlimite la mémoire allouée aux requêtes à 16 Mio. Ce n’est pas le cas. Plusieurs sessions, plusieurs tables temporaires et d’autres allocations d’exécution peuvent coexister.

Pour Oracle MySQL 8.4 , voici un autre point de départ illustratif :

temptable_max_ram=64M
temptable_max_mmap=0

N'ajoutez ces paramètres au [mysqld]groupe existant qu'après avoir confirmé la compatibilité du produit. Ils régissent le seuil de RAM partagée du moteur TempTable et l'utilisation des fichiers temporaires mappés en mémoire. Ils ne limitent pas l'ensemble du processus mysqld ni toutes les allocations locales aux threads. Des seuils plus bas peuvent permettre de transférer davantage de données vers le disque.

La documentation relative aux tables temporaires de MySQL 8.4 explique ces limites. Le comportement de MySQL 8.0 dépend de la version : cette limitation temptable_max_mmapest apparue dans la version 8.0.23 et tmp_table_sizeest devenue une limite individuelle pour les tables temporaires dans la version 8.0.28. Consultez la documentation de référence de MySQL 8.0 avant d'appliquer les mêmes paramètres. Ne copiez pas ces options spécifiques à Oracle vers MariaDB.

Action : Limitez le chevauchement des requêtes de rapports, des processus en arrière-plan et des tâches de sauvegarde ou d’importation. Examinez les plans de requêtes et les index lorsqu’une opération particulière génère une forte charge. Déplacer les tâches volumineuses en dehors des périodes de pointe peut s’avérer utile ; si la demande simultanée normale dépasse toujours la capacité, l’ajout de RAM ou la séparation de la base de données constituent la prochaine étape appropriée.

7. Validez les modifications et redémarrez délibérément

Pour les versions d'Oracle MySQL prenant en charge cette option, vérifiez la configuration avant de redémarrer :

sudo mysqld --validate-config

Utilisez le même chemin d'accès au fichier de configuration par défaut et les mêmes arguments de démarrage que le service s'il n'utilise pas la découverte de configuration par défaut. La documentation de validation MySQL précise que la validation n'initialise pas tous les sous-systèmes. Sa réussite ne constitue pas un test de capacité de charge. Ne présumez pas que MariaDB prenne en charge cette option Oracle.

Redémarrez le service pendant la période prévue, puis inspectez le démarrage et interrogez les valeurs effectives :

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

Les variables non prises en charge n'apparaîtront pas dans les résultats. Vérifiez les paramètres prévus au lieu de supposer que le nouveau fichier est prioritaire. Si le démarrage échoue suite à votre modification, restaurez la configuration enregistrée ou supprimez uniquement la nouvelle modification, puis redémarrez. Conservez les détails de l'erreur pour le diagnostic.

8. Définir le succès sous une charge représentative

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

Comparez le trafic et les tâches planifiées avant et après les modifications. Suivez les nouveaux événements OOM (mémoire insuffisante), les redémarrages de la base de données, la mémoire disponible, les refus de connexion, l'activité du swap et la latence des requêtes. Dans Debian vmstat, les opérations d'échange mémoire (swap-in/swap-out) soutenues méritent d'être étudiées. Le manuel vmstat de Debian explique que le premier rapport correspond à une moyenne de l'activité depuis le démarrage ; utilisez les rapports suivants pour connaître les taux actuels.

La documentation PSI du noyau décrit les mesures de blocage de la pression. Un temps de blocage mémoire accru peut révéler un problème avant même une nouvelle interruption. Le fait qu'un système inactif survive dix minutes ne garantit pas que la prochaine sauvegarde ou le prochain pic de trafic sera sans risque.

Des idées fausses qui peuvent aggraver le problème

Le manuel de gestion des ressources systemd de Debian explique comment MemoryMaxdéclencher la gestion des erreurs de mémoire insuffisante (OOM) au sein d'une unité. Il est déconseillé de supprimer les limites du fournisseur ou du conteneur sans autorisation. L'application doit disposer d'une mémoire adaptée à ces limites, ou ces dernières doivent faire l'objet d'une modification de capacité autorisée.

Il n'existe aucune taille minimale de VPS vérifiée garantissant le bon fonctionnement de cette charge de travail. Si un débit utile nécessite un échange constant de données, si les tâches planifiées provoquent toujours des interruptions, ou si des caches trop petits rendent la latence inacceptable, cessez de considérer la configuration comme un substitut à la capacité. Augmentez la RAM, réduisez la concurrence des applications ou déplacez la base de données vers un service distinct.