Bien dimensionner la RAM d'un serveur de jeu selon les joueurs et les mods

La RAM serveur de jeu est la ressource la plus mal comprise par les administrateurs débutants : on lui attribue tous les lags, on en ajoute au hasard, et rien ne change. La mémoire vive détermine pourtant ce que ton monde peut garder en mémoire à un instant T. Voici comment la dimensionner sérieusement, en fonction des joueurs, des mods et du moteur du jeu.

Comprendre le rôle réel de la RAM serveur de jeu

Un serveur de jeu maintient en mémoire l'état complet du monde simulé : chunks ou cellules chargées, entités (PNJ, mobs, animaux, véhicules), inventaires, structures posées par les joueurs, et l'ensemble du code des mods. La RAM sert de zone de travail : plus le monde est vaste, peuplé et modé, plus cette zone doit être large. En dessous d'un certain seuil, le processus passe son temps à recycler de la mémoire au lieu de faire tourner la boucle de simulation, et le tick rate s'effondre.

Selon le jeu que tu administres, les ordres de grandeur changent complètement. Si tu prépares une infrastructure autour d'un serveur Java modé, la page hébergeur Minecraft détaille les configurations disponibles pour ce moteur précis. Pour les autres titres, la logique de dimensionnement reste la même, mais les seuils diffèrent fortement.

RAM allouée n'est pas RAM utilisée

C'est la confusion la plus fréquente, en particulier sur les jeux tournant en Java. Quand tu alloues 8 Go à une JVM, le processus va progressivement remplir cet espace jusqu'à déclencher un ramasse-miettes (garbage collector). Voir 90 % d'occupation dans le panel n'est donc pas un problème en soi : c'est le comportement normal d'une JVM. Ce qui compte, c'est la fréquence et la durée des cycles de GC. Un GC long et répété toutes les 10 secondes produit des micro-freezes visibles en jeu ; une occupation stable à 85 % avec un GC toutes les deux minutes ne pose aucun souci.

À l'inverse, les moteurs natifs (Unreal Engine pour ARK, C++ pour Rust) consomment ce dont ils ont besoin, sans plafond artificiel. Si la mémoire manque, le noyau tue le processus. Pas de dégradation progressive : un arrêt brutal.

Ce qui consomme vraiment de la mémoire

• Le monde chargé : chaque chunk ou cellule active occupe de la mémoire. La distance de vue et de simulation multiplie ce volume par joueur connecté.
• Les entités : mobs, animaux apprivoisés, véhicules, items au sol. Sur ARK ou Rust, c'est souvent le premier poste de consommation après plusieurs mois de wipe.
• Les structures posées : une base de 40 000 pièces sur ARK pèse lourd, en RAM comme en temps de sauvegarde.
• Les mods et plugins : chaque mod charge ses classes, ses assets et ses données persistantes. Un modpack de 200 mods peut consommer 4 Go avant même qu'un joueur ne se connecte.
• Les joueurs : chacun ouvre une zone chargée autour de lui. Dix joueurs dispersés coûtent bien plus que dix joueurs regroupés sur une même base.

Retiens ceci : la dispersion des joueurs sur la carte coûte plus cher en mémoire que leur nombre brut.

Dimensionner selon le jeu, les slots et les mods

Il n'existe pas de règle universelle, mais des fourchettes fiables issues du terrain. Le tableau ci-dessous donne des points de départ raisonnables pour une instance stable, sauvegardes et redémarrages planifiés inclus.

Jeu	Vanilla, 10 joueurs	Modé / 20-40 joueurs	Facteur dominant
Minecraft (Paper/Purpur)	3 à 4 Go	6 à 10 Go	Plugins, view-distance
Minecraft moddé (Forge/NeoForge)	6 à 8 Go	10 à 16 Go	Nombre de mods, dimensions
ARK: Survival Evolved	8 à 12 Go	16 Go et plus	Structures, dinos apprivoisés
ARK: Survival Ascended	12 à 16 Go	20 Go et plus	Moteur UE5, taille de la carte
Rust	8 à 10 Go	16 Go et plus	Taille de map, entités posées
Palworld	8 à 12 Go	16 Go	Pals gérés, bases automatisées
Valheim	4 Go	6 à 8 Go	Constructions, zones explorées
Project Zomboid	4 Go	8 Go	Cellules chargées, zombies actifs
Satisfactory	6 à 8 Go	10 à 12 Go	Taille de l'usine, convoyeurs
7 Days to Die	6 à 8 Go	12 Go	Dégâts persistants du terrain
FiveM	4 à 6 Go	8 à 16 Go	Nombre de ressources, framework

Trois règles de dimensionnement qui tiennent la route

1. Pars du socle du jeu, puis ajoute les mods. Compte environ 40 à 60 Mo de mémoire par mod lourd sur Minecraft moddé, quasiment rien pour un mod de textures côté client. Un modpack de 150 mods réclame typiquement 8 Go minimum avant toute charge joueur.
2. Compte 100 à 200 Mo par joueur actif sur la plupart des jeux de survie, davantage si ta communauté joue dispersée sur une grande carte.
3. Garde 20 % de marge. Une instance qui tourne en permanence à 98 % n'a plus aucune tolérance aux pics : raid nocturne, explosion massive, chargement simultané de plusieurs zones.

Le piège de la sur-allocation

Donner 24 Go à un serveur Minecraft qui en utilise 6 est contre-productif. Le tas devient si grand que chaque cycle de ramasse-miettes doit parcourir un volume énorme, ce qui allonge les pauses. Sur une JVM, l'objectif n'est pas de maximiser la mémoire mais de trouver le palier où les GC sont espacés et courts. En pratique, un ajustement fin bat toujours la surenchère.

La même logique vaut pour ARK ou Rust : au-delà d'un certain point, ce n'est plus la mémoire qui limite, mais la fréquence du processeur, puisque la boucle de simulation reste largement mono-thread. C'est précisément pourquoi les processeurs Ryzen haute fréquence associés à du stockage NVMe donnent des résultats plus nets que l'ajout aveugle de gigaoctets. Tu peux comparer les configurations proposées par jeu sur Tous nos serveurs de jeu.

Mesurer et diagnostiquer la RAM serveur de jeu

Lire correctement les graphiques du panel

Le panel Pterodactyl affiche la consommation mémoire du conteneur en temps réel. Observe-la sur 24 heures, pas sur 30 secondes. Le profil typique d'une instance saine : une montée régulière, un décrochage net (le GC ou le déchargement des zones), puis une remontée. Le profil inquiétant : une courbe qui monte sans jamais redescendre, jusqu'au plafond. C'est une fuite mémoire, presque toujours causée par un plugin ou un mod précis.

Diagnostiquer depuis la console

Sur un serveur Minecraft, le plugin de profilage Spark reste l'outil de référence pour identifier ce qui remplit la mémoire :

/spark heapsummary
/spark profiler start --timeout 300
/spark tps

Le rapport te donne la répartition des objets en mémoire par classe. Si tu vois des dizaines de milliers d'entités d'un même type, tu tiens ton coupable : hoppers en masse, fermes à mobs mal conçues, ou un mod qui n'invalide jamais son cache.

Sur une machine Linux que tu administres toi-même, les vérifications de base :

# Vue globale de la mémoire, en format lisible
free -h

# Processus classés par consommation mémoire
ps aux --sort=-%mem | head -n 10

# Consommation par conteneur si tu utilises Docker
docker stats --no-stream

# Historique du ramasse-miettes d'une JVM
jstat -gcutil $(pgrep -f "server.jar") 5000

Décoder les erreurs les plus fréquentes

Symptôme	Cause probable	Correction
Exit code 137 dans la console	Le processus a été tué par le noyau, mémoire épuisée	Réduire la charge (distance de vue, entités) ou monter d'un palier
java.lang.OutOfMemoryError: Java heap space	Tas JVM saturé	Augmenter -Xmx, ou traquer la fuite avec Spark
TPS à 12-15 mais RAM à 50 %	Limite processeur, pas mémoire	Alléger la simulation, pas d'ajout de RAM utile
Freeze de 2 à 5 secondes toutes les minutes	Cycles de GC trop longs	Ajuster les flags JVM, réduire le tas
Sauvegarde qui fige le monde	Écriture disque massive	Planifier les sauvegardes hors pic de connexion

Optimiser avant d'ajouter des gigaoctets

Régler les paramètres qui pèsent le plus

Sur Minecraft, deux valeurs de server.properties pilotent l'essentiel de la charge mémoire :

view-distance=8
simulation-distance=6
max-tick-time=60000
sync-chunk-writes=false

Passer de 12 à 8 en distance de vue réduit le volume de chunks chargés de plus de la moitié, sans impact réel sur le ressenti des joueurs. Complète avec les fichiers spigot.yml et paper-world-defaults.yml pour limiter le nombre d'entités par chunk et activer le regroupement des mobs.

Sur ARK, la propreté du monde compte davantage que la mémoire brute. Active la décomposition automatique des structures abandonnées et limite le nombre de créatures apprivoisées par tribu dans GameUserSettings.ini :

[/Script/ShooterGame.ShooterGameMode]
MaxTamedDinos=4000
MaxPersonalTamedDinos=200
bAutoPvETimer=False
PvEStructureDecayPeriodMultiplier=1.0

Sur Rust, une carte de 4500 consomme sensiblement moins qu'une carte de 6000, et le wipe périodique reste l'outil de maintenance mémoire le plus efficace. Les paramètres complets sont documentés sur la page Serveur Rust. Même logique côté Serveur Valheim, où la taille du monde exploré fait grimper la consommation au fil des semaines.

Des flags JVM cohérents

Pour un serveur Java, les paramètres de ramasse-miettes ont un impact direct sur la fluidité. Un jeu de flags éprouvé, à adapter à ton allocation :

java -Xms8G -Xmx8G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:InitiateHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Point important : -Xms et -Xmx doivent être identiques. Laisser la JVM redimensionner son tas en cours de route provoque des pauses inutiles. Le détail de chaque flag est documenté par l'équipe Paper — voir la documentation officielle Paper.

Pré-générer et redémarrer intelligemment

La génération de terrain à la volée est l'un des pics de consommation les plus violents. Pré-générer une zone de 5000 blocs de rayon avec Chunky avant l'ouverture de ta communauté évite ces à-coups. De même, un redémarrage planifié toutes les 8 à 12 heures remet le tas à plat et purge les objets orphelins ; c'est une mesure d'hygiène, pas un aveu d'échec.

Ne jamais oublier les sauvegardes

Une instance qui frôle en permanence son plafond mémoire finit par être tuée en pleine écriture du monde, avec un risque réel de corruption. Vérifie que tes sauvegardes automatiques tournent, teste une restauration au moins une fois, et conserve toujours une copie hors instance. C'est le filet de sécurité qui transforme un incident mémoire en simple contretemps de dix minutes. D'autres guides de configuration sont disponibles sur le Blog Fly-Serv.

Checklist rapide

• Observer la consommation sur 24 h avant toute décision.
• Vérifier si le TPS chute réellement ou si seule la mémoire est haute.
• Profiler avec Spark ou l'équivalent pour identifier le coupable.
• Réduire distance de vue, entités et structures fantômes.
• Aligner -Xms et -Xmx, ajuster les flags GC.
• Planifier redémarrages et sauvegardes hors heures de pointe.
• Ne monter d'un palier mémoire qu'après ces étapes.

Conclusion

Bien dimensionner la mémoire d'un monde multijoueur relève de la mesure, jamais de l'intuition. Observe tes courbes sur plusieurs jours, identifie ce qui remplit réellement le tas, ajuste distance de simulation et entités, puis seulement ensuite envisage un palier supérieur. Cette méthode évite les dépenses inutiles et donne un monde stable, même avec beaucoup de mods et une communauté active.

FAQ

Comment savoir si mes lags viennent de la mémoire ou du processeur ?

Regarde le TPS et la RAM en parallèle. Si le TPS chute alors que la mémoire reste sous 70 %, la limite est processeur : trop d'entités à simuler ou un plugin gourmand en calcul. Si la mémoire sature avec des freezes réguliers de plusieurs secondes, c'est le ramasse-miettes qui bloque la boucle de jeu. Un profilage avec Spark tranche en quelques minutes.

Faut-il allouer toute la mémoire disponible à la JVM ?

Non. Laisse au moins 1 à 2 Go au système, aux processus de sauvegarde et au cache disque. Et surtout, évite un tas surdimensionné : un tas de 24 Go pour un usage réel de 6 Go allonge les cycles de ramasse-miettes et dégrade la fluidité. Trouve le palier où les GC sont courts et espacés, puis ajoute 20 % de marge.

Combien de mémoire ajouter quand j'installe un gros modpack ?

Compte 40 à 60 Mo par mod lourd, davantage pour ceux qui ajoutent des dimensions, des systèmes de machines ou une génération de terrain personnalisée. Un pack de 150 à 250 mods demande généralement 8 à 12 Go pour rester confortable avec une dizaine de joueurs. Vérifie aussi les recommandations publiées par l'auteur du pack, puis mesure sur 48 h.