Lag sur un serveur Minecraft : trouvez la cause avant de corriger

Avant de changer le moindre réglage, déterminez lequel de trois lags vous avez : la boucle de ticks du serveur qui prend du retard, le réseau entre les joueurs et le serveur, ou l'ordinateur d'un joueur qui peine à afficher le jeu. Lancez /spark tps pendant votre heure la plus chargée. Si les durées de tick restent sous 50 ms, le serveur suit, et le lag que ressentent vos joueurs vient d'ailleurs.

La plupart des « guides d'optimisation » sautent cette étape et vous remettent une liste de réglages. Certains aident, quelques-uns dégradent le jeu, et aucun ne résout un problème que vous n'avez pas trouvé. Ce guide commence par le diagnostic.

Trois types de lag (tick du serveur, réseau, client)

Petite parenthèse de geek sur les chiffres, parce qu'elle explique pourquoi les TPS mentent. Le serveur vise 20 ticks par seconde, donc chaque tick dispose de 50 ms. Les TPS ne peuvent jamais dépasser 20, ce qui veut dire qu'un serveur qui a besoin de 10 ms par tick et un autre qui en demande 48 affichent tous les deux 20,0 TPS. Le premier pourrait encaisser plusieurs fois sa charge actuelle, le second est à une ferme d'entonnoirs du lag. Le MSPT (millisecondes par tick) montre cette marge : surveillez donc le MSPT, pas les TPS.

Mesurer avant de changer quoi que ce soit

1. Choisissez la bonne heure. Un lag qui survient au pic ne se mesure pas à cinq heures du matin. Les quatre heures les plus chargées de notre réseau sont de 14:00 UTC à 18:00 UTC dans votre fuseau horaire, et la page de statistiques publique de votre fiche montre vos propres heures les plus chargées.
2. Lancez /spark tps. Elle affiche les TPS sur les 5 dernières secondes jusqu'aux 15 dernières minutes, et les durées de tick en minimum, médiane, 95e centile et maximum. Une médiane bien sous 50 ms avec un 95e centile au-dessus indique des pics, pas une surcharge constante. Le /mspt de Paper en donne la version courte.
3. Lancez /spark health. Elle ajoute l'usage du processeur, la mémoire et le disque, pour voir d'un coup d'œil si la machine elle-même manque de quelque chose.
4. Lisez la console. L'avertissement vanilla Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (la console du serveur l'écrit en anglais) signifie que le serveur a pris du retard et a sauté des ticks pour le rattraper. Un par jour, c'est du bruit. Un par minute, c'est un problème.
5. Notez l'état de départ : l'heure, les joueurs en ligne, la médiane et le 95e centile du MSPT, et où se trouvaient les joueurs (une nouvelle zone, une grosse ferme, un événement). Vous comparerez à ces valeurs après chaque changement.

Sur un serveur sans spark, la commande /tick query de vanilla (Java Edition 1.20.3 et suivantes, niveau de permission 3) donne le temps moyen par tick et ses centiles.

Pic 16:00 UTC

0003060912151821

Heures en UTC

Plus forte affluence à 16:00 UTC avec environ 17 845 joueurs, plus calme à 01:00 UTC. L’heure de pointe compte 2,6 fois plus de joueurs que l’heure la plus calme.

Mesuré le 19 oct. 2026, 23:45 UTCComment nous mesurons

Lire un profil spark

Quand les chiffres disent que le serveur est lent, le profileur dit pourquoi. La documentation de PaperMC suggère :

/spark profiler start --timeout 600

Cela échantillonne chaque thread pendant dix minutes et vous donne un lien vers le rapport. Deux variantes aident pour des problèmes précis :

• /spark profiler start --only-ticks-over 100 n'enregistre que les ticks plus lents que 100 ms, ce qui isole les pics de lag courts du bruit de fond normal.
• /spark tickmonitor --threshold-tick 100 affiche une ligne chaque fois qu'un tick dépasse 100 ms, pour rapprocher les pics de ce qui se passait en jeu.

Le profil doit tourner pendant que le lag se produit. Un profil d'un serveur calme à 5 h du matin ne dit rien du lag de 18 h.

Dans le visualiseur, ouvrez le thread du serveur et descendez en suivant le plus gros pourcentage. Vous cherchez la branche où part le temps :

• Le ticking des entités, souvent avec l'IA des mobs ou la recherche de chemin des villageois en dessous, désigne les mobs (section suivante).
• Les entités de bloc (block entities), avec les entonnoirs haut dans la liste, désignent les chaînes d'entonnoirs et les systèmes de stockage.
• Le travail sur les chunks (génération, chargement, sauvegarde) désigne des joueurs qui explorent du terrain neuf.
• Le nom d'un plugin dans l'arbre d'appels, ou haut dans la répartition par plugin du visualiseur, désigne ce plugin. Notez ce qu'il faisait (un gestionnaire d'événement, une tâche planifiée, un appel à la base de données) avant de l'accuser, car le même plugin peut très bien se comporter avec un autre réglage.

Le ramasse-miettes (garbage collection) est aussi enregistré par spark. Des pauses fréquentes de plusieurs centaines de millisecondes indiquent une pression sur la mémoire, que /spark gc montre dans le temps. Faites aussi un profil une fois quand le serveur va bien, pour savoir à quoi ressemble la normale sur votre installation.

Les suspects habituels (entités, génération de chunks, redstone, plugins, ramasse-miettes)

Entités

Les fermes à mobs, les halls d'échange de villageois, les tas d'objets au sol, les systèmes de wagonnets et les décors en porte-armures tickent tous. Sur Paper, /paper entity list affiche les entités qui tickent par type, et un filtre comme /paper entity list minecraft:villager affine la liste pour trouver où elles s'accumulent. /paper mobcaps montre à quel point les limites de mobs sont remplies, et /paper chunkinfo combien de chunks sont chargés et tickent. Les solutions sont des limites, pas des interdictions : un plafond d'entités par chunk, des règles de ferme sur lesquelles vos joueurs s'accordent, et un petit mot à celui qui a construit le hall de 400 villageois.

Génération de chunks

Générer un nouveau chunk est l'une des choses les plus coûteuses qu'un serveur fasse, et des joueurs en élytres peuvent en exiger des dizaines par minute. Prégénérez le monde une fois, avec un plugin comme Chunky (/chunky radius 5000, puis /chunky start), aux heures creuses, et fixez une bordure du monde correspondante avec /worldborder set 10000. La bordure prend un diamètre, le rayon de Chunky en est la moitié : les deux nombres décrivent donc le même carré. Ensuite, explorer ne fait que charger des chunks depuis le disque, ce qui coûte bien moins.

Redstone et entonnoirs

Les horloges redstone rapides et les longues chaînes d'entonnoirs finissent par peser. Paper offre deux leviers dans config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT installe une implémentation plus rapide de la poudre de redstone. hopper.disable-move-event: true allège les entonnoirs, mais casse les plugins qui dépendent de cet événement, comme certains plugins de protection et de filtrage d'entonnoirs : testez donc d'abord. hopper.cooldown-when-full est déjà activé par défaut.

Plugins

Un plugin lourd apparaît par son nom dans le profil. Les cas courants sont les scoreboards, hologrammes ou listes de joueurs qui se reconstruisent à chaque tick, les requêtes à la base de données ou au web faites sur le thread principal, les moteurs de rendu de carte qui parcourent un grand monde, et les vérifications d'anti-cheat sous charge. La solution passe d'abord par la configuration (intervalles de mise à jour, limites de rendu), puis par une mise à jour, puis par un remplacement.

Ramasse-miettes

Si spark montre des pauses de collecte longues ou fréquentes, vérifiez la mémoire avant tout : -Xmx est-il trop petit pour le monde et les plugins, et -Xms a-t-il la même valeur ? Les options recommandées par PaperMC sont une base solide. Plus de mémoire n'aide que si c'est la collecte le problème, et sur un hébergement mutualisé, tout allouer prive le système d'exploitation.

Les correctifs qui marchent

Une fois la cause connue, voici les changements qui paient en général, à peu près dans l'ordre où nous les essaierions :

Le changement de simulation-distance est plus important qu'il n'en a l'air. Autour de chaque joueur, le serveur traite à chaque tick à peu près un carré de chunks : passer de 10 à 6 le réduit d'environ 21 sur 21 chunks à 13 sur 13, soit d'environ 441 chunks à environ 169, alors que les joueurs voient toujours aussi loin que view-distance le permet.

Certains conseils populaires n'aident pas. Les plugins qui effacent tous les objets au sol toutes les quelques minutes traitent un symptôme et agacent les joueurs. Les plugins « d'optimisation » qui promettent plus de TPS sans dire ce qu'ils changent méritent un profil avant et après. Et redémarrer toutes les deux heures cache les problèmes au lieu de les trouver.

Le lag réseau vu de l'extérieur

Un détail surprend beaucoup de propriétaires. Le ping d'état que les listes de serveurs utilisent est traité par les threads réseau du serveur, pas par la boucle de ticks : un serveur peut donc avoir un gros lag en jeu et répondre quand même à notre pinger en quelques millisecondes. Nous ne pouvons pas voir le lag de tick de l'extérieur, et c'est exactement pour cela que spark existe. Derrière Velocity, le pinger ne parle jamais qu'au proxy.

Ce que notre pinger peut voir, c'est le réseau. La page de statistiques publique de votre fiche (/server/your-server/stats) montre trois éléments à lire :

• Le temps de réponse, c'est-à-dire le temps qu'a mis le serveur à répondre à notre pinger, avec sa médiane, sa plage habituelle et un graphique. Le niveau dépend surtout de la distance jusqu'à notre pinger, en Europe de l'Ouest : un serveur aux États-Unis n'y affichera pas 10 ms, sauf si un réseau de protection répond depuis un point de présence proche. Regardez sa forme dans le temps, pas sa valeur.
• Les pics au-dessus de la plage habituelle. Si les réponses montent bien au-dessus de la plage habituelle seulement à vos heures chargées, la machine ou sa liaison réseau est saturée à ces moments. Si la plage est large à toute heure, soupçonnez le trajet ou le réseau de l'hébergeur.
• Le journal des pannes. Les courtes interruptions sont des redémarrages ou des plantages. Les longues méritent un coup d'œil à la page d'état de votre hébergeur et à vos rapports de plantage.

Côté joueurs, demandez aux joueurs touchés un traceroute vers votre adresse (tracert sous Windows, traceroute sous macOS et Linux) et leur région. Si tous les joueurs d'un même pays ont du lag et personne d'autre, c'est le trajet, et déménager ou ajouter un réseau de protection avec un point de présence proche peut aider plus que n'importe quel réglage. Les joueurs qui n'arrivent pas du tout à se connecter ont d'autres problèmes, que notre guide des erreurs de connexion traite.

Quand redémarrer, et quand ne pas le faire

Les redémarrages ne sont pas gratuits. Tous les joueurs connectés sont expulsés, et un joueur éjecté en plein combat un dimanche soir s'en souvient. Nos données de pannes montrent comment les propriétaires les planifient réellement.

Sur les 30 jours jusqu'au 16 octobre 2026, 90 fiches de notre liste étaient jouables au moins 90 % du temps. 58 d'entre elles ont eu au moins une panne, que nous comptons à partir de trois pings d'affilée sans réponse jouable, et ensemble elles en ont eu 515. Mesurée du premier ping manqué au dernier, la moitié des pannes étaient terminées en moins de cinq minutes, et les 10 % les plus longues ont dépassé deux heures. 375 des 515 (73 %) ont duré 15 minutes ou moins, la durée d'un redémarrage, ou d'un plantage suivi d'une relance.

Quand ces pannes courtes ont-elles commencé ? Une heure se détache : 4 h UTC, avec 39 des 375, la signature de redémarrages nocturnes planifiés. En dehors de cette heure, elles se répartissent assez régulièrement sur la journée. 64 des 375 (17 %) ont commencé entre 14 h et 18 h UTC, les quatre heures les plus chargées de notre liste, soit à peu près la part attendue si les heures de redémarrage étaient choisies au hasard.

19 %Pannes courtes commencées pendant les quatre heures les plus chargées du réseau, 30 derniers jours

Mesuré le 19 oct. 2026, 22:52 UTCComment nous mesurons

En direct, sur les 30 derniers jours : 473 pannes sur 83 fiches à 90 % ou plus, avec une médiane de 5 minutes minutes, dont 70 % de 15 minutes ou moins. L'heure de début la plus fréquente pour les pannes courtes est 04:00 UTC dans votre fuseau horaire, et l'heure la plus calme du réseau est 01:00 UTC.

Ce qu'il faut en retenir :

1. Redémarrez à votre propre heure creuse, pas à une heure ronde. La carte thermique de votre page de statistiques la montre, et quand les serveurs sont les plus fréquentés montre comment elle varie selon la région. Si vos joueurs sont répartis sur plusieurs fuseaux horaires, choisissez le point le plus bas de votre courbe, pas minuit.
2. Annoncez-le avec un compte à rebours dans le tchat, et restez bref.
3. Redémarrez pour une raison. Des mises à jour, une fuite de mémoire que vous suivez, un changement de configuration qui l'exige. Un redémarrage quotidien qui ne corrige rien coûte quand même une expulsion par jour.
4. Cherchez la fuite au lieu de la cacher. Si la mémoire grimpe jusqu'au redémarrage, /spark heapsummary montre ce qui la remplit.

Les redémarrages ne corrigent pas le lag de tick. Une ferme qui coûte 30 ms par tick coûte toujours 30 ms par tick cinq minutes après un redémarrage. Notre étude sur l'uptime donne les chiffres complets de pannes sur toute la liste.

Quand améliorer le matériel

Passez au matériel supérieur quand le profil le dit. Les signes :

• Le MSPT au pic reste au-dessus d'environ 40 ms une fois les suspects ci-dessus traités.
• Le profil montre un temps réparti sur le travail vanilla ordinaire (entités, chunks, mises à jour de blocs) sans coupable unique restant.
• Sur un VPS, top montre le CPU steal (la valeur st) qui grimpe aux heures chargées, ce qui veut dire que vos voisins utilisent des cœurs que vous payez.

Achetez alors d'abord de la vitesse monocœur, car la boucle de ticks tourne sur un seul cœur. Plus de RAM ne règle que les problèmes de mémoire. Au-delà, la réponse est de répartir la charge : plusieurs serveurs derrière un proxy Velocity, ou Folia pour un très grand monde, deux options traitées dans notre guide des logiciels de serveur. Choisir un hébergeur contient les questions à poser avant de payer la nouvelle machine.