Comprendre et gérer l'OOM killer Linux sur un serveur VPS

Votre serveur Minecraft redémarre sans raison apparente. Le processus FiveM disparaît en pleine nuit. Un daemon MySQL tombe pendant une sauvegarde. Dans les trois cas, le coupable probable est le même : le OOM killer de Linux, qui tue des processus quand le système épuise toute sa mémoire RAM et son swap.

Ce guide explique comment fonctionne ce mécanisme du noyau Linux, comment identifier un kill dans les logs, et comment protéger les processus critiques d'un VPS Ubuntu, Debian, CentOS ou d'un serveur dédié. L'hébergeur cloud ne peut pas intervenir directement sur ce mécanisme noyau : c'est l'administrateur du serveur virtuel qui doit le configurer, au même titre qu'il gère son pare-feu (firewall) ou ses règles DNS.

Qu'est-ce que l'OOM killer ?

L'OOM killer (Out Of Memory killer) est un composant du noyau Linux qui s'active lorsqu'une allocation mémoire ne peut plus être satisfaite. Linux pratique par défaut l'overcommit : il alloue davantage de mémoire virtuelle que de RAM physique disponible, en pariant que tous les processus n'utiliseront pas leur allocation simultanément. Quand ce pari échoue, RAM pleine et swap plein, le noyau doit libérer de la mémoire de force.

Le noyau sélectionne alors le processus à éliminer en calculant un score de badness pour chaque tâche en cours. Ce score est principalement basé sur la quantité de mémoire utilisée par le processus par rapport à la mémoire totale disponible sur le système. Un processus utilisant toute la mémoire autorisée obtient un score de 1000 ; un processus en utilisant la moitié obtient un score de 500. Les processus root bénéficient d'un léger avantage (3 % de mémoire supplémentaire allouée virtuellement) dans ce calcul.

Sur un VPS cloud ou un serveur VPS Linux, la virtualisation isole les ressources entre les clients, mais à l'intérieur de votre machine virtuelle la RAM reste partagée entre tous vos processus. Un serveur de jeu gourmand qui monopolise toute la mémoire sans swap peut déclencher l'OOM killer en pleine session. Ce problème concerne aussi bien les VPS Ubuntu et Debian que les serveurs dédiés avec SSD NVMe, dès lors que le processeur et la mémoire vive sont saturés.

Détecter un kill dans dmesg et journalctl

Le noyau Linux consigne chaque intervention du OOM killer dans le ring buffer du noyau. Pour lire ces messages, utilisez dmesg :

dmesg -T | grep -i "oom\|killed process\|out of memory"

L'option -T affiche les timestamps en format lisible. Une sortie typique ressemble à :

[Thu Oct  1 03:14:22 2026] Out of memory: Killed process 4821 (java) total-vm:3456789kB, anon-rss:1987654kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:3876kB oom_score_adj:0

Ce message indique : le processus java (probablement votre serveur Minecraft) avec le PID 4821 a été tué car il utilisait environ 2 Go de mémoire anonyme. Avec journalctl, la commande équivalente pour un serveur administré via systemd est :

journalctl -k --since "1 hour ago" | grep -i "oom\|killed"

L'option -k restreint la sortie aux messages du noyau, équivalent à dmesg mais avec la gestion des rotations de journaux de journalctl. Pour visualiser tous les kills OOM depuis le dernier démarrage du serveur VPS Linux :

journalctl -k -b | grep -i "oom killer\|killed process"

Comprendre le score OOM de chaque processus

Chaque processus expose son score OOM actuel dans le pseudo-système de fichiers /proc. Pour connaître le score courant d'un processus (par exemple le processus java de votre serveur Minecraft), identifiez d'abord son PID :

pgrep -a java

Puis lisez son score :

cat /proc/<PID>/oom_score

Et son ajustement actuel :

cat /proc/<PID>/oom_score_adj

Le fichier oom_score (disponible depuis Linux 2.6.11) affiche le score calculé par le noyau. Le fichier oom_score_adj (depuis Linux 2.6.36) contient l'ajustement appliqué, compris entre -1000 et +1000. La valeur -1000 désactive complètement le OOM kill pour ce processus ; la valeur +1000 le rend toujours candidat prioritaire.

Pour inspecter le score OOM d'un daemon en cours d'exécution sur votre machine virtuelle ou serveur physique, une commande simple suffit :

# Lire le score OOM du processus FiveM (remplacez 1234 par le PID réel)
cat /proc/1234/oom_score
cat /proc/1234/oom_score_adj

Pour automatiser ce diagnostic sur tous les processus de jeu en cours, consultez leur historique de logs pour trouver des corrélations entre pics de consommation mémoire et kills. Un système de monitoring continu (alertes sur l'usage RAM) est encore plus efficace pour anticiper.

Protéger un processus critique

Pour réduire la probabilité que le OOM killer cible votre serveur de jeu, abaissez son score d'ajustement. La commande choom (util-linux) offre une interface simple :

# Abaisser l'ajustement du processus FiveM (PID 1234) à -500
choom -n -500 -p 1234

Pour un ajustement permanent via systemd, ajoutez la directive OOMScoreAdjust dans le fichier de service. Sur Ubuntu ou Debian, le fichier se trouve généralement dans /etc/systemd/system/fivem.service :

[Service]
OOMScoreAdjust=-500
ExecStart=/opt/fivem/FXServer +exec server.cfg

Rechargez la configuration systemd après toute modification :

systemctl daemon-reload
systemctl restart fivem

Pour protéger votre serveur Minecraft ou FiveM via le fichier oom_score_adj directement (si vous n'utilisez pas systemd) :

echo -500 | sudo tee /proc/<PID>/oom_score_adj

Cette modification est éphémère : elle disparaît au redémarrage du processus. C'est pourquoi le passage par OOMScoreAdjust dans le service systemd est fortement recommandé pour un serveur de jeu sur VPS Linux. Pensez aussi à réduire la consommation mémoire de votre serveur pour éloigner la saturation.

Régler l'overcommit mémoire

Le comportement d'overcommit est contrôlé par le paramètre noyau /proc/sys/vm/overcommit_memory qui accepte trois valeurs :

• 0 (défaut) : overcommit heuristique. Le noyau autorise les allocations en fonction d'estimations.
• 1 : overcommit illimité. Toutes les allocations sont autorisées quel que soit l'état de la mémoire.
• 2 : aucun overcommit. La mémoire virtuelle totale allouée ne peut dépasser CommitLimit = RAM * overcommit_ratio / 100 + swap.

Pour les serveurs de jeu sur VPS Ubuntu ou Debian, la valeur par défaut (0) convient dans la plupart des cas. La valeur 2 est utile pour les environnements de production critiques où on préfère un refus d'allocation explicite plutôt qu'un kill intempestif, mais elle peut provoquer des erreurs au démarrage de certains processus gourmands comme la JVM Minecraft.

Pour inspecter et modifier temporairement l'overcommit :

# Vérifier la valeur actuelle
cat /proc/sys/vm/overcommit_memory

# Passer en mode strict (non recommandé pour les serveurs de jeu)
sysctl -w vm.overcommit_memory=2

Pour rendre le changement permanent, ajoutez dans /etc/sysctl.conf ou dans un fichier /etc/sysctl.d/99-memoire.conf :

vm.overcommit_memory = 0

Swap, espace disque et limites cgroup

L'OOM killer ne se déclenche que quand toute la mémoire physique et tout le swap sont épuisés. Un swap bien dimensionné sur votre VPS Linux permet donc d'amortir les pics de consommation mémoire et de retarder (voire d'éviter) le OOM kill. Le swap utilise l'espace disque du serveur virtuel : vérifiez que vous disposez d'espace libre suffisant avant de l'activer.

Pour un serveur Minecraft avec 4 Go de RAM, un swap de 2 à 4 Go offre une marge de manoeuvre suffisante. Pour un serveur FiveM avec bases de données MySQL et des sauvegardes (backup) planifiées, un swap de 4 Go sur un VPS de 8 Go de RAM est un minimum raisonnable. Sur un serveur dédié avec SSD NVMe, le swap est négligeable en termes de latence et offre une flexibilité précieuse pour absorber des pics mémoire sans saturer la RAM.

Si vous utilisez des limites de ressources systemd (MemoryMax, MemoryHigh) via les directives cgroup, le OOM killer peut aussi être déclenché par l'atteinte de la limite du cgroup plutôt que par l'épuisement global. Dans ce cas, seuls les processus du cgroup concerné sont candidats au kill. Le message dans dmesg précisera alors Memory cgroup out of memory au lieu de Out of memory.

Bonnes pratiques sur un serveur VPS de jeu

Voici les actions concrètes à mettre en place sur un VPS Linux Ubuntu, Debian, CentOS ou Rocky Linux hébergeant un serveur de jeu. Ces bonnes pratiques s'appliquent à n'importe quel hébergeur dédié ou hébergement cloud, qu'il s'agisse d'une machine virtuelle KVM ou d'un serveur physique bare metal, quel que soit le fournisseur ou l'adresse IP du serveur :

1. Activer le swap sur l'espace disque disponible, avec une taille égale à 50 % de la RAM (minimum 2 Go). Voir le guide complet sur le swap.
2. Réduire la consommation mémoire du serveur de jeu avec les techniques du guide optimisation mémoire : limitation des plugins, réglage du heap Java, optimisation des bases de données.
3. Abaisser le OOMScoreAdjust du service de jeu à -500 dans le fichier systemd pour le protéger des kills prioritaires.
4. Consulter dmesg après chaque crash inexpliqué pour confirmer ou exclure un OOM kill avant de chercher un bug applicatif ou de contacter l'hébergeur.
5. Dimensionner le VPS en fonction de la charge réelle : un serveur FiveM avec 60 joueurs et des bases de données MySQL nécessite en général 8 Go de RAM minimum ; un serveur Minecraft vanilla 20 joueurs tourne confortablement sur 4 Go.
6. Mettre en place la détection automatique de panne pour être alerté dès que le processus de jeu tombe. La détection automatique de serveur hors service vous permettra d'agir avant que vos joueurs ne se plaignent.