Le journal affiche « Can't keep up! Is the server overloaded? » alors qu'il reste 3 Go de RAM libres. Le blocage vient souvent du tick serveur, pas du tas Java. Vous gagnez plus en réduisant la charge par tick qu'en ajoutant de la mémoire que Minecraft ne lit pas.
Diagnostiquer un serveur Minecraft à 12 TPS
Un serveur Minecraft vise 20 TPS. Cela laisse 50 ms pour calculer un tick. Quand le tick monte à 70 ms, le serveur tombe vers 14 TPS. Les coffres répondent en retard. Les mobs avancent par à-coups. La RAM peut rester à 55 %, le problème ne bouge pas : le thread principal attend que le CPU finisse son calcul.
Le premier indice est dans latest.log. Le message exact « Can't keep up! Is the server overloaded? Running 5234ms or 104 ticks behind » ne parle pas de mémoire. Il indique 104 ticks de retard accumulés. À 20 TPS, cela fait un peu plus de 5 secondes de calcul que le serveur n'a pas rattrapé.
Lancez un profilage de 120 secondes pendant le lag réel : téléportation, raid, ferme à mobs, redstone. Pas pendant un serveur vide. Deux minutes suffisent pour repérer un plugin qui prend 35 % du tick ou un monde qui charge 600 chunks.
/spark profiler --timeout 120
Regardez le MSPT moyen, le 95e percentile et le thread « Server thread ». Un MSPT moyen à 38 ms passe encore. Un 95e percentile à 120 ms casse les combats, même si la moyenne paraît propre. Un pic isolé au démarrage, après un backup ou pendant une sauvegarde auto toutes les 6000 ticks, ne se traite pas comme un 80 ms permanent.
Régler view-distance et simulation-distance sans vider la RAM
La distance d'affichage charge des chunks. La distance de simulation les fait vivre. C'est là que le CPU part : entités, liquides, cultures, redstone, villages. Dans server.properties, une valeur recopiée à 10 semble banale. Elle coûte cher dès que 15 joueurs partent dans 15 directions.
| Réglage | Valeur à poser | Effet réel | Seuil à éviter |
|---|---|---|---|
| view-distance | 8 | Le joueur reçoit 289 chunks autour de lui au lieu de 441 à 10. La carte reste lisible, la bande passante baisse. | Au-dessus de 10, le gain visuel ne paie presque jamais le coût avec plus de 20 joueurs. |
| simulation-distance | 6 | Les entités et blocs actifs restent dans un rayon contenu. Les fermes loin du joueur cessent de tourner. | Au-dessus de 8, les farms et villages actifs se multiplient trop vite. |
L'écart arrive vite. À view-distance 10, un joueur force jusqu'à 441 chunks chargés côté serveur. À 8, il descend à 289. Avec 20 joueurs dispersés, le plafond théorique passe de 8820 chunks à 5780. Tous ne sont pas uniques. Le CPU, lui, ne calcule pas une moyenne de tableau : il travaille sur les chunks réellement actifs.
Gardez simulation-distance plus basse que view-distance sur un serveur survie. Une vue à 8 et une simulation à 6 donnent une carte lisible sans laisser tourner une usine à fer située à 150 blocs. À 4, les joueurs sentent que les mobs apparaissent trop près. À 10, vous payez des machines que personne ne regarde.
Choisir le processeur avant d'ajouter 4 Go de RAM
Minecraft garde une vieille limite : beaucoup de travail passe par un thread principal. Paper, Fabric et les versions récentes déplacent certaines tâches, mais le tick du monde, une partie des entités et beaucoup de plugins restent liés à la fréquence et aux performances par coeur. Un processeur avec moins de coeurs mais un meilleur score mono-coeur tient mieux un serveur de 30 joueurs qu'un CPU plus large et plus lent.
Paper 1.21.8 avec Java 21 et 20 joueurs tient souvent dans 4 Go si les plugins restent propres. Le même serveur à 6 Go ne gagne rien si le MSPT reste à 75 ms. La mémoire évite le crash quand elle manque. Elle ne rend pas une ferme à 400 villageois moins lourde à calculer.
| Symptôme | Cause probable | Mesure utile | Ajout de RAM |
|---|---|---|---|
| 12 à 16 TPS, RAM à 60 % | Thread principal saturé | Réduire distance, entités, plugins lourds | Inutile |
| Crash « Java heap space » | Tas trop petit ou fuite mémoire | Monter Xmx, trouver le plugin fautif | Utile, puis contrôle |
| Freeze de 2 secondes toutes les minutes | GC, sauvegarde ou génération de chunks | Lire les pauses, pré-générer, limiter les accès disque | Parfois pire |
L'arbitrage dépend surtout du nombre de mondes et de ce que les joueurs y font. Un lobby de 80 joueurs avec peu d'entités consomme moins de CPU qu'une survie à 25 joueurs avec End, Nether, claims, économie, carte dynamique et 12 fermes chargées. Prévoyez large côté CPU dès que le serveur accepte la construction libre. Calculez la RAM ensuite, selon les mondes, les plugins et les packs.
Lire le GC avant de monter la mémoire maximale
Le garbage collector nettoie la mémoire Java. Quand il passe trop souvent, les joueurs voient des micro-freezes. Quand vous donnez trop de RAM sans raison, le nettoyage peut durer plus longtemps. Un serveur à 10 Go pour 12 joueurs n'est pas plus sain qu'un serveur à 4 Go si le tas monte, redescend et remonte en dents de scie toutes les 30 secondes.
- Vérifiez le plafond Java. Regardez Xms et Xmx dans la ligne de démarrage. Pour une survie Paper 1.21 avec 10 à 25 joueurs, 4 Go à 6 Go couvrent la plupart des cas sans pack lourd.
- Surveillez le tas pendant une vraie session. Le test seul à 14 h ne vaut rien si le raid de 21 h charge 300 entités et trois mondes.
- Lisez les erreurs exactes. « java.lang.OutOfMemoryError: Java heap space » demande une hausse de Xmx ou la suppression d'une fuite. « GC overhead limit exceeded » signale souvent un serveur qui passe son temps à nettoyer au lieu de calculer.
jcmd $PID GC.heap_info
Une occupation qui monte à 90 % puis retombe à 45 % reste normale si les pauses restent sous 100 ms. Une occupation bloquée à 95 % pendant plusieurs minutes annonce un crash. À l'inverse, un Xmx à 12 Go pour 15 joueurs peut transformer une pause rare en gel visible. Montez par paliers de 1 Go. Redescendez si le TPS ne bouge pas et si les pauses augmentent.
Tester les plugins et les farms qui mangent le tick
Un plugin mal placé coûte plus cher que 2 Go de RAM manquants. Une carte dynamique qui rend des tuiles, un plugin de claims qui vérifie chaque piston, un anticheat trop agressif ou un plugin de mobs custom peuvent prendre 10 à 40 % du tick. Le dossier plugins/ rassure à tort : 45 fichiers jar ne font pas 45 petites charges. Un seul jar peut dominer le profil.
Testez par groupes. Coupez d'abord les plugins visuels et secondaires sur une copie : carte web, hologrammes, cosmétiques, quêtes. Gardez permissions, protection et sauvegarde. Si le MSPT passe de 82 ms à 46 ms, vous tenez le bon groupe. Remettez ensuite les plugins un par un. C'est long. C'est moins long qu'un mois de lag attribué à tort à l'hébergeur, à Java ou à la RAM.
Les farms mentent aussi. Une ferme à mobs avec 250 entités, 180 hoppers et des collisions à 24 entités par bloc se voit dans Spark. Les hoppers vérifient leur inventaire, les villageois cherchent des métiers, les golems testent leur chemin. Sur un monde survie, limitez les zones chargées par chunk loaders. Un chunk loader qui garde 9 chunks actifs toute la nuit fait travailler le serveur pour zéro joueur.
Ne corrigez pas tout avec un clear automatique toutes les 5 minutes. Effacer les items au sol réduit parfois 5 ms, mais casse les systèmes de tri et donne une mauvaise habitude aux joueurs. Fixez des règles qui se mesurent : 100 villageois par base, pas de clocks redstone à 1 tick permanentes, farms publiques contrôlées après construction.
Arbitrer une offre Minecraft pour 10, 30 ou 80 joueurs
Choisissez depuis la charge, pas depuis le nombre affiché dans la liste des joueurs connectés. Dix joueurs en survie vanilla avec view-distance à 8 passent dans 3 à 4 Go. Trente joueurs avec Paper, économie, claims, Nether et End demandent plutôt 6 Go et un très bon coeur CPU. Quatre-vingts joueurs sur un lobby sans mobs peuvent demander moins de calcul qu'une survie à 35 joueurs remplie de fermes.
| Serveur | RAM de départ | Point CPU à surveiller | Mauvais signal |
|---|---|---|---|
| Survie 10 joueurs | 3 à 4 Go | Génération de chunks et sauvegardes | MSPT au-dessus de 60 ms pendant l'exploration |
| Survie 30 joueurs | 6 Go | Entités, plugins, distances | TPS sous 18 avec RAM sous 80 % |
| Réseau lobby 80 joueurs | 4 à 8 Go selon plugins | Plugins cosmétiques et paquets réseau | CPU haut sur le thread principal sans mobs |
Chez Starmine, le panel évite de modifier à la main la version Java, la ligne de démarrage et les redémarrages planifiés pendant un diagnostic CPU contre RAM. Vous changez l'offre, vous relancez, puis vous comparez TPS, MSPT et mémoire sur la même scène de jeu.
Ne payez pas 4 Go de plus pour masquer un view-distance à 12. Prenez une offre avec plus de marge CPU quand le profiler montre un tick trop long. Prenez plus de RAM quand le journal montre « Java heap space », quand un pack moddé charge beaucoup de registres, ou quand plusieurs mondes restent chargés en permanence. Les offres se comparent avec vos mesures, pas avec une promesse de slots.
Guides
Pourquoi mon serveur Minecraft lag alors que la RAM n'est pas pleine ?
La RAM libre ne dit pas combien de temps dure un tick. Si le thread principal met 80 ms à calculer un tick, le serveur descend sous 13 TPS même avec 3 Go libres. Regardez le MSPT et le message « Can't keep up! Is the server overloaded? » dans les logs.
Combien de RAM faut-il pour un serveur Minecraft entre amis ?
Pour 5 à 10 joueurs sur Paper récent, 3 à 4 Go suffisent souvent avec view-distance à 8. Ajoutez de la RAM si vous utilisez beaucoup de mods, plusieurs mondes chargés ou si le journal affiche « Java heap space ». Sans ces signes, cherchez plutôt côté CPU, chunks et plugins.
Est-ce qu'un serveur Minecraft utilise plusieurs coeurs CPU ?
Oui, mais le tick principal reste très dépendant d'un coeur rapide. Paper et Java déplacent certaines tâches, comme le réseau ou des opérations asynchrones, mais les entités, plugins et blocs actifs reviennent souvent au thread principal. Le score mono-coeur compte donc beaucoup.
Baisser la distance de vue va-t-il frustrer les joueurs ?
À view-distance 8, la plupart des joueurs gardent une vision confortable en survie. À 6, certains le sentent en montagne ou en elytra. Gardez view-distance à 8 et simulation-distance à 6 pour réduire la charge sans rendre le monde trop court.