Combien de RAM pour un serveur Minecraft ?

La RAM est le premier chiffre affiché sur toutes les offres d'hébergement Minecraft, et la question « combien m'en faut-il ? » n'a pas de réponse unique. Tout dépend de ce que fait tourner le serveur, du nombre de joueurs connectés simultanément, de la distance de rendu et de ce que vous avez ajouté par-dessus. Ce guide donne des fourchettes indicatives, explique chaque paramètre et montre comment vérifier si votre allocation actuelle est trop juste ou inutilement généreuse.

Pourquoi la mémoire compte, et pourquoi plus n'est pas toujours mieux

Un serveur Minecraft est une application Java. Tout ce qu'il garde actif vit dans le tas (heap) Java : chunks chargés, entités, inventaires des joueurs, données des plugins, registres des mods. Quand le tas se remplit, le ramasse-miettes (garbage collector) doit travailler davantage pour libérer de la place, ce qui se traduit par des pics de lag réguliers. Si la mémoire vient à manquer complètement, le serveur plante.

Au-delà d'un certain seuil, en revanche, ajouter de la RAM n'apporte rien. La logique de jeu tourne principalement sur un seul thread : un serveur limité par le processeur ne deviendra pas plus rapide avec davantage de mémoire. Un tas très volumineux peut même allonger les pauses du ramasse-miettes si les arguments de la JVM ne sont pas réglés. C'est pour cela qu'existent des arguments de démarrage très répandus comme les flags d'Aikar : ils configurent le collecteur G1 pour le profil d'allocation de Minecraft, et ils partent du principe d'un tas bien dimensionné, pas maximisé.

L'objectif est d'avoir assez de marge pour le pic de charge, pas de prendre la plus grosse offre possible.

Le socle : quel type de serveur ?

Le type de serveur fixe le point de départ, avant même que le premier joueur se connecte. Voici des valeurs de base indicatives, cohérentes avec la manière dont notre calculateur de RAM commence son estimation :

Type de serveur	Base indicative	Remarques
Vanilla	environ 2 Go	Serveur officiel ou Paper sans plugins
Serveur à plugins	environ 2,5 Go	Paper, Purpur ou Spigot avec un nombre modéré de plugins
Modpack léger	environ 4 Go	Petits packs Fabric ou Forge, mods de performance, quelques mods de contenu
Modpack lourd	environ 6 Go	Gros packs « kitchen sink » ou techniques avec des centaines de mods

Ce ne sont pas des mesures réalisées sur un pack précis, mais des points de départ raisonnables à ajuster selon les paramètres ci-dessous.

Paper et Purpur méritent une mention : ils intègrent de nombreuses optimisations par rapport au serveur vanilla (gestion des chunks améliorée, limites d'entités configurables), ce qui explique en partie pourquoi ils sont le choix par défaut pour un serveur à plugins.

Les paramètres qui font grimper la consommation

Les joueurs simultanés

Chaque joueur connecté charge les chunks qui l'entourent et ajoute des entités, des données d'inventaire et des tampons réseau. Ce qui compte, c'est le nombre de joueurs connectés en même temps, pas la taille de votre whitelist. Des joueurs dispersés sur la carte coûtent plus cher que des joueurs regroupés dans une même ville, car ils maintiennent davantage de chunks distincts en mémoire.

Les plugins et les mods

Les plugins sont très inégaux. Un plugin de mise en forme du chat ne consomme presque rien ; une carte dynamique, un plugin d'économie adossé à une grosse base de données ou un gestionnaire chargeant plusieurs mondes peuvent peser lourd. Pour les mods, leur nombre donne une idée approximative, mais les mods riches en contenu (nouvelles dimensions, grands systèmes de machines, refonte de la génération du monde) pèsent bien plus que les petits mods utilitaires.

Distance de rendu et distance de simulation

La distance de rendu (view-distance) définit combien de chunks autour de chaque joueur sont envoyés au client. La distance de simulation (simulation-distance) définit combien de chunks sont réellement actifs : les mobs bougent, les cultures poussent, la redstone fonctionne. Sur de nombreux serveurs, la distance de rendu par défaut est de 10 chunks.

Le nombre de chunks augmente avec le carré du rayon : passer de 10 à 16 chunks fait plus que doubler la surface chargée autour de chaque joueur. Au-delà de 10 chunks, la consommation grimpe vite, c'est pourquoi notre calculateur ajoute de la mémoire pour chaque palier supplémentaire. Réduire la distance de simulation tout en gardant une distance de rendu raisonnable est une méthode courante pour économiser à la fois processeur et RAM.

Les mondes et l'exploration

Chaque monde supplémentaire (le Nether et l'End comptent, tout comme des mondes survie ou mini-jeux additionnels) garde sa zone de spawn et les chunks occupés par des joueurs en mémoire. L'exploration intensive en élytres charge et génère aussi beaucoup de nouveaux chunks très vite, ce qui provoque des pics de mémoire et de processeur. Prégénérer le monde avec un plugin ou un mod avant l'arrivée des joueurs évite ces pics pendant les sessions de jeu.

Fourchettes indicatives selon l'usage

En combinant la base et les paramètres, on obtient des fourchettes pour les situations courantes. À prendre comme repères, pas comme garanties :

Vanilla ou Paper, quelques amis, distance de rendu par défaut : 2 à 4 Go.
Serveur à plugins, petite communauté de 10 à 20 joueurs connectés : 4 à 6 Go.
Serveur à plugins avec plus de joueurs, plusieurs mondes ou une carte dynamique : 6 à 10 Go, et le processeur devient la contrainte principale.
Modpack léger, petit groupe : 4 à 6 Go.
Modpack lourd, petit groupe : 6 à 10 Go.
Modpack lourd avec beaucoup de joueurs ou une grande distance de rendu : 10 Go et plus, souvent sur une offre à CPU dédié.

Pour un chiffre adapté à votre configuration, indiquez le type de serveur, le nombre de joueurs, les plugins ou mods et la distance de rendu dans le calculateur de RAM. Il applique la logique décrite ci-dessus et arrondit le résultat à une taille d'offre courante.

Les signes d'un manque (ou d'un excès) de RAM

Inutile de deviner : le serveur vous renseigne.

Signes d'un manque de mémoire :

des pics de lag réguliers toutes les quelques secondes ou minutes, qui correspondent aux cycles du ramasse-miettes,
des avertissements « Can't keep up! » associés à une forte utilisation mémoire dans le panel,
des messages OutOfMemoryError dans la console ou dans les rapports de plantage,
un panel qui affiche une mémoire en permanence proche de la limite.

Signes que vous avez plus que nécessaire :

l'utilisation mémoire reste bien en dessous de l'allocation, même aux heures de pointe,
le TPS chute sans que la mémoire soit pleine (le problème vient alors du processeur, pas de la RAM).

Un profileur comme spark, disponible en plugin ou en mod, affiche à la fois l'utilisation mémoire et ce qui consomme le temps de chaque tick. C'est le moyen le plus fiable de distinguer un problème de mémoire d'un problème de processeur.

Conseils pratiques pour consommer moins

Utilisez Paper ou Purpur pour un serveur à plugins, et des mods de performance sur un serveur Fabric ou NeoForge.
Gardez la distance de rendu à 10 ou moins sur un serveur chargé, et réduisez d'abord la distance de simulation si vous devez économiser.
Prégénérez votre monde jusqu'à une bordure raisonnable.
Supprimez les plugins et mods inutilisés.
Démarrez le serveur avec des arguments JVM éprouvés plutôt qu'avec ceux par défaut, et réglez le tas un peu en dessous de la limite de l'offre pour laisser de la place au système et au panel.
Programmez des redémarrages si un plugin ou un mod est connu pour ses fuites de mémoire, le temps de trouver une solution.

Choisir son offre

Prenez votre estimation, ajoutez une marge pour la croissance et choisissez la taille d'offre standard la plus proche. Accordez ensuite la même attention au processeur : une offre bien dimensionnée en RAM sur un processeur partagé et surchargé laguera quand même. Le guide comment choisir son hébergement Minecraft couvre les autres critères, et le comparateur permet de filtrer les offres par RAM et par localisation.