Combien de RAM pour un serveur Minecraft ? Repères et mesure

Il n'existe pas de chiffre unique : un serveur vanilla entre amis démarre avec 1 à 4 Go de mémoire, alors que la documentation de Paper conseille au moins 6 à 10 Go pour un serveur réglé comme elle le recommande. Vous saurez quoi régler au lancement, pourquoi la RAM ne guérit pas tous les lags et comment mesurer la consommation réelle de votre serveur Java.

En bref

• Repères : 1 à 4 Go en vanilla selon le Minecraft Wiki, au moins 6 à 10 Go sur Paper avec les flags d'Aikar.
• -Xmx fixe le plafond du jeu, pas la consommation totale : gardez 1 à 1,5 Go de marge pour le système.
• Au-delà du nécessaire, plus de RAM n'apporte rien : PaperMC parle de rendements décroissants.
• Un serveur qui lag alors que le tas reste loin de son plafond manque de puissance par cœur : un tick doit durer 50 ms ou moins.
• Baissez la distance de vue, pré-générez le monde, puis mesurez avec spark avant d'acheter de la mémoire.

Ce que règlent -Xms et -Xmx

Minecraft Java tourne dans une machine virtuelle Java (JVM). Deux options fixent la mémoire de son « tas », la zone où vivent le monde chargé, les entités et les plugins : -Xms est la taille de départ, -Xmx la taille maximale. La documentation de Paper donne cet exemple, avec 4 Go :

java -Xms4G -Xmx4G -jar paper.jar --nogui

--nogui désactive l'interface graphique. Depuis Minecraft 26.1, Paper exige Java 25 : vérifiez avec java -version. Lancez la commande depuis le dossier du serveur, en remplaçant paper.jar par le nom exact du fichier téléchargé. Au premier démarrage, le serveur crée eula.txt et s'arrête : passez eula=false à eula=true pour accepter le contrat de Mojang (voir le tutoriel du wiki), puis relancez. Pour changer la mémoire ensuite, tapez stop dans la console, attendez l'arrêt complet, modifiez la commande et relancez. Ne fermez pas la fenêtre sans stop.

Ne copiez pas 4G tel quel : la machine doit avoir plus de RAM. Java occupe aussi de la mémoire hors du tas. PaperMC recommande de réduire -Xmx et -Xms d'environ 1 000 à 1 500 Mo par rapport à la RAM de la machine. Sinon, le « OOMKiller » de Linux (le mécanisme qui tue un programme quand la mémoire manque) peut arrêter le serveur. Avec 8 Go, la documentation donne 6 500 Mo : -Xms6500M -Xmx6500M (en Mo, sans virgule). Sur un ordinateur de bureau (Windows ou Linux), le wiki conseille de laisser au moins 1 Go de RAM physique en plus, pour que l'affichage ne rame pas.

Même valeur pour -Xms et -Xmx ? C'est la recommandation de PaperMC et d'Aikar : si -Xms est plus bas, la mémoire inutilisée est gaspillée. Retenez-le pour une machine dédiée.

Pour le ramasse-miettes (le mécanisme qui libère la mémoire inutilisée), Paper recommande les « flags d'Aikar », qui activent le collecteur G1 (-XX:+UseG1GC) : voici le bloc de la documentation, avec 10 Go. Il vaut pour Linux et macOS ; sous Windows, mettez tout sur une seule ligne dans un start.bat. Sur un VPS, ne lancez pas le serveur en root : créez un utilisateur dédié.

java -Xms10G -Xmx10G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true -jar paper.jar --nogui

-XX:+AlwaysPreTouch réserve toute la mémoire dès le démarrage : avec 10G, il faut réellement 10 Go libres. Remplacez seulement -Xms et -Xmx par votre RAM moins la marge. Avec 12 Go ou moins, ne touchez à rien d'autre. Au-delà, restez à 12 Go ou suivez la section sur les grands tas de l'article d'Aikar, qui change cinq valeurs.

Quels repères selon votre serveur ?

Ces sources ne décrivent pas la même situation. Le tableau du Minecraft Wiki suppose les réglages par défaut, un monde neuf et une distance de vue de 10 au plus ; un grand monde avec de la redstone et des fermes à monstres peut facilement plus que doubler les besoins. Ces chiffres valent pour le serveur seul : le système a besoin de RAM en plus. PaperMC recommande au moins 6 à 10 Go, même avec très peu de joueurs, pour un serveur lancé avec les flags d'Aikar.

Ajoutez les plugins un à un et mesurez après chacun (installer des plugins sur Paper et Spigot). Pour un modpack, suivez les auteurs du pack, puis ajustez sur la mesure. Pour héberger chez vous, voyez créer un serveur Minecraft sur son PC.

Une règle « 1 Go par joueur » n'a pas de base officielle : selon le Minecraft Wiki, un objet joueur n'occupe que 50 à 100 Mo, mais le serveur alloue souvent bien plus (chunks chargés, entités, plugins).

Pourquoi trop de RAM ne sert à rien

Selon PaperMC, plus de mémoire n'améliore plus les performances au-delà d'un certain point : 32 Go pour un serveur ne font que gaspiller de l'argent. La documentation précise aussi que G1 gère bien les grands tas : c'est son argument pour garder -Xms égal à -Xmx, pas une raison d'exagérer la taille du tas.

À l'inverse, un tas trop petit se signale par java.lang.OutOfMemoryError: Java heap space. Selon la documentation de Java, un objet n'a alors pas pu être alloué, parfois faute de taille suffisante. Si la machine a de la marge, montez -Xmx ; sinon, retirez des plugins ou changez d'offre. D'autres OutOfMemoryError existent (par exemple « Metaspace ») et ne se règlent pas avec -Xmx.

La RAM ne règle pas le lag dû au processeur

Minecraft tourne à 20 « ticks » par seconde : un tick est un cycle de calcul du jeu, qui doit durer 50 ms au plus. On parle de TPS pour le nombre de ticks par seconde et de MSPT pour la durée d'un tick. Si la machine ne suit pas, le TPS baisse, même avec de la mémoire libre.

Ce calcul dépend surtout d'un cœur. Selon le Minecraft Wiki, depuis la 1.14 le serveur emploie d'autres cœurs pour certaines opérations, mais en général trois cœurs au plus sont utilisés. Le SMT (deux threads par cœur physique) ne semble pas beaucoup aider, sans gêner non plus. La fréquence par cœur compte donc plus que leur nombre.

Redstone, grandes fermes et génération de nouveaux chunks allongent les ticks sans demander de RAM. La démarche complète est dans réduire le lag d'un serveur Minecraft.

Distance de vue et pré-génération

Dans server.properties, view-distance et simulation-distance valent 10 par défaut selon la documentation de Paper. La première est la quantité de monde envoyée à chaque joueur, la seconde la distance jusqu'où les entités sont mises à jour, en chunks (des portions de monde de 16 × 16 blocs), en rayon.

Pour simulation-distance, la zone est un carré dont le côté vaut 2 × la distance + 1 : à 10, elle fait environ 21 × 21 soit 441 chunks par joueur, contre environ 17 × 17 soit 289 à 8. Ces chiffres ne valent pas pour view-distance : le wiki indique que la distance d'affichage charge les chunks en cylindre autour du joueur, non en carré. Arrêtez le serveur avec stop, essayez view-distance=8 et simulation-distance=6 dans server.properties, relancez, puis jugez sur les mesures.

La pré-génération crée le monde à l'avance au lieu de le générer pendant la partie. Le wiki de Chunky conseille de la faire avant l'arrivée des joueurs. Chunky est un plugin à installer à part (jar dans plugins/, puis redémarrage) ; sans lui, la console signale une commande inconnue. Son exemple pré-génère un rayon de 5 000 blocs :

chunky radius 5000
chunky start

Le wiki prévient que les grands mondes prennent beaucoup d'espace disque et très longtemps à générer. Pour un premier essai, prenez chunky radius 2000 et vérifiez l'espace libre avec df -h sous Linux. Les joueurs peuvent dépasser la zone créée : worldborder set 4000 (diamètre en blocs) limite le monde. Sur un monde existant, sauvegardez avant : arrêtez le serveur avec stop, puis copiez le dossier du serveur entier.

Mesurer avec spark

Depuis la 1.21, Paper intègre le profileur spark. Selon la page des commandes, /spark supplante /tps et /mspt, qui fonctionnent toujours, et Timings est déprécié. Dans la console, tapez les commandes sans /. En jeu, ajoutez le / devant la commande et soyez opérateur (op VotrePseudo dans la console) : spark demande la permission spark.

spark health show --memory
spark tps
spark profiler start --timeout 600

• spark health show --memory affiche dans la console TPS, processeur, mémoire (tas, hors tas) et disque ; spark tps, le TPS et l'usage du processeur.
• spark profiler start --timeout 600 profile 10 minutes puis renvoie un lien vers un rapport en ligne. Lancez-le pendant que le lag se produit. Considérez ce lien comme public : ne le partagez qu'avec des personnes à qui vous acceptez de montrer votre configuration.

Attention aux variantes sans show. Selon la documentation de spark, spark health ouvre le rapport en ligne dans un tableau de bord et spark health upload envoie un rapport statique. Seule spark health show affiche le rapport dans la console, sans envoi. spark heapsummary et le profileur publient aussi en ligne.

Dans la sortie de spark health show, regardez les « Tick durations » (durées de tick en ms : sous 50 ms pour tenir 20 TPS) et la ligne « Memory usage ». Si le tas reste loin de son plafond aux heures de pointe, la mémoire n'est pas votre problème. S'il le touche de façon répétée, montez -Xmx par paliers, en gardant la marge.

Ce que montrent nos mesures au repos

Nous avons lancé un serveur Paper 26.2 (build 132) avec Java 25 (Eclipse Temurin 25.0.4.1) sur Ubuntu 24.04 sous WSL2, avec 24 processeurs logiques et le ramasse-miettes G1, le 9 octobre 2026. La commande était équivalente à java -Xms2G -Xmx2G -jar paper.jar --nogui (ou -Xms1G -Xmx2G), plus des options de journalisation et de blocage réseau sans effet sur la mémoire, donc sans flags d'Aikar ni AlwaysPreTouch. Un monde neuf, puis un redémarrage sur ce monde, avec deux réglages chacun. Aucun joueur ne s'est connecté. Chaque mesure date d'environ 90 secondes après le démarrage, avec une seule exécution par réglage.

La « mémoire du processus » est la mémoire résidente de Java, lue dans la colonne RSS de ps et convertie avec 1 Go = 1 024 Mo, comme dans spark. Voici la partie mémoire du rapport spark health show --memory relevé 90 secondes après le démarrage du premier essai :

> Memory usage:
    608.1 MB / 2.0 GB   (29%)
    [┃┃┃┃┃┃┃┃┃┃┃┃┃┃┃┃┃╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻╻]

> Non-heap memory usage:
    177.9 MB

• Le processus occupe bien plus que le tas utilisé : environ 2,24 Go côté système pour 608 Mo de tas.
• La mémoire occupée suit -Xms, pas le besoin : pour le même monde neuf, -Xms1G occupe environ 0,8 Go de moins que -Xms2G, avec un tas utilisé quasi identique. Sur une machine dédiée, on réserve quand même tout dès le départ ; sur un PC partagé, un -Xms plus bas libère de la mémoire au repos.

Ces chiffres ne disent rien du besoin d'un serveur en service. Sans joueur, sans plugin et avec un monde réduit à la zone de spawn, ils ne donnent qu'un plancher, non transposable à 5 ou 20 joueurs ni à un autre système. Pour connaître votre besoin, mesurez votre serveur en pleine affluence.

Questions fréquentes

Combien de RAM pour un serveur Minecraft à 5 joueurs ? En vanilla, le Minecraft Wiki donne 2 Go pour 5 à 10 joueurs. Sur Paper avec les flags recommandés, PaperMC conseille au moins 6 à 10 Go, même avec très peu de joueurs.

Faut-il le même -Xms et -Xmx ? Oui sur une machine dédiée, selon PaperMC et Aikar. Gardez -Xmx 1 à 1,5 Go sous la RAM de la machine.

Plus de RAM supprime-t-il le lag ? Non. Vérifiez les durées de tick avec spark : si elles dépassent 50 ms alors que le tas reste loin de son plafond, le processeur est en cause. Un tas collé au plafond allonge aussi les ticks.

Et chez JSBCloud ?

Les serveurs de jeux JSBCloud tournent sur des Ryzen 7 9700X avec mémoire DDR5 et SSD NVMe ; la fiche des offres rappelle que sur un serveur de jeu, c'est la fréquence par cœur qui fixe le plafond de joueurs. Vous pouvez passer à une offre supérieure à tout moment sans perdre vos données, ce qui permet de dimensionner par paliers. Le panel permet de surveiller les ressources en temps réel et de créer des sauvegardes à tout moment : faites-en une avant de changer d'offre.

Sources

• Aikar's flags, PaperMC
• Getting started, PaperMC
• Profiling, PaperMC
• Commands, PaperMC
• server.properties, PaperMC
• Tuning the JVM, G1GC Garbage Collector Flags for Minecraft, Aikar
• Server/Requirements, Minecraft Wiki
• Tick, Minecraft Wiki
• Setting up a Java Edition server, Minecraft Wiki
• Commands/worldborder, Minecraft Wiki
• Command Usage, spark
• Pregeneration, Chunky
• Troubleshooting memory leaks, Oracle

Informations vérifiées le 09/10/2026 (versions : mesures faites sur Paper 26.2 build 132 ; Java 25 / Eclipse Temurin 25.0.4.1 ; Minecraft Wiki pour Java Edition 26.3 ; spark intégré à Paper), mises à jour le 01/11/2026 pour la forme des zones de chunks et pour Paper : la 26.3 a des builds stables depuis le 11/10/2026. Les mesures de mémoire n'ont pas été refaites sur la 26.3.