Deine Latenz im 99. Perzentil hat Spitzen, die der Anwendungscode nicht erklärt. Wie prüfst du, ob Garbage Collection dahintersteckt?

Schalt Garbage-Collection-Logging ein und leg die Zeitstempel der Pausen neben die langsamen Requests. Passen die Spitzen zu den Pausen, schau dir Allokationsrate, Promotion und Heap-Reserve an, bevor du irgendein Flag anfasst, denn die meisten Pausen kommen von zu viel Allokation oder einem zu kleinen Heap. Passen sie nicht, prüf die Time to Safepoint, denn ein langer Safepoint legt jeden Thread lahm und sieht exakt aus wie eine Garbage-Collection-Pause.

Ich will zwei Zeitleisten. Unified Logging gibt mir jede Pause mit Ursache und Dauer, meine Traces geben mir die langsamen Requests, die erste Frage ist also schlicht, ob sich das deckt. Wenn ja, widerstehe ich dem Impuls, Flags zu ändern, und schaue nach dem Warum. Meistens alloziert der Service pro Request enorm, etwa Zwischenlisten in einer Schleife oder das Loggen eines serialisierten Payloads bei jedem Aufruf, der Fix ist also, weniger zu allozieren. Manchmal ist der Heap einfach zu knapp und es wird permanent gesammelt, oder der Code alloziert in G1 große Arrays, die zu Humongous Objects werden und sich schlecht verhalten. Erst danach würde ich einen Low-Pause-Collector erwägen, und ich würde das als Tradeoff behandeln, nicht als Gratisgewinn. Korrelieren die Pausen nicht, schaue ich woanders: die Time to Safepoint kann lang sein, selbst wenn die Sammlung selbst kurz ist, ein Thread in einer Counted Loop hält also alle auf. Ich habe auch mal einen Fall gejagt, der sich als CPU-Throttling im Container herausstellte, wo der Prozess komplett von der CPU genommen wurde und kein JVM-Tuning geholfen hätte.