Performances et lagVotre forfait peut afficher trois cœurs et un graphique du panel bloqué à trente pour cent — et le jeu peut quand même bégayer. Ce n'est pas une contradiction. C'est ce qui arrive quand le travail qui compte est confiné à exactement un de ces cœurs, et le graphique ne fait jamais que raconter la moyenne.
Pourquoi le tick du monde ne peut pas simplement se répartir entre les cœurs
Chaque tick, le serveur doit répondre à des questions comme : cette flèche a-t-elle touché ce joueur, dans quel ordre ces deux pistons ont-ils tiré, cette mise à jour de redstone arrive-t-elle avant ou après celle-là. Ces réponses dépendent d'une vue unique et cohérente du monde à cet instant précis — deux fils mettant à jour le même chunk en même temps produiraient des résultats qui dépendraient du minutage plutôt que des règles du jeu, ce qui est la définition d'un bug que les joueurs finiraient par remarquer sous forme d'objets dupliqués ou tombant à travers des blocs qui étaient là un instant plus tôt.
Rendre multithread, en sécurité, un monde partagé et sans cesse modifié est l'un des problèmes les plus difficiles de la conception de moteurs, et Mojang ne l'a pas résolu pour la boucle centrale du jeu : entités, physique et redstone tiquent encore sur un seul fil. C'est ce fil que mesure un rapport /spark profiler quand il désigne « le fil principal », et c'est la ressource que tout autre réglage de votre serveur cherche finalement à protéger.
Bien lire le chiffre de CPU du panel
| Le panel affiche | Le forfait a | Ce que cela signifie réellement |
|---|---|---|
| 33 % | 3 vCores | Un cœur est totalement saturé. Les deux autres sont presque au repos. |
| 100 % | 3 vCores | Soit tous les cœurs sont occupés — génération de chunks, fils d'extensions — soit la lecture d'un seul cœur est rapportée comme si c'était toute l'allocation. |
| 12 % | 8 vCores | Un cœur saturé sur huit. Le serveur peut être à sa limite absolue pendant que ce chiffre paraît calme. |
Un forfait avec plus de vCores donne au travail asynchrone — génération de chunks, certaines sauvegardes du monde, tâches d'extensions en arrière-plan — plus de marge pour tourner sans concurrencer le fil principal. Il ne donne pas au fil principal lui-même plus de vitesse, parce qu'il n'y en a qu'un et qu'il ne peut pas être divisé. Si le temps de tick est le goulot, ce qui compte est la vitesse d'horloge d'un seul cœur et le peu de travail que vous demandez à ce fil unique — pas le nombre de cœurs.
Ce qui relève vraiment le plafond
- Sortez un rapport
/spark profilerpendant le lag, pas aprèsIl montre exactement quelle extension, quel type d'entité ou quelle zone du monde consomme le temps du fil principal. Le deviner avec le seul graphique du panel ne peut pas faire cela.
- Coupez ce que le profileur désigne
Moins d'entités dans la zone chaude, une extension remplacée, une distance d'affichage ou de simulation plus petite — ce que le rapport pointe spécifiquement.
- Passez à un logiciel de la famille Paper si ce n'est pas déjà fait
Il déporte du vrai travail — chargement de chunks, une partie de l'éclairage et du pathfinding — hors du fil principal dans les limites que le comportement vanilla permet, ce qui est le plus gros levier disponible avant de toucher à autre chose.
Dix millisecondes de code d'extension mal écrit tournant à chaque tick représentent un cinquième de tout le budget de 50 millisecondes que le serveur a pour finir un tick, peu importe le nombre de cœurs ou la mémoire inutilisée. Un goulot mono-fil n'a aucun moyen d'emprunter ailleurs.