Calculateur de RAM pour serveur Minecraft

Combien de RAM faut-il pour un serveur Minecraft ?

La plupart des serveurs Paper tournent bien avec 3 à 8 Go de heap : 3 ou 4 Go pour un groupe d’amis, 5 ou 6 Go pour 20 ou 30 joueurs avec un ensemble de plugins classique, et 8 Go ou plus au-delà de 50 joueurs. L’offre que vous louez doit être un peu plus grande, car Java utilise aussi de la mémoire en dehors du heap.

Le calculateur ci-dessus fait le même calcul avec vos chiffres. Prenez le résultat comme point de départ : l’usage réel dépend de la dispersion des joueurs, de la view distance et de ce que fait chaque plugin.

Comment l’estimation est calculée

Le calculateur additionne le heap, c’est-à-dire la mémoire que Java donne à Minecraft (celle que vous réglez avec -Xmx) :

• 2 Go de base pour Paper ou Purpur avec ses mondes chargés et personne en ligne. Folia part de 3 Go, car il est conçu pour beaucoup de joueurs répartis sur la carte.
• 75 Mo par joueur connecté en même temps. Chaque joueur garde chargés les chunks autour de lui, avec les mobs et les items qu’ils contiennent. Des joueurs dispersés dans le monde coûtent plus que des joueurs regroupés dans un lobby.
• 40 Mo par plugin, en moyenne. La plupart des plugins utilisent bien moins, et quelques-uns bien plus.
• 2 Go de plus pour les plugins lourds ou un grand monde : cartes web (Dynmap, BlueMap), modèles personnalisés (ItemsAdder, ModelEngine), beaucoup de mobs ou de fermes, ou une view distance au-delà de 10.
• Les trois quarts du total en 1.8 à 1.11, dont les chunks sont plus légers.

Le résultat est arrondi au Go supérieur et ne descend jamais sous 3 Go (2 Go en 1.8 à 1.11). Le minimum en fait environ les deux tiers : le serveur tourne, mais avec peu de marge pour les moments chargés, la génération de nouveaux chunks ou les sauvegardes. Le calculateur s’arrête à 31 Go, car au-delà d’environ 32 Go Java désactive les compressed object pointers, et dépasser un peu ce seuil laisse moins de mémoire utilisable, pas plus.

Ces chiffres sont volontairement larges. Manquer de mémoire fait saccader un serveur puis le fait crasher, alors qu’un peu trop ne coûte qu’un peu plus chaque mois.

Laissez de la place à Java : heap et offre

-Xmx ne limite que le heap. Java utilise aussi de la mémoire pour les classes de chaque plugin, ses threads, le code qu’il compile, les buffers réseau et la comptabilité interne du garbage collector. Le calculateur réserve pour cela 1 Go ou 15 % du heap, selon le plus grand des deux, conformément au conseil de Paper de donner à -Xmx 1000 à 1500 Mo de moins que la mémoire dont vous disposez. En pratique :

• Vous louez une offre : fiez-vous à la taille d’offre qu’indique le calculateur, pas au heap. Un heap de 8 Go nécessite une offre de 10 Go.
• Vous avez déjà une offre : indiquez-la dans RAM de votre offre et les flags seront dimensionnés pour tenir dedans. Une offre de 8 Go laisse un heap de 6,5 Go.
• Pterodactyl, Docker et la plupart des hébergeurs limitent le conteneur entier. Si Java dépasse, le serveur est tué sur-le-champ, souvent sans aucune erreur dans la console.
• Votre propre PC ou VPS : laissez de la mémoire au système d’exploitation et à tout ce qui tourne à côté.

Pourquoi -Xms est égal à -Xmx

Les flags d’Aikar donnent la même valeur à -Xms et -Xmx et ajoutent -XX:+AlwaysPreTouch, qui réserve tout le heap au démarrage du serveur. G1 fonctionne mieux avec un heap qui ne grandit ni ne rétrécit jamais, et si la mémoire n’est pas vraiment là, vous le découvrez au démarrage. Un effet secondaire : le graphique de mémoire de votre panel montre tout le heap utilisé dès la première minute. C’est normal.

Les flags d’Aikar et ZGC

Les flags d’Aikar règlent le garbage collector G1 selon la façon dont Minecraft utilise la mémoire : d’énormes quantités d’objets qui vivent un seul tick, et des pauses qui doivent rester courtes. Paper les recommande, et ils conviennent aux serveurs de toutes tailles. Au-delà de 12 Go de heap, le calculateur passe aux valeurs d’Aikar pour les gros heaps : G1NewSizePercent=40, G1MaxNewSizePercent=50, G1HeapRegionSize=16M, G1ReservePercent=15 et InitiatingHeapOccupancyPercent=20.

ZGC est un autre collector qui fait presque tout son travail pendant que le serveur continue de tourner, si bien que les pauses restent sous la milliseconde. En échange, il consomme plus de CPU, et il n’a de sens que sur les gros heaps (16 Go ou plus) avec des cœurs disponibles. Utilisez la version générationnelle : en Java 21 elle nécessite -XX:+ZGenerational, et à partir de Java 23 c’est le mode par défaut, donc le calculateur omet ce flag. Dans le doute, restez sur G1.

Quelle version de Java

C’est le tableau de la documentation de Paper. Vérifiez celle que vous avez avec java -version. Si plusieurs sont installées, le script lance celle qu’exécute la commande java.

Démarrer le serveur

1. Renseignez les joueurs, les plugins, le logiciel et la version, ainsi que la RAM de votre offre si vous en avez déjà une.
2. Choisissez un Script de démarrage :
   • start.sh pour Linux et macOS. Enregistrez-le à côté du jar, lancez chmod +x start.sh une fois, puis ./start.sh.
   • start.bat pour Windows. Enregistrez-le à côté du jar et double-cliquez dessus. Le pause à la fin garde la fenêtre ouverte si le serveur s’arrête, pour que vous puissiez lire l’erreur.
   • Pterodactyl donne la commande de démarrage, avec {{SERVER_JARFILE}} pour que le panel remplisse le jar. Réglez ensuite la mémoire du serveur dans le panel sur au moins la taille de l’offre.
   • Flags seuls est pour les hébergeurs qui ont un champ pour les arguments JVM. Si votre hébergeur règle lui-même la mémoire, retirez -Xms et -Xmx.
3. Cliquez sur Copier. Copier le lien de partage garde vos réglages dans le lien.

Quand plus de RAM n’aidera pas

Le lag vient en général du CPU : un serveur normal fait l’essentiel de son travail sur un seul thread principal, donc un cœur plus rapide aide plus que de la mémoire en plus. Avant de passer à une offre supérieure, lancez /spark health pour voir la mémoire et le TPS, et /spark profiler pour voir ce qui prend du temps. spark est inclus dans Paper depuis la 1.21. Baisser view-distance et simulation-distance économise à la fois de la mémoire et du CPU, et prégénérer le monde avec un plugin comme Chunky évite les pics de lag liés à la génération de nouveaux chunks pendant que les gens jouent.