AEM Thread-Dump-Analyse
Befolgen Sie die in diesem Artikel beschriebenen Schritte und Best Practices, um AEM-Java-Thread-Dumps mithilfe des Tools IBM Thread Analyzer erfolgreich zu analysieren.
Beschreibung
Umgebung
Adobe Experience Manager
Problem
Wie analysiere ich AEM-Java-Thread-Dumps mit dem Tool IBM Thread Analyzer?
Auflösung
-
Laden Sie IBM Thread Analyzer herunter und installieren Sie es (nennen wir es kurz IBM TDA).
-
Erfassen Sie Thread-Dumps von einer AEM-Instanz, die Performance-Probleme aufweist.
-
Öffnen Sie die Thread-Dumps in IBM TDA.
-
Um die Details eines Thread-Speicherauszugs anzuzeigen, wählen Sie die Datei in der Liste aus und klicken Sie dann auf die Schaltfläche Thread-Detail.
-
Sortieren Sie nach Stapeltiefe wobei die längsten Stapel oben liegen.
-
Überprüfen Sie die Threads mit einer Stapeltiefe von 10 Zeilen oder mehr. Das sind in der Regel die Threads, die am interessantesten sind.
Machen Sie sich Notizen zu Threads, die von Interesse sind.
-
Nach Thread sortieren State.
-
Scrollen Sie nach unten zu den ausführbaren Threads. Ausführbare Threads sind diejenigen, die aktiv CPU-Zeit beansprucht haben, als der Thread-Dump erstellt wurde.
Hinweis: Bei der Durchsicht der ausführbaren Threads können Sie Threads ignorieren, die im Abschnitt Threads aufgeführt sind, ignoriert werden können am Ende dieser Seite.
-
Suchen Sie nach ausführbaren Threads, die Teil der Anwendung sind, z. B. Hintergrund-Job-Threads oder Anfrage-Threads (Anfrage-Threads haben Namen wie 127.0.0.1
[
1347028187737]
GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1).Sobald Sie sie gefunden haben, klicken Sie sie einzeln an.
-
Für jeden Anfrage-Thread können Sie feststellen, wann der Browser des Benutzers die Anfrage an den Server gesendet hat, indem Sie den Zeitstempel im Thread-Namen überprüfen.
Im obigen Thread-Namen wird beispielsweise der Zeitstempel (im Millisekunden-Unix-Epochenformat) 1347028187737.
Diese Epochenzahl kann mithilfe von www.epochconverter.com in ein Datum/Zeit- konvertiert werden.
Jeder Thread-Dump zeigt das Datum und die Uhrzeit der Erfassung an.
Sie können den Zeitunterschied zwischen der Anfragezeit und der Thread-Dump-Zeit ermitteln, um zu sehen, wie lange eine Anfrage aktiv war.
-
Scrollen Sie nach Überprüfung der Anfrage-Threads durch die anderen () .
Nachdem Sie einen ausführbaren Thread gefunden haben, der Sie interessiert, sehen Sie sich den mittleren Bereich ( Threads) .
Die dort aufgelisteten Threads warten darauf, dass der ausgewählte Thread einen Monitor freigibt.
Wenn keine wartenden Threads angezeigt werden, kann Ihr ausgewählter Thread weiterhin Besitzer einer Lock sein (Einzelheiten finden Sie unter Implementierungsklassen von Lock).
Mit einem „ReentrantReadWriteLock können Sie beispielsweiseerkennen, welcher Thread der Sperrhalter ist, da Sperren mehrere Monitore intern implementieren.
So müssen Sie sich vielleicht den Quell-Code ansehen, um ihn einem Thread zuzuordnen, der der Sperrhalter sein könnte.
-
Wenn der Thread eine Sperre oder einen Monitor hatte, auf den viele andere Threads gewartet haben, durchsuchen Sie den Rest der Thread-Dumps, um zu sehen, ob Sie andere Threads finden können, die dasselbe Problem haben.
Überprüfen Sie, ob derselbe Thread in den anderen Dumps noch vorhanden ist (in IBM TDA können Sie mehrere Thread-Dumps auswählen und auf die Schaltfläche Threads vergleichen klicken, um den Status eines Threads über mehrere Thread-Dumps hinweg anzuzeigen.
-
Siehe Collector Service im folgenden Screenshot:
-
In dieser Ansicht können Sie den Thread über mehrere Thread-Dumps hinweg sehen, um festzustellen, ob es sich um einen lang laufenden Thread handelt.
Wenn sich der Thread über mehrere Dumps hinweg im Ausführbar-Status befindet und einen langen Stapel hat, bedeutet dies normalerweise, dass es sich um einen lang laufenden Thread handelt.
-
Wenn Sie bei der Betrachtung der ausführbaren Threads nicht viel gefunden haben, gehen Sie zurück zur Thread-Liste, wählen Sie einen Thread-Dump aus und klicken Sie dann auf die Schaltfläche Monitor-Detail im oberen Bereich.
IBM TDA öffnet ein Fenster mit einer Baumstrukturansicht der Threads, die Monitore besitzen, und der wartenden Threads.
Hinweis: Möglicherweise werden einige Thread-Pool-Threads angezeigt, z. B. der Thread-Pool-Monitor der Servlet-Engine. Inaktive Threads können ignoriert werden.
Normalerweise können Sie erkennen, dass ein Thread ein inaktiver Threadpool-Thread ist, da er in den meisten Fällen nur 10 Stapelzeilen oder weniger hat.
Nutzung von CPU auf Thread-Ebene (nur Linux-Plattform):
-
Wenn Sie
top -H -b -n1 -p <javapid>
Ausgabe zusätzlich zu Thread-Dumps erfassen, können Sie die CPU-Auslastung auf Thread-Ebene vergleichen.Öffnen Sie die obere Ausgabe und rufen Sie die Prozess-ID der Threads ab, die die CPU verwenden.
Konvertieren Sie die Prozess-ID in einen Hexadezimalwert und suchen Sie dann in der entsprechenden Thread-Dump-Datei nach diesem Hexadezimalwert.
Die ID sollte mit der nid eines der Threads übereinstimmen.
-
Wenn der übereinstimmende Thread, der die meisten CPU verwendet, der VM- oder ein GC-Thread ist, dann haben Sie möglicherweise ein Speicherproblem.
Wiederholen Sie dieselbe Übung für weitere Thread-Dumps und die Top-Ausgabe. Wenn es ein Muster gibt, bei dem diese Threads CPU Zeit in Anspruch nehmen, haben Sie ein Speicherproblem.
-
Wenn sich das Speicherproblem bestätigt hat, sollten Sie beim nächsten Auftreten des Problems einen Heap-Dump erstellen.
Weitere Informationen Erfassen und Analysieren von HeapDumps finden Sie in diesem Artikel zum Thema „Analysieren von Speicherproblemen“.
Threads, die ignoriert werden können:
- VM-Thread: Dies ist ein VM-System-Thread.
- Threads, die mit „GC task thread“ beginnen: Dies sind Speicherbereinigungs-Threads.
- Threads mit ähnlichen Namen wie
- [ 1347028691218] in code at java.net.PlainSocketImpl.socketAccept(Native Method)
: Dies sind Threads aus dem Thread-Pool der Servlet-Engine, die auf neue Verbindungen warten.