AEM Thread-Dump-Analyse

Beschreibung

Umgebung

Adobe Experience Manager

Problem

Analysieren AEM Java-Thread-Sicherheitskopien mithilfe von IBM Thread Analyzer Tools und Best Practices.

Auflösung

Befolgen Sie diese Schritte und Best Practices zur Analyse AEM Java-Thread-Sicherheitskopien mithilfe von IBM Thread Analyzer Tool:

1. Herunterladen und installieren des IBM Thread Analyzer (nennen wir es kurz IBM TDA).

2. Erfassen Sie Thread-Dumps von einer AEM-Instanz, die Leistungsprobleme aufweist.

3. Öffnen Sie die Thread-Dumps in IBM TDA.

4. Um die Details eines Thread-Sicherheitskopfes anzuzeigen, wählen Sie die Datei in der Liste aus und klicken Sie dann auf Thread-Detail Schaltfläche.

   

5. Sortieren nach Stapeltiefe mit den längsten Stapeln oben.

   

6. Ü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.

7. Nach Thread sortieren state.

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

   Hinweis: Bei der Überprüfung der Runnable Threads, können Sie die Threads ignorieren, die in der Threads, die ignoriert werden können unten auf dieser Seite.

9. Suchen Sie ausführbare Threads, die Teil der Anwendung sind, z. B. Hintergrund-Auftrags-Threads oder Anfrage-Threads (Anforderungs-Threads haben Namen wie folgt: 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.

10. 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 ist beispielsweise der Zeitstempel (im Format der Unix-Epoche in Millisekunden) 1347028187737.

    Diese Epochenzahl kann mithilfe von www.epochconverter.com.

    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.

11. Scrollen Sie nach Überprüfung der Anforderungs-Threads durch die anderen Runnable Threads.

    Sobald Sie einen aussagekräftigen Thread gefunden haben, sehen Sie sich den mittleren Bereich an. Warten von Threads.

    Die dort aufgeführten 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 Sperre sein (Weitere Informationen finden Sie unter Implementierungsklassen von Sperren).

    Beispiel: mit einer ReentrantReadWriteLock Sie können nicht erkennen, welcher Thread der Sperrhalter ist, da Sperren mehrere Monitore intern implementieren.

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

12. 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 der gleiche Thread noch in den anderen Dumps vorhanden ist (in IBM TDA können Sie mehrere Thread-Sicherheitskopien auswählen und auf die Threads vergleichen -Schaltfläche, um den Status eines Threads über mehrere Thread-Sicherheitskopien hinweg anzuzeigen.

    

13. Siehe Collector Service im folgenden Screenshot:

    

14. 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.

    Grundsätzlich, wenn sich der Thread im Runnable -Status über mehrere Dumps hinweg anzuzeigen und einen langen Stapel hat, bedeutet das normalerweise, dass es sich um einen langwierigen Thread handelt.

15. Wenn Sie nicht viel auf die Runnable Threads, gehen Sie zurück zur Thread-Liste, wählen Sie einen Thread-Dump aus und klicken Sie dann auf Bildschirmdetails im oberen Bereich.

IBM TDA öffnet ein Fenster mit einer Baumstrukturansicht der Threads, die Monitore bistzen, und der wartenden Threads.

Hinweis: Möglicherweise werden einige Thread-Pool-Threads angezeigt, wie der Thread-Poolmonitor der Servlet-Engine, während inaktive Threads ignoriert werden könnten.

Sie können einen inaktiven Thread-Pool-Thread in der Regel daran erkennen, dass er nur 10 Stapelzeilen oder weniger hat.

CPU-Auslastung auf Thread-Ebene (nur Linux-Plattform):

1. Wenn Sie top -H -b -n1 -p javapid -Ausgabe zusätzlich zu Thread-Sicherheitskopien auszugeben, können Sie dann auf 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.

2. Wenn der passende Thread, der die CPU am meisten verwendet, die VM Thread oder GC -Threads ein Problem mit dem Arbeitsspeicher haben.

   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.

3. Wenn sich das Speicherproblem bestätigt hat, sollten Sie beim nächsten Auftreten des Problems einen Heap-Dump erstellen.

   Siehe dies Artikel zur Analyse von Speicherproblemen Weitere Informationen zum Erfassen und Analysieren von Heap-Dumps.

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 - 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.

Ressourcen für Business.Adobe.com