Votre serveur de jeu tourne bien, jusqu'à ce qu'il disparaisse soudainement sans avertissement. Pas de message d'erreur dans le chat, pas d'arrêt propre. Vous ouvrez le panneau et voyez que le serveur s'est arrêté. Dans les logs, vous trouvez « Out of memory » ou rien du tout. C'est un OOM-kill : le système d'exploitation a terminé de force le processus de votre serveur parce que la mémoire était épuisée.
Qu'est-ce qu'un OOM-kill ?
OOM signifie Out of Memory. Lorsqu'un serveur a consommé toute la RAM disponible et qu'il n'en reste plus, le système d'exploitation intervient. Le OOM-killer de Linux sélectionne le processus qui utilise le plus de mémoire et le termine immédiatement. Votre serveur de jeu est presque toujours ce processus. Le résultat : un crash brutal sans sauvegarde propre, avec potentiellement des données de monde endommagées.
Reconnaître les symptômes
- Le serveur se fige brièvement puis disparaît complètement (pas de message « server closed »).
- Dans les logs système (pas les logs du jeu) apparaît « Out of memory: Killed process » ou « oom-kill ».
- Pour les jeux Java (Minecraft, modpacks) :
java.lang.OutOfMemoryError: Java heap spacedans la console juste avant le crash. - Le serveur redémarre de lui-même (si le redémarrage automatique est activé) et tourne normalement un moment, jusqu'à ce que le schéma se répète.
Causes courantes
- Trop de joueurs ou d'entités : chaque joueur charge des chunks, et chaque chunk contient des entités (mobs, objets, objets au sol). Cent vaches dans une ferme ou des milliers d'objets au sol dévorent la mémoire.
- Fuites de mémoire dans les plugins ou mods : certains plugins réservent de la mémoire qu'ils ne libèrent jamais. Après des heures de fonctionnement, l'utilisation de la mémoire croît continuellement, jusqu'à atteindre la limite.
- Pas assez de RAM allouée : un serveur Minecraft avec 20 mods sur 2 Go de RAM va certainement planter. Les modpacks ont besoin de 4 à 8 Go, selon le pack.
- Monde trop largement chargé : une view distance élevée (16 ou plus) charge énormément de chunks simultanément. Chaque chunk coûte de la mémoire, et avec plusieurs joueurs éloignés les uns des autres, cela se multiplie.
- Pas de planning de redémarrage : même sans fuites, l'utilisation de la mémoire augmente après 24 heures ou plus de fonctionnement continu. Redémarrer régulièrement évite qu'elle atteigne le maximum.
Solutions étape par étape
1. Vérifiez les logs pour l'OOM
Consultez les logs du serveur dans votre panneau. Cherchez « OutOfMemoryError », « heap space » ou « oom ». Si vous avez un accès SSH, vérifiez aussi dmesg | grep -i oom pour les OOM-kills au niveau système. Cela confirme que la mémoire est le problème et non un autre crash.
2. Augmentez la mémoire allouée
Si votre serveur atteint structurellement la limite, vous avez besoin de plus de RAM. Pour Minecraft, vous le configurez avec le flag -Xmx (par exemple -Xmx4G pour 4 Go). Attention : n'allouez pas plus que ce que votre plan offre, sinon le OOM-killer terminera quand même le processus. Mettez éventuellement à niveau votre plan d'hébergement pour plus de mémoire.
3. Trouvez et supprimez les plugins qui fuient
Installez un plugin de profilage comme Spark (pour Minecraft). Laissez le serveur tourner quelques heures et consultez le rapport de heap. Les plugins qui réclament de plus en plus de mémoire sans la libérer sont les coupables. Supprimez-les ou remplacez-les et surveillez si l'utilisation de la mémoire se stabilise.
4. Configurez un planning de redémarrage
Planifiez des redémarrages automatiques toutes les 6 à 12 heures. Cela donne au serveur une page blanche en termes de mémoire. Utilisez le planificateur dans votre panneau (Pterodactyl : Schedules, action « Power: Restart ») ou un plugin en jeu qui avertit les joueurs avant le redémarrage.
5. Utilisez les Aikar flags pour Minecraft
Les Aikar JVM flags optimisent la gestion de la mémoire par Java. Ils configurent le garbage collector pour effectuer régulièrement de petits cycles de nettoyage au lieu d'un grand, de sorte que le serveur souffre moins de pics de lag dus au nettoyage de la mémoire. Ajoutez les flags à votre ligne de commande de démarrage ; ils sont expliqués dans la documentation de Paper.
6. Limitez le monde
Définissez une bordure de monde (/worldborder set 10000 pour un rayon de 5000 blocs). Réduisez la view distance à 8 ou 10. Utilisez des plugins qui nettoient automatiquement les entités (comme ClearLagg) pour supprimer les objets au sol et les mobs superflus.
Vous manquez structurellement de mémoire ? Consultez les plans HostValues avec suffisamment de RAM pour votre configuration. La mise à niveau peut se faire directement depuis le panneau, sans perte de données.
La mémoire swap aide-t-elle contre les crashes OOM ?
Le swap (mémoire disque comme RAM de secours) peut temporairement éviter un OOM-kill, mais ce n'est pas une solution. Le swap est des dizaines de fois plus lent que la vraie RAM. Un serveur de jeu qui tourne sur le swap a tellement de lag que les joueurs ne peuvent pas jouer. Le swap vous achète tout au plus du temps pour investiguer la situation, mais votre serveur a vraiment besoin de plus de RAM.
Comment trouver quel plugin fuit la mémoire ?
Installez Spark (pour Paper/Purpur) et générez un heap dump après quelques heures de fonctionnement. Le rapport montre quels objets occupent le plus de mémoire. Si un objet lié à un plugin est en tête et grandit à chaque mesure, c'est votre fuite. Vous pouvez aussi désactiver les plugins un par un et surveiller si l'utilisation de la mémoire se stabilise.
Comment distinguer un OOM d'autres crashes ?
Lors d'un crash OOM, le serveur disparaît brusquement sans message d'arrêt propre. Dans les logs du jeu apparaît souvent « OutOfMemoryError » juste avant la fin. Lors d'un crash normal (par un bug ou une corruption), vous voyez généralement une stacktrace ou un message d'erreur. Lors d'un problème réseau ou matériel, le serveur continue de tourner mais est injoignable. Vérifiez toujours à la fois les logs du jeu et le niveau système (événements du panneau, dmesg) pour déterminer le type de crash.
