RAM d'un serveur Minecraft : pourquoi plus n'est pas mieux

Par Yohann · 20 octobre 2026 · 4 min de lecture

« Combien de RAM pour mon serveur Minecraft ? » est une question légitime, mais elle cache souvent la vraie. Pas parce que la mémoire ne compte pas, mais parce qu'on lui attribue des problèmes qui n'ont rien à voir avec elle : un serveur généreusement doté peut laguer avec cinq joueurs, et un serveur modeste mais bien réglé tenir bien davantage.

Si vous cherchez seulement des ordres de grandeur, ils sont dans notre guide Combien de RAM pour un serveur Minecraft ?. Ici, je veux expliquer ce que fait la mémoire sur un serveur Minecraft, pour que vous puissiez la doser vous-même.

Ce que vous allouez n'est pas ce que le serveur consomme

Un serveur Minecraft Java est un processus Java. Le chiffre que vous réglez (-Xmx, ou la mémoire de la formule) fixe surtout la taille maximale du tas : l'espace où vivent les chunks, les entités, les données des plugins.

Mais le processus utilise aussi de la mémoire hors du tas : la machine virtuelle Java elle-même, le code compilé, les piles des threads, les tampons réseau, les bibliothèques natives. Conséquence pratique : si votre serveur tourne dans un conteneur limité à 4 Go et que vous donnez 4 Go au tas, le processus dépassera la limite. Le noyau le tuera, sans OutOfMemoryError dans la console, juste un arrêt brutal.

Règle simple : laissez une marge entre la limite du conteneur et -Xmx.

Pourquoi trop de mémoire peut faire laguer

Java libère la mémoire avec un ramasse-miettes (GC). Il travaille en tâche de fond, mais certaines phases interrompent brièvement le serveur. Plus le tas est grand et rempli d'objets à vieille durée de vie, plus ces passages peuvent coûter cher s'ils sont mal réglés.

Deux conséquences :

• un tas surdimensionné ne rend pas le serveur plus fluide : il repousse les passages du GC, qui deviennent plus lourds ;
• le réglage du GC compte autant que la taille. Les options de démarrage de G1 largement diffusées dans la communauté Paper existent pour cette raison : elles visent des pauses courtes et régulières plutôt que rares et longues.

L'objectif n'est pas « le plus de mémoire possible », c'est « assez de mémoire pour que le GC respire, et pas beaucoup plus ».

Le tick tourne sur un cœur

Le cœur de la simulation, le tick, s'exécute vingt fois par seconde, et pour l'essentiel sur un seul thread. Si une ferme à mobs, une machine de redstone ou un plugin mal écrit prend plus de 50 ms par tick, le TPS chute. Doubler la mémoire n'y change rien : c'est du temps de calcul, pas de la place.

C'est pour ça que je demande toujours un profil avant de parler de mémoire. Avec spark, intégré à Paper récent :

/spark tps
/spark health
/spark profiler start

Si la mémoire après un passage du GC reste confortable mais que le TPS est bas, cherchez dans le profil, pas dans la formule.

Ce qui remplit vraiment le tas

Dans l'ordre où je les rencontre :

1. Les mods. Un modpack charge des milliers de blocs, d'objets et de recettes avant même le premier joueur. C'est le premier facteur, de loin.
2. Les chunks chargés. Chaque joueur maintient une zone autour de lui. view-distance et simulation-distance dans server.properties agissent directement dessus : passer de 10 à 7 divise à peu près par deux le nombre de chunks par joueur.
3. La dispersion des joueurs. Dix joueurs regroupés dans une base coûtent bien moins que dix joueurs aux quatre coins de la carte.
4. Les entités. Élevages, objets au sol, fermes : la mémoire suit, le temps de tick aussi.
5. Certains plugins. Cartes web, journaux de blocs, tout ce qui garde beaucoup de données en mémoire.

Le nombre de joueurs n'arrive qu'ensuite, et surtout parce qu'il multiplie les points 2 à 4.

Ma méthode pour doser

1. Partez des repères du guide pour votre usage (Paper avec quelques plugins, modpack léger, gros modpack).
2. Pré-générez la carte avant d'ouvrir le serveur : la génération de chunks est l'une des opérations les plus lourdes, autant ne pas la faire pendant que les joueurs explorent. Le guide Optimiser un serveur Paper détaille la méthode.
3. Réglez view-distance et simulation-distance à des valeurs raisonnables.
4. Jouez une semaine, puis regardez /spark health aux heures d'affluence : la mémoire après un passage du GC est le vrai chiffre de consommation.
5. Si ce chiffre reste collé au plafond, montez d'une formule. S'il reste loin, la mémoire n'est pas votre problème.

Chez HebergHub

Nos formules Minecraft Java vont de 2 Go (Paper Starter, 3,99 € par mois) à 4 Go (Paper, Purpur, Vanilla et Fabric Standard, 7,99 €), 6 Go (Forge et NeoForge Standard, 11,99 €) et 8 Go (Paper Premium et modpacks, 14,99 €) ; en Bedrock, 2 à 4 Go (5,99 à 7,99 €). Si votre serveur manque de place, le bouton « Mettre à niveau » de la fiche du service vous fait passer à la formule supérieure, et seule la différence est facturée ; il n'y a pas d'engagement au-delà de la période choisie, ce qui permet de commencer petit et d'ajuster après mesure.

Le détail des offres est sur la page Serveur Minecraft, et la prise en main sur Créer son serveur Minecraft.