Votre latence au 99e centile a des pics que le code applicatif n'explique pas. Comment vérifiez-vous si le ramasse-miettes est responsable ?

Activez la journalisation du ramasse-miettes et alignez les horodatages des pauses avec les requêtes lentes. Si les pics correspondent aux pauses, regardez le taux d'allocation, la promotion et la marge du tas avant de toucher la moindre option, puisque la plupart des pauses viennent d'allocations excessives ou d'un tas trop petit. S'ils ne correspondent pas, vérifiez le temps jusqu'au safepoint, puisqu'un long safepoint bloque tous les threads et ressemble exactement à une pause de ramasse-miettes.

Je veux deux chronologies. La journalisation unifiée me donne chaque pause avec sa cause et sa durée, et mes traces me donnent les requêtes lentes, donc la première question est simplement de savoir si ça coïncide. Si oui, je résiste à l'envie de changer des options et je cherche pourquoi. En général le service alloue énormément par requête, du genre construire des listes intermédiaires dans une boucle ou logguer une charge utile sérialisée à chaque appel, donc le correctif est d'allouer moins. Parfois le tas est simplement trop serré et les collectes tournent en continu, ou dans G1 le code alloue de grands tableaux qui deviennent des objets humongous et se comportent mal. Ce n'est qu'après ça que j'envisagerais de passer à un collecteur à faibles pauses, et je le traiterais comme un compromis plutôt qu'un gain gratuit. Si les pauses ne corrèlent pas, je cherche ailleurs : le temps jusqu'au safepoint peut être long même quand la collecte elle-même est courte, donc un thread dans une boucle comptée bloque tout le monde. J'ai aussi poursuivi un cas qui s'est révélé être du throttling CPU du conteneur, où le processus était complètement désordonnancé et où aucun réglage de JVM n'aurait aidé.