Comment optimiser votre serveur Minecraft et lire les timings
Dans cet article, nous allons apprendre à optimiser au maximum votre serveur Minecraft. Veuillez noter qu'il ne s'agit pas d'un ensemble d'instructions magiques qui supprimeront tout le décalage de votre serveur, mais elles vous aideront.
Cet article est un peu différent des autres, étant donné qu'il sera mis à jour très fréquemment pour en faire le meilleur possible.
Papier et l'une de ses fourchettes
Pocketmine
Noukkit
Socle vanille
Java vanille
Spigot ou sous fourches
Autres
* Si vous utilisez Spigot ou l'une des fourches ci-dessous, vous ne devriez vraiment pas et devriez utiliser des fourches plus optimisées, comme Paper ou Purpur (nous recommandons purpur).
TPS correspond aux ticks par seconde. Il y a 20 ticks minecraft en une seconde irl, donc si votre serveur n'est pas à la traîne, il devrait fonctionner à 20TPS.
MSPT correspond à la durée de chaque tick. Plus ce nombre est inférieur, mieux c'est.
Ping (ms). 99,9% du temps, cela n'est pas lié aux performances de vos serveurs, mais plutôt au délai de localisation entre votre client et le serveur.
La première section nécessitera de modifier les fichiers de configuration de votre serveur qui se trouvent dans le dossier racine de votre serveur.
Pour accéder à ces fichiers si vous ne savez pas comment faire, suivez ce mini guide :
Accédez au panneau, sur witherpanel.com
Sélectionnez le serveur dans la liste.
Accédez au gestionnaire de fichiers sur le côté du panneau.
Ici, vous pouvez voir la liste des fichiers du serveur qui comprend les fichiers de configuration que nous voulons.
Cliquez sur le fichier paper.yml dans le gestionnaire de fichiers, cela ouvrira le fichier dans le navigateur Web.
Sur votre clavier, utilisez le raccourci clavier Ctrl + F pour ouvrir le champ de recherche.
Vous pouvez rechercher le paramètre via ceci, puis cliquer sur "Entrée".
Ensuite, nous changeons use-faster-eigencraft-redstone: false en use-faster-eigencraft-redstone: true.
Enregistrez le fichier avec le bouton Enregistrer.
Vous avez maintenant modifié un paramètre dans le fichier de configuration, pour appliquer ces paramètres, redémarrez votre serveur.
Il existe une liste de paramètres qu'il est recommandé de modifier pour vous apporter le serveur le plus optimisé.
Nous pourrions les parcourir et les lister tous ici, mais il existe une liste parfaitement bonne que les gens ont faite au fil des ans, que nous vous recommandons de modifier les paramètres en conséquence.
Le guide qui combine plein d'autres petits guides est ici : https://github.com/YouHaveTrouble/minecraft-optimization et ici https://www.spigotmc.org/threads/guide-server-optimization%E2%9A%A1 .283181/
Nous vous recommandons de les parcourir tous les deux et d'appliquer leurs modifications à votre serveur.
Si votre serveur doit fonctionner aussi près que possible du comportement vanille (tout en utilisant des fourches Spigot), certains des paramètres qui modifient les fonctionnalités de base du jeu, comme le comportement du conteneur et la génération de mob, vous ne voudrez peut-être pas changer. Cela étant dit, c'est votre serveur, donc vous faites ce que vous voulez faire !
Vous avez suivi ces 2 guides, en modifiant de nombreux paramètres sur votre serveur, mais il a toujours un TPS faible...
Nous allons vous montrer comment déboguer ce qui cause le décalage sur votre serveur.
C'est pour les fourches Paper et supérieures, car Spigot n'a pas cette fonctionnalité mise à jour (Spigot n'a que Timings v1, tandis que Paper/forks ont Timings v2, ce dont nous avons besoin).
Sur votre serveur, exécutez la commande timings on .
Laissez votre serveur fonctionner pendant environ 30 minutes, car le minutage collecte des données pour le rapport.
Après 30 minutes, exécutez la commande "timings paste" et accédez au lien créé dans la console.
C'est là que le plaisir commence, en parcourant les horaires pour voir ce qui cause le décalage.
Pour commencer plus facilement, nous allons jeter un œil à l'onglet PLUGINS, pour voir si l'un de vos plugins provoque un décalage.
Ceci est un exemple de rapport de temps, dans ledit onglet :
Vous pouvez voir dans l'image que le plugin "InventoryRollback" prend plus que la moyenne du tick.
En cliquant sur InventoryRollback :: Combined Total, vous obtiendrez une liste plus détaillée des événements que le plugin gère, ce qui provoque un décalage :
La première étape que nous vous recommandons de suivre est de vérifier s'il existe une version mise à jour du plugin que vous utilisez, qui a plus d'optimisations en place, pour réduire le décalage (comme une mise à jour qui tente d'exécuter les événements des plugins dans async, plutôt que dans le thread CPU du serveur principal).
Par exemple, le plugin "InventoryRollback" a une version plus récente, appelée "InventoryRollbackPlus", qui est une version mise à jour, améliorée et moins lente du plugin. Voir ici.
Si aucune mise à jour de ce type n'existe, ou s'il n'y en a pas une qui améliore l'état du rapport de synchronisation de votre serveur, alors examiner ce que le rapport de synchronisation indique que votre plugin fait pour provoquer un décalage serait la prochaine étape que nous vous recommandons de prendre.
Exemple:
Nous pouvons voir que InventoryRollback a certains événements qui retardent le serveur plus que d'autres, tels que InventoryRollback::Event: m.d.i.l.EventLogs (PlayerQuitEvent) (reportez-vous à la capture d'écran).
Dans la configuration InventoryRollback, nous pouvons voir qu'il existe des options dans la configuration qui contrôlent le moment où il prend une sauvegarde de l'inventaire des joueurs.
Plus précisément, notez "quitter", qui est l'événement le plus décalé lors de la lecture de nos horaires. Nous pouvons désactiver cet événement en définissant la valeur sur "0".
Cela vise à réduire l'impact d'un plugin spécifique sur les ticks de votre serveur.
Suivre ce type de méthode avec d'autres plugins qui causent des problèmes sur vos timings, aidera à réduire la charge sur votre serveur.
Regarder cet onglet peut sembler intimidant au début, mais il peut être décomposé assez facilement.
Le rapport de chronométrage a les numéros du "décalage" codés par couleur (le rouge étant le pire, le blanc étant peu d'impact), cependant, les différentes sections ne le sont pas, j'ai donc codé par couleur la partie principale des chronométrages que nous serons regarder.
Couleurs:
Aqua = Entités
Rose = Monde
Jaune = plugins
En commençant par le haut, nous pouvons voir que le Full Server Tick est le plus impacté par Minecraft::world -doTick, et en développant doTick, nous voyons tickEntities être le top-lagger.
Développer les quelques valeurs suivantes nous amène à ceci :
En cela, nous voyons que les `mooshroom`s prennent beaucoup de la tique. Cela signifie qu'il y a très probablement beaucoup de champignons sur votre serveur.
Cela peut se produire pour plusieurs raisons, telles que :
Les joueurs les utilisant pour les fermes.
Les paramètres d'apparition de monstres de votre serveur sont élevés et permettent aux lots d'apparaître.
Beaucoup de morceaux contenant la foule sont chargés.
Les choses que vous pourriez faire pour réduire l'impact de ces choses énumérées pourraient être des choses telles que :
Introduction d'un coup de pied AFK, afin que les joueurs ne puissent pas garder les morceaux chargés pendant de longues périodes.
Modification des paramètres d'apparition de mob dans bukkit.yml pour réduire le nombre d'apparitions. Vous voudrez peut-être activer per-player-mob-spawns dans paper.yml, qui vise à modifier plus équitablement la répartition des mobs entre les joueurs sur le serveur (cela peut entraîner la création de plus de mobs, selon la façon dont votre serveur est configuré).
Réduction de la distance de rendu pour les morceaux et activation des paramètres no-tick-distance dans paper.yml.
Dans mon exemple de minutage, presque tout le décalage provient du fait que la foule se reproduit en morceaux. Réduire la distance de rendu tout en définissant la no-tick-distance dans paper.yml aiderait le problème des monstres apparaissant dans une zone étendue, car la distance sans tic est comme la distance de rendu (distance de vue), mais les morceaux ne 't tick, donc les foules n'y apparaîtront pas. Dans les horaires, je peux voir beaucoup de monstres en morceaux et de tâches de frai causant la plupart des problèmes de décalage. Réduire le frai et le plafond de la foule aiderait à résoudre ce problème.
Parcourir le rapport de synchronisation comme celui-ci vous aidera à identifier d'où vient le décalage TPS et MSPT et est nécessaire pour que votre serveur fonctionne correctement.
Essayez de ne pas utiliser une quantité excessive de plugins, car ceux-ci peuvent utiliser beaucoup de ressources, surtout s'ils sont mal codés, et soyez raisonnable avec les paramètres de votre serveur.
Pour obtenir de l'aide sur l'optimisation du serveur, n'hésitez pas à envoyer un ping à MrRazamataz # 6614 dans #community-help dans le [serveur WitherHosting Discord] (https://discord.gg/jbmzKhgbhp).
Dernière mise à jour : 13/09/2021 à 21h19 GMT + 1
Cet article est un peu différent des autres, étant donné qu'il sera mis à jour très fréquemment pour en faire le meilleur possible.
Logiciel pour lequel cela s'applique :
Papier et l'une de ses fourchettes
Logiciels auxquels cela ne s'applique pas :
Pocketmine
Noukkit
Socle vanille
Java vanille
Spigot ou sous fourches
Autres
* Si vous utilisez Spigot ou l'une des fourches ci-dessous, vous ne devriez vraiment pas et devriez utiliser des fourches plus optimisées, comme Paper ou Purpur (nous recommandons purpur).
Mots clés:
TPS correspond aux ticks par seconde. Il y a 20 ticks minecraft en une seconde irl, donc si votre serveur n'est pas à la traîne, il devrait fonctionner à 20TPS.
MSPT correspond à la durée de chaque tick. Plus ce nombre est inférieur, mieux c'est.
Ping (ms). 99,9% du temps, cela n'est pas lié aux performances de vos serveurs, mais plutôt au délai de localisation entre votre client et le serveur.
Commencer:
La première section nécessitera de modifier les fichiers de configuration de votre serveur qui se trouvent dans le dossier racine de votre serveur.
Pour accéder à ces fichiers si vous ne savez pas comment faire, suivez ce mini guide :
Accéder aux fichiers de configuration et les modifier :
Accédez au panneau, sur witherpanel.com
Sélectionnez le serveur dans la liste.
Accédez au gestionnaire de fichiers sur le côté du panneau.
Ici, vous pouvez voir la liste des fichiers du serveur qui comprend les fichiers de configuration que nous voulons.
Nous allons essayer de modifier le fichier de configuration appelé paper.yml et nous allons définir use-faster-eigencraft-redstone sur true.
Cliquez sur le fichier paper.yml dans le gestionnaire de fichiers, cela ouvrira le fichier dans le navigateur Web.
Sur votre clavier, utilisez le raccourci clavier Ctrl + F pour ouvrir le champ de recherche.
Vous pouvez rechercher le paramètre via ceci, puis cliquer sur "Entrée".
Ensuite, nous changeons use-faster-eigencraft-redstone: false en use-faster-eigencraft-redstone: true.
Enregistrez le fichier avec le bouton Enregistrer.
Vous avez maintenant modifié un paramètre dans le fichier de configuration, pour appliquer ces paramètres, redémarrez votre serveur.
Réglages
Il existe une liste de paramètres qu'il est recommandé de modifier pour vous apporter le serveur le plus optimisé.
Nous pourrions les parcourir et les lister tous ici, mais il existe une liste parfaitement bonne que les gens ont faite au fil des ans, que nous vous recommandons de modifier les paramètres en conséquence.
Le guide qui combine plein d'autres petits guides est ici : https://github.com/YouHaveTrouble/minecraft-optimization et ici https://www.spigotmc.org/threads/guide-server-optimization%E2%9A%A1 .283181/
Nous vous recommandons de les parcourir tous les deux et d'appliquer leurs modifications à votre serveur.
Si votre serveur doit fonctionner aussi près que possible du comportement vanille (tout en utilisant des fourches Spigot), certains des paramètres qui modifient les fonctionnalités de base du jeu, comme le comportement du conteneur et la génération de mob, vous ne voudrez peut-être pas changer. Cela étant dit, c'est votre serveur, donc vous faites ce que vous voulez faire !
Trouver les causes du décalage :
Vous avez suivi ces 2 guides, en modifiant de nombreux paramètres sur votre serveur, mais il a toujours un TPS faible...
Nous allons vous montrer comment déboguer ce qui cause le décalage sur votre serveur.
C'est pour les fourches Paper et supérieures, car Spigot n'a pas cette fonctionnalité mise à jour (Spigot n'a que Timings v1, tandis que Paper/forks ont Timings v2, ce dont nous avons besoin).
Pas:
Sur votre serveur, exécutez la commande timings on .
Laissez votre serveur fonctionner pendant environ 30 minutes, car le minutage collecte des données pour le rapport.
Après 30 minutes, exécutez la commande "timings paste" et accédez au lien créé dans la console.
C'est là que le plaisir commence, en parcourant les horaires pour voir ce qui cause le décalage.
Procédure pas à pas:
Pour commencer plus facilement, nous allons jeter un œil à l'onglet PLUGINS, pour voir si l'un de vos plugins provoque un décalage.
Ceci est un exemple de rapport de temps, dans ledit onglet :
Vous pouvez voir dans l'image que le plugin "InventoryRollback" prend plus que la moyenne du tick.
En cliquant sur InventoryRollback :: Combined Total, vous obtiendrez une liste plus détaillée des événements que le plugin gère, ce qui provoque un décalage :
La première étape que nous vous recommandons de suivre est de vérifier s'il existe une version mise à jour du plugin que vous utilisez, qui a plus d'optimisations en place, pour réduire le décalage (comme une mise à jour qui tente d'exécuter les événements des plugins dans async, plutôt que dans le thread CPU du serveur principal).
Par exemple, le plugin "InventoryRollback" a une version plus récente, appelée "InventoryRollbackPlus", qui est une version mise à jour, améliorée et moins lente du plugin. Voir ici.
Si aucune mise à jour de ce type n'existe, ou s'il n'y en a pas une qui améliore l'état du rapport de synchronisation de votre serveur, alors examiner ce que le rapport de synchronisation indique que votre plugin fait pour provoquer un décalage serait la prochaine étape que nous vous recommandons de prendre.
Exemple:
Nous pouvons voir que InventoryRollback a certains événements qui retardent le serveur plus que d'autres, tels que InventoryRollback::Event: m.d.i.l.EventLogs (PlayerQuitEvent) (reportez-vous à la capture d'écran).
Dans la configuration InventoryRollback, nous pouvons voir qu'il existe des options dans la configuration qui contrôlent le moment où il prend une sauvegarde de l'inventaire des joueurs.
Plus précisément, notez "quitter", qui est l'événement le plus décalé lors de la lecture de nos horaires. Nous pouvons désactiver cet événement en définissant la valeur sur "0".
Cela vise à réduire l'impact d'un plugin spécifique sur les ticks de votre serveur.
Suivre ce type de méthode avec d'autres plugins qui causent des problèmes sur vos timings, aidera à réduire la charge sur votre serveur.
Passons maintenant à l'onglet TIMINGS.
Regarder cet onglet peut sembler intimidant au début, mais il peut être décomposé assez facilement.
Le rapport de chronométrage a les numéros du "décalage" codés par couleur (le rouge étant le pire, le blanc étant peu d'impact), cependant, les différentes sections ne le sont pas, j'ai donc codé par couleur la partie principale des chronométrages que nous serons regarder.
Couleurs:
Aqua = Entités
Rose = Monde
Jaune = plugins
En commençant par le haut, nous pouvons voir que le Full Server Tick est le plus impacté par Minecraft::world -doTick, et en développant doTick, nous voyons tickEntities être le top-lagger.
Développer les quelques valeurs suivantes nous amène à ceci :
En cela, nous voyons que les `mooshroom`s prennent beaucoup de la tique. Cela signifie qu'il y a très probablement beaucoup de champignons sur votre serveur.
Cela peut se produire pour plusieurs raisons, telles que :
Les joueurs les utilisant pour les fermes.
Les paramètres d'apparition de monstres de votre serveur sont élevés et permettent aux lots d'apparaître.
Beaucoup de morceaux contenant la foule sont chargés.
Les choses que vous pourriez faire pour réduire l'impact de ces choses énumérées pourraient être des choses telles que :
Introduction d'un coup de pied AFK, afin que les joueurs ne puissent pas garder les morceaux chargés pendant de longues périodes.
Modification des paramètres d'apparition de mob dans bukkit.yml pour réduire le nombre d'apparitions. Vous voudrez peut-être activer per-player-mob-spawns dans paper.yml, qui vise à modifier plus équitablement la répartition des mobs entre les joueurs sur le serveur (cela peut entraîner la création de plus de mobs, selon la façon dont votre serveur est configuré).
Réduction de la distance de rendu pour les morceaux et activation des paramètres no-tick-distance dans paper.yml.
Dans mon exemple de minutage, presque tout le décalage provient du fait que la foule se reproduit en morceaux. Réduire la distance de rendu tout en définissant la no-tick-distance dans paper.yml aiderait le problème des monstres apparaissant dans une zone étendue, car la distance sans tic est comme la distance de rendu (distance de vue), mais les morceaux ne 't tick, donc les foules n'y apparaîtront pas. Dans les horaires, je peux voir beaucoup de monstres en morceaux et de tâches de frai causant la plupart des problèmes de décalage. Réduire le frai et le plafond de la foule aiderait à résoudre ce problème.
Parcourir le rapport de synchronisation comme celui-ci vous aidera à identifier d'où vient le décalage TPS et MSPT et est nécessaire pour que votre serveur fonctionne correctement.
Essayez de ne pas utiliser une quantité excessive de plugins, car ceux-ci peuvent utiliser beaucoup de ressources, surtout s'ils sont mal codés, et soyez raisonnable avec les paramètres de votre serveur.
Pour obtenir de l'aide sur l'optimisation du serveur, n'hésitez pas à envoyer un ping à MrRazamataz # 6614 dans #community-help dans le [serveur WitherHosting Discord] (https://discord.gg/jbmzKhgbhp).
Dernière mise à jour : 13/09/2021 à 21h19 GMT + 1
Mis à jour le : 14/06/2022
Merci !