Protokolldateien des Garbage Collector (GC) analysieren, um Arbeitsspeicherprobleme zu überwachen
Es wird empfohlen, die GC-Protokollierung in Produktionsumgebungen zu aktivieren. Weitere Informationen zum Aktivieren der GC-Protokollierung finden Sie im Abschnitt Arbeitsspeicherverwendung eines ThingWorx Servers überwachen. Nachdem die GC-Protokollierung aktiviert wurde, werden alle GC-Aktivitäten auf dem Server protokolliert. Wenn die JVM längere Zeit nicht reagiert, können externe Tools wie VisualVM möglicherweise keine Arbeitsspeicherdaten sammeln. Die JVM kann jedoch die GC-Aktivität ausgeben, was Ihnen hilft, die Ursache für das Arbeitsspeicherproblem zu identifizieren.
GC-Protokolle lesen
Sie können Tools wie GCEasy.io und Chewiebug GC Viewer verwenden, um GC-Protokolle zu analysieren. Sie können GC-Protokolle auch manuell in einem Texteditor auf gängige Probleme analysieren.
Jede Bereinigung des Arbeitsspeichers wird im Allgemeinen ausgegeben, wie im folgenden Beispiel gezeigt.
1. Zeit seit JVM-Start
2. GC-Typ
3. Grund für GC
4. Young Generation von 549 M auf 4 M bereinigt
5. Gesamtgröße Young Generation
6. Gesamtzeit für GC-Abschluss
7. Zugeordneter Heap
8. Gesamtarbeitsspeicher der Lösung, der von Java bereinigt wird
Weitere Informationen zu GC-Operationen finden Sie in der Oracle-Dokumentation.
Ein GC-Analyse-Tool wandelt die Textdarstellung der Bereinigungen in ein leichter lesbares Diagramm um.
Die Analyse der Daten im GC-Protokoll hilft Ihnen, die folgenden Szenarios zu identifizieren, die Arbeitsspeicherprobleme in Ihrer ThingWorx Lösung angeben:
• Extrem lange vollständige GC-Operationen (mehr als 45 Sekunden) – Dies sind nicht erwünschte Stop-the-World-Operationen. Beispielsweise dauert die folgende vollständige GC-Operation 46 Sekunden. Während dieser Zeit werden alle anderen Benutzeraktivitäten angehalten:
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• Vollständige GCs in einer Schleife – Es handelt sich um vollständige GCs, die in einer schnellen Folge auftreten.
Beispielsweise dauert die Auflösung der folgenden vier aufeinander folgenden Garbage Collections fast zwei Minuten:
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• Im folgenden Diagramm sind die roten Dreiecke auf den Diagrammspitzen visuelle Anzeichen dafür, dass vollständige GCs in einer Schleife erfolgen:
• Arbeitsspeicherlecks – Diese treten auf, wenn eine steigende Anzahl von Objekten im Arbeitsspeicher beibehalten wird und der Arbeitsspeicher nicht bereinigt werden kann.
Im folgenden Beispiel nimmt der Arbeitsspeicher trotz der Garbage Collectors stetig zu:
Empfehlung – Wenn kein automatisches Tool vorhanden ist, um die Arbeitsspeicherverwendung zu überwachen und aufzuzeichnen, prüfen Sie die GC-Protokolldateien täglich auf Arbeitsspeicherprobleme. Wenn Arbeitsspeicherprobleme auftreten, sammeln Sie JVM-Thread-Dumps oder Heap-Dumps, um Operationen mit langer Ausführungszeit zu identifizieren. Diese Operationen können die zugrunde liegenden Arbeitsspeicherprobleme in Ihrer ThingWorx Lösung auslösen.