Pourquoi le CPU est souvent plus important que la RAM sur Minecraft

Un serveur Minecraft qui lag déclenche presque toujours le même réflexe : ajouter de la RAM. C’est l’argument le plus visible sur les grilles tarifaires, le plus simple à comprendre, et pourtant c’est rarement ce qui manque. Dans l’immense majorité des cas, ce qui limite un serveur Minecraft n’est pas la quantité de mémoire disponible, mais la vitesse à laquelle un seul cœur de processeur enchaîne les calculs.

La page Minecraft du site MineStrator le dit sans détour : « La RAM assure la stabilité, mais c’est surtout la fréquence du processeur qui détermine la fluidité. Au-delà de 6 Go, ajouter de la RAM ne réduit plus le lag. » Ce guide explique pourquoi, ce que le processeur calcule à chaque instant, comment reconnaître un serveur qui manque de CPU plutôt que de mémoire, et sur quels critères choisir une offre quand la fluidité est la priorité.

Qu’est-ce qu’un tick, un TPS et un MSPT ?

Un tick est un tour complet de la boucle de jeu du serveur : à chaque tick, Minecraft met à jour tout ce qui existe dans le monde, puis recommence. Le serveur vise 20 ticks par seconde, soit un tick toutes les 50 millisecondes, et c’est cette cadence qui donne au jeu son rythme normal.

TPS (ticks par seconde) : le nombre de ticks que le serveur réussit réellement à produire chaque seconde. À 20 TPS, tout est à l’heure ; à 15 TPS, chaque action du jeu prend 33 % de temps en plus que prévu.

MSPT (millisecondes par tick) : le temps que le serveur met réellement à calculer un tick. Tant que le MSPT reste sous 50 ms, le serveur finit son travail en avance et attend le tick suivant. Dès qu’il dépasse 50 ms, le tick suivant démarre en retard, et les TPS chutent mécaniquement. Le MSPT est l’indicateur le plus précis des deux : un serveur à 20 TPS avec un MSPT de 48 ms est à la limite de la rupture, alors que les TPS affichent encore un score parfait.

Pour la mécanique complète des ticks, le message « Can’t keep up! » et le comportement du watchdog, le guide dédié Comment fonctionnent ticks, TPS et main thread sur Minecraft détaille chaque étape.

Pourquoi Minecraft dépend-il d’un seul cœur ?

Parce que la simulation du monde tourne sur un seul fil d’exécution, le main thread (thread principal), et que les ticks ne peuvent pas s’exécuter en parallèle : le tick 2 ne peut pas commencer tant que le tick 1 n’est pas terminé. Un processeur à 16 cœurs n’accélère donc pas cette boucle : seul le cœur qui exécute le main thread compte, et ce qui compte pour lui, c’est sa performance par cœur, c’est-à-dire sa fréquence et le nombre d’instructions qu’il traite par cycle.

Ce qui passe par le main thread à chaque tick : les paquets reçus des joueurs (déplacements, blocs, attaques), la position de chaque entité, l’intelligence artificielle et le pathfinding des mobs, les mises à jour de blocs et la redstone, les blocs à entité (coffres, fours, entonnoirs), les ticks aléatoires (pousse des cultures, fonte de la glace), puis l’envoi des mises à jour aux joueurs. Les plugins Paper et Spigot s’exécutent sur ce même fil : chaque écouteur d’événement est du temps pris sur les 50 ms du tick.

Tout n’est pas mono-thread pour autant : la génération et le chargement des chunks tournent sur des threads dédiés (Paper en alloue par défaut jusqu’à la moitié des cœurs physiques), les accès disque et le réseau sont gérés à part. Mais une fois un chunk généré, tout ce qui vit dedans est simulé sur le main thread, tick après tick.

💬 Bon à savoir : c’est pour cette raison qu’un processeur de bureau récent, à fréquence élevée, fait souvent mieux sur Minecraft qu’un processeur de serveur à 32 cœurs cadencé plus bas. Sur ce jeu, la vitesse d’un cœur bat le nombre de cœurs.

Ce que la RAM fait vraiment sur un serveur Minecraft

La RAM ne calcule rien : elle stocke. Elle garde en mémoire les chunks chargés, les entités, le contenu des coffres, les données des joueurs et celles des plugins ou des mods, pour que le serveur n’ait pas à tout relire sur le disque à chaque tick. Elle fonctionne comme un seuil : en dessous du besoin réel, le serveur s’étouffe et finit par planter en OutOfMemoryError ; au-dessus, il n’en tire aucun gain de vitesse.

Entre les deux, il y a le garbage collector de Java, qui recycle en permanence la mémoire libérée. Quand la RAM allouée est trop juste, ce recyclage tourne en boucle et bloque le main thread quelques millisecondes à chaque passage : là, et seulement là, ajouter de la RAM améliore les TPS. Quand elle est déjà suffisante, la documentation Paper sur les Aikar's Flags est explicite : plus de mémoire n'apporte pas de meilleures performances au-delà d'un certain point, et surdimensionner ne fait, selon ses termes, que gaspiller de l'argent pour un retour minimal. Cette même page recommande au moins 6 à 10 Go d'allocation JVM et juge inutile d'aller bien au-delà, ce qui rejoint le seuil de 6 Go de la page Minecraft.

Les besoins réels par type de serveur et par nombre de joueurs sont détaillés dans le guide Combien de RAM pour un serveur Minecraft en 2026 : 4 Go couvrent une dizaine de joueurs en Paper, seuls les gros modpacks justifient 12 à 16 Go.

Pourquoi ajouter de la RAM ne règle pas le lag ?

Parce que le lag de gameplay est presque toujours un problème de temps de calcul, pas de place en mémoire. Quand un tick met 80 ms au lieu de 50, le serveur n’a pas manqué de mémoire : il a manqué de temps processeur, et 4 Go de plus ne raccourcissent aucun calcul.

C’est le sens du seuil de 6 Go donné par la page Minecraft du site : au-delà, la RAM cesse d’être le facteur limitant sur un serveur classique, et la fluidité ne dépend plus que du processeur. Le tableau compare l’effet réel des deux leviers sur les symptômes courants.

🚨 Important : un serveur peut afficher 20 TPS et 60 % de RAM libre tout en étant au bord de la rupture. Le seul chiffre qui révèle la marge réelle est le MSPT, tick par tick.

Chunks, entités, redstone : ce qui sature réellement le processeur

Trois familles de charge remplissent les 50 ms d’un tick, et aucune ne se résout avec de la mémoire.

Les chunks simulés. Avec la distance de simulation par défaut (10), un seul joueur fait ticker jusqu'à 441 chunks autour de lui, et chacun reçoit ses ticks aléatoires (3 blocs par sous-chunk et par tick en Java Edition) et ses mises à jour de blocs. La distance de vue, elle aussi à 10 par défaut, charge la même surface, mais c'est bien la simulation qui coûte du temps de calcul. Dix joueurs dispersés, c'est dix zones entières à simuler, sur un seul cœur.

Les entités. Chaque mob recalcule à chaque tick sa position, ses collisions, sa cible et son chemin. Une ferme qui entasse 200 créatures dans un couloir, un enclos de 80 villageois qui cherchent chacun leur lit, ou des centaines d’objets au sol après une explosion coûtent bien plus cher qu’un joueur supplémentaire.

La redstone et les blocs à entité. Une horloge redstone qui tourne en continu génère des mises à jour de blocs en boucle, jusqu'à vingt fois par seconde pour les plus rapides, même quand personne ne s'en sert. Les entonnoirs sont un cas d’école : chacun vérifie ses transferts en permanence (un objet toutes les 8 ticks au maximum) et sonde les conteneurs voisins, si bien qu’un système de tri de 300 entonnoirs pèse sur chaque tick même quand rien ne circule. Un plugin qui écoute chaque mouvement de joueur produit le même effet.

Le point commun de ces trois familles : leur coût se mesure en millisecondes de calcul, jamais en gigaoctets. C'est le cas de figure le plus courant : un main thread saturé par des entités, des fermes ou des plugins, avec une mémoire loin d'être pleine. Pour identifier le coupable, le rapport Spark reste l’outil de référence : le guide Comment utiliser Spark pour diagnostiquer les lags explique comment le générer et le lire.

Comment savoir si votre serveur manque de CPU ou de RAM ?

En lisant deux indicateurs : le MSPT pour le processeur, l’usage mémoire réel et les logs pour la RAM. Avec Spark installé, /spark tps affiche les TPS sur plusieurs fenêtres de temps et le MSPT en minimum, médiane, 95e centile et maximum, colorés en vert, orange ou rouge. Une médiane proche de 50 ms ou un 95e centile au-dessus, c’est un serveur qui manque de temps de calcul, pas de mémoire.

Côté mémoire, /spark health résume l'usage de la JVM, du CPU et du disque, et /spark gcmonitor montre la fréquence et la durée des passages du garbage collector. Un serveur qui déclenche plusieurs nettoyages par seconde, ou qui laisse une erreur OutOfMemoryError dans ses logs, manque réellement de RAM. Un serveur dont la mémoire plafonne à 60 % pendant que le MSPT explose n’en manque pas.

Pour dérouler le diagnostic complet, de la vérification de la connexion jusqu’à la lecture du rapport, suivez Pourquoi mon serveur Minecraft lag ? Diagnostic TPS et Spark.

Quel processeur choisir pour un serveur Minecraft ?

Celui qui offre la meilleure performance par cœur, avant celui qui aligne le plus de cœurs. Un serveur Minecraft utilise réellement un cœur pour sa simulation, un ou deux de plus pour la génération des chunks et le réseau, et tire peu parti des suivants : la fréquence et l’architecture du processeur pèsent plus que son nombre de cœurs.

Le second critère, moins visible, est la stabilité de cette performance dans le temps : un cœur rapide sur une machine saturée par d’autres serveurs perd sa vitesse aux pires moments, quand tout le monde joue. Chez MineStrator, chaque serveur dispose d’une capacité CPU garantie, de 2 à 16 cœurs selon l’offre, et les machines sont maintenues sous 70 % de charge : vos performances ne dépendent pas de vos voisins. Sur les offres qui en disposent, FlexCore™ ajoute des cœurs supplémentaires, automatiquement et gratuitement, lors des pics ponctuels (démarrage, changement de carte, regroupement de joueurs), sur la base du 95e centile statistique. Le détail des cœurs dédiés et du FlexCore est affiché sur chaque offre avant l'achat.

Le troisième critère est de savoir sur quoi vous tournez. Le processeur exact est affiché sur chaque offre, avant l’achat : AMD EPYC 7543p avec DDR4 sur les MyBox de 4 à 10 Go, AMD EPYC 9354p Genoa avec DDR5 à partir de 12 Go, et AMD Ryzen 9 9900x overclocké avec DDR5 sur la gamme MyBox Perf, recommandée pour les gros modpacks, les serveurs à forte population et les jeux exigeants en mono-thread. Une MyBox Perf 4 démarre à 11,99 € par mois contre 6,99 € pour une MyBox 4 : à mémoire égale, la différence achète de la vitesse par cœur.

📝 Conseil : si votre serveur affiche un MSPT élevé avec de la mémoire libre, passer de la gamme MyBox à la gamme MyBox Perf, à quantité de RAM identique, agit directement sur le problème. Monter d’un palier de RAM dans la même gamme ne changera rien à vos TPS.

Comment soulager le processeur sans changer d’offre ?

En réduisant le travail demandé à chaque tick, avant de chercher plus de puissance. Trois réglages récupèrent souvent plusieurs millisecondes par tick.

• Passer sur Paper plutôt que sur le serveur vanilla : ticking des entités, pathfinding et gestion des chunks y sont optimisés, à gameplay identique pour la quasi-totalité des serveurs. Le guide de performance des plugins détaille les réglages qui comptent.

• Baisser la distance de simulation (simulation-distance dans server.properties, 10 par défaut) : elle fixe la zone où entités et redstone sont réellement calculées autour de chaque joueur. Passer à 6 divise la zone simulée par plus de deux (169 chunks au lieu de 441), sans toucher à la distance de vue.

• Limiter les fermes et les horloges : plafonner le nombre de mobs par ferme, remplacer les horloges redstone permanentes par des déclencheurs, regrouper les entonnoirs. Ce sont les postes qui reviennent le plus souvent en tête des rapports Spark.

Sur un serveur moddé, les sélections de mods de performance Fabric et NeoForge font le même travail. Ces optimisations repoussent la limite sans la supprimer : passé un certain nombre de joueurs et de systèmes actifs, le seul levier restant est la vitesse du cœur qui porte la simulation.

Questions fréquentes

Combien de cœurs faut-il pour un serveur Minecraft ?

Deux à quatre cœurs suffisent à la grande majorité des serveurs Minecraft, à condition qu’ils soient rapides. La simulation du monde tourne sur un seul cœur (le main thread), la génération des chunks et le réseau en occupent un ou deux de plus. Chez MineStrator, chaque offre affiche ses cœurs garantis (de 2 à 16 selon la taille) et le processeur exact avant l’achat.

Ajouter de la RAM améliore-t-il les TPS d’un serveur Minecraft ?

Non, sauf si le serveur en manquait réellement. Les TPS dépendent du temps de calcul de chaque tick, donc de la vitesse du processeur, pas de la quantité de mémoire. Au-delà de 6 Go sur un serveur classique, ajouter de la RAM ne réduit plus le lag ; seule une RAM trop juste, reconnaissable à un garbage collector qui tourne en boucle ou à une erreur OutOfMemoryError, justifie d’en ajouter.

Qu’est-ce que le MSPT et quelle valeur viser ?

Le MSPT (millisecondes par tick) est le temps que le serveur met à calculer un tick. La cible est 50 ms ou moins, puisque le serveur doit produire 20 ticks par seconde. Un MSPT médian sous 30 ms laisse une marge confortable ; un 95e centile au-dessus de 50 ms signifie que le serveur décroche régulièrement, même si les TPS moyens affichent encore 20. La commande /spark tps donne ces valeurs.

Pourquoi mon serveur lag alors que la RAM n’est pas pleine ?

Parce que le main thread est saturé : trop d’entités, une ferme trop dense, une horloge redstone permanente ou un plugin gourmand remplissent les 50 ms du tick, et la mémoire n’y est pour rien. C’est le cas le plus fréquent en pratique. Un rapport Spark généré pendant le lag montre précisément quel système consomme le temps de calcul, et c’est la première pièce que le support MineStrator demande pour diagnostiquer un serveur.

MyBox ou MyBox Perf pour un serveur Minecraft fluide ?

La gamme MyBox Perf, à quantité de RAM égale, apporte un processeur plus rapide par cœur (AMD Ryzen 9 9900x overclocké, DDR5), ce qui agit directement sur les TPS d’un serveur à forte population ou sous gros modpack. La gamme MyBox (AMD EPYC, dès 6,99 € par mois) suffit pour un serveur entre amis ou une communauté modérée en Paper. Le bon réflexe : lire le MSPT, et changer de gamme plutôt que de palier de RAM si c’est le processeur qui sature.

Conclusion

Sur Minecraft, la fluidité se joue sur un seul cœur, tick après tick, dans une fenêtre de 50 millisecondes. La RAM fixe le seuil en dessous duquel le serveur ne tient pas ; au-dessus, elle n’accélère rien. Quand les TPS chutent avec de la mémoire libre, la réponse est un processeur plus rapide par cœur, ou moins de travail par tick, jamais un palier de RAM.

C’est la logique des offres MineStrator : processeur affiché avant l’achat, capacité CPU garantie par serveur, machines sous 70 % de charge, et une gamme MyBox Perf au Ryzen 9 9900x overclocké pour les serveurs que la vitesse par cœur limite. Pour mesurer la différence sur votre propre monde, l’essai gratuit de 12 h sans carte bancaire se lance sur une MyBox 12 ou une MyBox Perf 12, au choix, et les offres complètes sont sur la page hébergement Minecraft.

Avant de changer d’offre, générez un rapport Spark pendant le lag et lisez votre MSPT : si le main thread est à bout de souffle, vous saurez exactement quoi acheter, et pourquoi.