AEM Thread-Dump-Analyse

Laden Sie IBM Thread Analyzer herunter und installieren Sie ihn (nennen wir ihn 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-Dump anzuzeigen, wählen Sie die Datei in der Liste aus und klicken Sie dann auf die Schaltfläche Thread-Detail .

Sortieren Sie nach Stack-Tiefe mit den längsten Stacks oben.

Überprüfen Sie die Threads mit einer Stapeltiefe von 10 Zeilen oder mehr.  Dies sind normalerweise die Threads, die am meisten Interesse zeigen.

Nehmen Sie Hinweise zu interessanten Threads vor.

Sortieren nach Thread State.

Scrollen Sie nach unten zu den Threads Runable . Ausführbare Threads sind diejenigen, die aktiv CPU-Zeit beansprucht haben, als der Thread-Dump erstellt wurde.

Hinweis: Bei der Überprüfung der ausgeführten Threads können Sie die im Abschnitt Threads aufgeführten Threads ignorieren, die am unteren Rand dieser Seite ignoriert werden können.

Suchen Sie ausführbare Threads, die Teil der Anwendung sind, z. B. Hintergrund-Auftrags-Threads oder Anforderungs-Threads (Anforderungs-Threads haben Namen wie diese: 127.0.0.1 [ 134702818737] GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1.3}).

Sobald Sie sie gefunden haben, klicken Sie sie einzeln an.

Für jeden Anforderungs-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 ist beispielsweise der Zeitstempel (im Unix-Epochenformat Millisekunde) 1347028187737.

Wir können diese Epochenzahl mit www.epochconverter.com in ein Datum/eine Uhrzeit konvertieren.

Jeder Thread-Dump zeigt das Datum und die Uhrzeit der Aufnahme an.

Sie können den Zeitunterschied zwischen der Anforderungszeit und der Thread-Dump-Zeit nehmen, um zu sehen, wie lange eine Anforderung aktiv war.

Scrollen Sie nach Überprüfung der Anforderungs-Threads durch die anderen Ausführbaren-Threads.

Sobald Sie einen ausführbaren Thread von Interesse gefunden haben, sehen Sie sich den mittleren Bereich, Warten von Threads, an.

In Threads ist aufgeführt, dass darauf gewartet wird, dass der ausgewählte Thread einen Monitor freigibt.

Wenn keine wartenden Threads angezeigt werden, kann der ausgewählte Thread weiterhin Inhaber einer Sperrung sein (weitere Informationen finden Sie unter Implementieren von Klassen von Sperren ).

Mit einem ReentrantReadWriteLock können Sie beispielsweise nicht erkennen, welcher Thread der Sperrhalter ist, da Sperren mehrere Monitore intern implementieren.

So müssen Sie sich vielleicht den Quellcode ansehen, um ihn mit einem Thread abzugleichen, der der Sperrhalter sein könnte.

Wenn der Thread über eine Sperrung oder einen Monitor verfügte, auf die viele andere Threads warteten, gehen Sie durch den Rest der Thread-Sicherheitskopien, um zu sehen, ob Sie andere Threads finden können, die dasselbe Problem haben.

Überprüfen Sie, ob derselbe Thread noch in den anderen Dumps vorhanden ist (in IBM TDA können Sie mehrere Thread-Sicherheitskopien auswählen und auf die Schaltfläche Threads vergleichen klicken, um den Status eines Threads über mehrere Thread-Sicherheitskopien hinweg anzuzeigen.

Siehe Collector Service im folgenden Screenshot:

In dieser Ansicht können Sie den Thread über mehrere Thread-Sicherheitskopien hinweg sehen, um zu sehen, ob es sich um einen langwierigen Thread handelt.

Wenn sich der Thread in mehreren Dumps im Status Ausführbar befindet und einen langen Stapel hat, bedeutet dies normalerweise, dass es sich um einen langwierigen Thread handelt.

Wenn Sie die Ausführbaren-Threads nicht sehr genau angesehen haben, gehen Sie zurück zur Thread-Liste, wählen Sie einen Thread-Dump aus und klicken Sie dann im oberen Bereich auf die Schaltfläche Detail überwachen .

Wenn Sie zusätzlich zu den Thread-Sicherheitskopien die Ausgabe top -H -b -n1 -p <javapid> erfasst haben, können Sie die CPU-Auslastung auf Thread-Ebene verweisen.

Ö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 passende Thread, der die CPU am meisten verwendet, den VM Thread oder einen GC -Thread ist, liegt möglicherweise ein Speicherproblem vor.

Wiederholen Sie dieselbe Übung für weitere Thread-Dumps und die Top-Ausgabe. Wenn ein Muster dieser Threads CPU-Zeit in Anspruch nimmt, liegt ein Speicherproblem vor.

Wenn Sie das Speicherproblem bestätigt haben, erfassen Sie beim nächsten Auftreten des Problems einen Heap-Dump.

Weitere Informationen zum Erfassen und Analysieren von Heap-Dumps finden Sie in diesem Artikel Speicherprobleme analysieren .