Performances et lagUn profileur dit où est passé le temps du tick. Le rapport intimide parce que c'est un arbre d'appels complet, mais il ne se lit que d'une façon : de haut en bas, en suivant le plus gros pourcentage.
Produire un profil utile
- Profilez pendant que ça va mal
/spark profiler start, puis attendez le problème. Un profil de serveur sain vous dit ce que fait un serveur sain, ce qui n'était pas la question. - Laissez tourner quelques minutes
Trente secondes attrapent un pic ; cinq minutes attrapent un motif. Pour un problème intermittent, plus long vaut mieux.
- Arrêtez et ouvrez le lien
/spark profiler stopvous donne une visionneuse web. Rien à installer pour le lire.
Les trois formes que vous verrez
| Forme | Signifie |
|---|---|
| Une extension haut dans l'arbre | Cette extension. Lisez le nom de la méthode : il dit généralement ce qu'elle faisait. |
| Tick d'entités ou de blocs dominant | Une ferme, une salle de stockage, ou trop de chargé. Pas un problème d'extension. |
| Temps réparti finement sur tout | Vous êtes simplement à la capacité du forfait. C'est le cas où un forfait plus grand est la réponse honnête. |
Si le serveur est sain, quelque chose doit tout de même être le plus gros poste de l'arbre : c'est de l'arithmétique, pas un bug. Les pourcentages comptent quand le TPS est réellement sous 20. Optimiser la première entrée d'un profil pris à 20 TPS, c'est courir après rien.
/spark health avant de profilerIl montre TPS, durée de tick et mémoire sur un écran. Si la durée de tick va bien et que la mémoire est au plafond, votre problème est le ramasse-miettes et un profil du tick ne le montrera pas.
À propos de Timings
Les vieux guides disent d'utiliser /timings. Paper s'en est éloigné au profit de spark, et sur les versions récentes la commande peut ne plus exister. Si un guide commence par Timings, vérifiez sa date avant de suivre le reste.