Das Herunterfahren des AEM dauert zu lange

Problem

Die behutsame Beendigung des AEM-Java-Prozesses dauert zu lange (über 10 Minuten).

Umgebung

Ursache

Es kann viele Gründe geben, weshalb das Herunterfahren des AEM lange dauert. Wenn Sie den AEM-Java-Prozess beenden, wird ein Java-Hook ausgeführt, um den Apache Felix OSGi zu beenden, in dem AEM ausgeführt wird. Während des Herunterfahrens des OSGi stoppt das System alle OSGi-Bündel und Komponenten. Im Rahmen dieses Prozesses beenden verschiedene Dienste Schreibvorgänge, schließen die offenen Dateilenker und warten, bis alle aktiven HTTP-Anforderungen auf sie reagieren.
 
Die gängigsten Ursachen für ein langsames Herunterfahren sind:

  • Die Deaktivierungsmethode für eine OSGi-Komponente benötigt lange bis zur Durchführung
  • Es gibt lange Laufanforderungen, wenn das System heruntergefahren wird

Lösung

Zur Behebung eines langsamen Herunterfahrens müssen Sie Thread-Sicherheitskopien analysieren, um festzustellen, welche Threads das Herunterfahren verzögern.

Führen Sie die folgenden Schritte durch:

  1. Erstellen Sie Thread-Sicherheitskopien, indem Sie die Schritte in diesem Artikel befolgen

  2.  Öffnen Sie die Thread-Sicherheitskopien in Analyseprogrammen für Thread-Sicherheitskopien wie TDA, http://fastthread.io/, oder IBM Thread Analyzer

  3.  Durchsuchen Sie die Thread-Sicherheitskopien nach HTTP-Anfrage-Threads in LAUFFÄHIGEM Zustand mit Namen wie die folgenden Threads:

    • Threads die mit „qtp“ beginnen:
    "qtp1926827727-86864" #86864 prio=5 os_prio=0 tid=0x00007f320894a800 nid=0x79f0 runnable [0x00007f31d7109000]
       java.lang.Thread.State: RUNNABLE
    • Oder Threads mit IP-Anforderungslinien im Namen:
    "10.25.10.11 [1457551498445] GET /content/dam/test.jpg HTTP/1.1" #38626 prio=5 os_prio=0 tid=0x00007fe5c854c800 nid=0x7f9c runnable [0x00007fe55f7f3000]
       java.lang.Thread.State: RUNNABLE
  4. Zusätzlichen zu den Anforderungs-Threads, suchen Sie den Thread „FelixStartLevel“. Dieser Thread verarbeitet das Starten und Beenden aller OSGi-Bündel und -Komponenten und gibt einige Hinweise darüber, was das Herunterfahren verzögert. 

    "FelixStartLevel" #18 daemon prio=5 os_prio=0 tid=0x00007f32ad8c2800 nid=0x6992 runnable [0x00007f32946d7000]
       java.lang.Thread.State: RUNNABLE
  5.  Suchen Sie nach Mustern im Stacktrace des „FelixStartLevel“-Threads in den Thread-Sicherheitskopien. Erkennen Sie, ob das Anhalten eines Bündels oder das Deaktivieren einer bestimmten OSGi-Komponente in vielen der Thread-Sicherheitskopien beendet wird. Sie können ein Tool wie „grep“ zur Analyse verwenden. Wenn Sie beispielsweise feststellen, dass die SlingServletResolver OSGi-Komponente in mehreren Thread-Sicherheitskopien deaktiviert wurde, können Sie den folgenden Befehl verwenden. Der folgende Befehl zählt, wie viele Thread-Sicherheitskopien über FelixStartLevel-Threads mit SlingServletResolver in ihrem Stacktrace enthalten:

    grep -A 50 FelixStartLevel jstack.* | grep SlingServletResolver | awk '{print $1 }' | uniq | wc -l
  6. Sobald Sie erkannt haben, was zur Verzögerung des Herunterfahrens führt und Sie feststellen, ob es sich um ein Anwendungsproblem handelt oder nicht.  Wenn es mit einem AEM-Produktcode zusammenhängt, kontaktieren Sie den AEM Kundendienst.

    Hinweis:

    Siehe diesen Artikel für weitere Informationen über die Analyse von Thread-Sicherheitskopien.

 Adobe

Schneller und einfacher Hilfe erhalten

Neuer Benutzer?

Adobe MAX 2024

Adobe MAX
Die Konferenz für Kreative

14. bis 16. Oktober in Miami Beach und online

Adobe MAX

Die Konferenz für Kreative

14. bis 16. Oktober in Miami Beach und online

Adobe MAX 2024

Adobe MAX
Die Konferenz für Kreative

14. bis 16. Oktober in Miami Beach und online

Adobe MAX

Die Konferenz für Kreative

14. bis 16. Oktober in Miami Beach und online