Vous vous déplacez dans votre monde Minecraft et autour de vous les chunks ne se chargent pas. Des plaines vides, des blocs manquants, ou vous tombez carrément à travers le monde parce que le sol n'est pas encore là. Des chunks qui chargent lentement ne sont pas seulement irritants ; ils rendent le jeu injuste si vous entrez dans une zone en PvP que votre client n'a pas encore chargée. Dans cet article, j'explique pourquoi les chunks chargent lentement et comment y remédier.
Que sont les chunks et pourquoi sont-ils importants ?
Un chunk est une colonne de 16x16 blocs, du bedrock à la limite de construction. Le monde Minecraft est divisé en milliers de chunks, mais le serveur ne charge que les chunks autour de chaque joueur. Lorsqu'un joueur se déplace, de nouveaux chunks doivent être chargés (depuis le disque ou générés s'ils sont nouveaux) et envoyés au client. Si ce processus est trop lent, le joueur voit des zones vides ou subit du rubber-banding.
Causes du chargement lent des chunks
- Support de stockage lent : les chunks sont lus depuis le disque. Un HDD est nettement plus lent qu'un SSD, et un SSD est plus lent que le NVMe. Lors du chargement de dizaines de chunks par seconde, le type de stockage fait une grande différence.
- Pas assez de RAM pour le cache : le serveur garde les chunks récemment chargés en mémoire. S'il n'y a pas assez de RAM, les chunks doivent constamment être relus depuis le disque au lieu de provenir du cache.
- Génération de monde lourde par des mods ou datapacks : si un joueur entre dans une zone qui n'existe pas encore, le serveur doit générer ces chunks. Les mods comme Terralith ou les datapacks qui modifient la génération du monde rendent ce processus bien plus lourd que la normale.
- Trop d'entités dans les chunks : un chunk rempli de centaines de mobs, cadres d'objets ou porte-armures prend plus de temps à charger et à sérialiser. Les chunks riches en entités sont nettement plus lents.
- Chargement de chunks single-thread : sur Vanilla et Spigot, le chargement des chunks est géré sur le thread principal. Cela signifie que le chargement des chunks entre en concurrence avec tout ce que le serveur fait d'autre (IA des mobs, redstone, traitement des ticks). Paper et Purpur disposent du chargement asynchrone des chunks, ce qui résout largement ce problème.
- View distance trop élevée : une view distance de 16 charge 1089 chunks par joueur (33x33). À 10, ce sont 441 (21x21). C'est plus de la moitié en moins. Avec plusieurs joueurs, cela s'accumule rapidement.
Solutions
1. Utilisez Paper ou Purpur
Le chargement asynchrone des chunks de Paper est la plus grande amélioration que vous puissiez apporter. Il déplace le chargement des chunks du thread principal vers des threads séparés, de sorte que le chargement des chunks n'entre plus en concurrence avec le game-tick. Purpur va encore plus loin avec des optimisations supplémentaires. Si vous tournez encore sur Spigot ou Vanilla, passer à Paper est la première et la plus importante étape.
2. Réduisez la view distance
Définissez view-distance dans server.properties à 8 ou 10. C'est la distance de rendu côté serveur. Les joueurs peuvent configurer leur distance de rendu côté client plus haute ; le serveur n'envoie alors pas de chunks au-delà de sa propre limite. Pour la plupart des serveurs, 8 à 10 est un bon compromis entre visibilité et performances.
3. Prégénérez votre monde
Utilisez le plugin Chunky pour prégénérer votre monde. Cela évite que le serveur doive générer des chunks à la volée lorsque les joueurs explorent de nouvelles zones. Générez une zone qui correspond à votre bordure de monde (par exemple 10 000 blocs dans chaque direction). Cela prend du temps une seule fois, mais ensuite chaque chunk se charge directement depuis le disque au lieu d'être calculé.
4. Limitez les entités
Configurez les limites de mobs via bukkit.yml ou la configuration de Paper. Les valeurs par défaut sont souvent trop élevées pour les serveurs avec beaucoup de joueurs. Réduisez monster-spawns, animal-spawns et water-animal-spawns. Nettoyez les zones riches en entités avec WorldEdit ou manuellement. Envisagez un plugin qui supprime automatiquement les objets au sol après une minute.
5. Utilisez le stockage NVMe
Les disques NVMe sont 5 à 10 fois plus rapides que les SSD SATA pour les lectures et écritures aléatoires. Le chargement de chunks est exactement ce type de charge de travail : beaucoup de petits fichiers lus rapidement les uns après les autres. Si votre hébergeur propose du NVMe, la mise à niveau en vaut la peine. HostValues utilise le stockage NVMe sur tous les plans.
6. Allouez plus de RAM
Plus de RAM signifie plus de chunks en cache. Configurez le flag -Xmx à au moins 4 Go pour un serveur avec mods, ou 6 à 8 Go pour les gros modpacks. N'utilisez pas plus que ce que votre plan autorise ; le système d'exploitation a aussi besoin de mémoire.
7. Optimisez le garbage collection
Les Aikar JVM flags améliorent la façon dont Java nettoie la mémoire. Le garbage collection Java standard peut causer des micro-pauses (« lag spikes ») pendant lesquelles le chargement des chunks s'arrête aussi momentanément. Les Aikar flags configurent le garbage collector G1 pour effectuer le nettoyage en cycles plus petits et plus fréquents. Ajoutez-les à votre ligne de commande de démarrage pour un chargement de chunks nettement plus fluide.
Vous voulez des chunks qui chargent ultra-rapidement ? L'hébergement Minecraft HostValues tourne sur du stockage NVMe avec des CPU rapides, pour que les chunks se chargent avant même que vous ne les remarquiez.
Dois-je prégénérer le monde entier ?
Pas le monde entier, mais bien la zone où vos joueurs seront activement. Définissez une bordure de monde et prégénérez tout à l'intérieur. C'est le plus efficace avec les modpacks à génération de monde lourde (Terralith, BOP). Pour un serveur vanilla, c'est moins nécessaire, mais cela aide quand même lors de la première exploration. La prégénération elle-même prend quelques heures à une journée, selon la taille.
Quelle est la différence entre view distance et simulation distance ?
La view distance détermine combien de chunks le serveur envoie au client pour le rendu. La simulation distance détermine dans combien de chunks le serveur fait spawner des mobs, fait fonctionner la redstone et fait pousser les cultures. Vous pouvez mettre la simulation distance plus basse que la view distance : le joueur voit alors loin, mais seuls les chunks proches sont « actifs ». Cela économise du CPU sans limiter la vue. Dans server.properties, vous configurez les deux séparément.
Plus de RAM aide-t-il pour le chargement des chunks ?
Oui, mais ce n'est pas tout. Plus de RAM aide parce que le serveur peut mettre en cache plus de chunks en mémoire, de sorte qu'ils n'ont pas besoin d'être constamment relus depuis le disque. Mais si votre support de stockage est lent, la RAM n'aide que pour les chunks déjà chargés une fois. Et si le CPU est le goulot d'étranglement (à cause d'une génération de monde lourde), ni plus de RAM ni un stockage plus rapide ne résoudra le problème. Le serveur idéal a un équilibre des trois : CPU rapide, suffisamment de RAM et stockage NVMe.
