La chiusura di AEM richiede troppo tempo

Problema

Arrestare normalmente il processo AEM java richiede troppo tempo (oltre 10 minuti).

Ambiente

Causa

Possono esserci molte cose che possono causare un rallentamento nella chiusura dell'AEM Quando si interrompe il processo java di AEM, esegue un java hook per chiudere il contenitore Apache Felix OSGi in cui viene eseguito AEM. Durante la chiusura del contenitore OSGi, il sistema interrompe tutti i pacchetti e i componenti OSGi. Come parte di questo processo, vari servizi termineranno le operazioni di scrittura, chiuderanno gli handle dei file aperti e attenderanno che tutte le richieste HTTP attive ricevano risposta.

Le cause più comuni di chiusura lenta sono:

  • Il metodo di disattivazione per un componente OSGi richiede un lungo periodo di esecuzione
  • Ci sono lunghe richieste in corso quando il sistema è spento

Risoluzione

Per risolvere un problema di chiusura lenta, è necessario analizzare i thread dump per scoprire quali thread stiano ritardando la chiusura.

Effettuate le seguenti operazioni:

  1. Prendere i thread dumps seguendo i passi in questo articolo

  2.  Apri il thread dump in un analizzatore di thread dump come TDAhttp://fastthread.io/, o IBM Thread Analyzer

  3.  Cerca nelle thread dumps per richieste thread HTTP nello stadio RUNNABLE con nomi come le seguenti thread:

    • Thread che iniziano con "qtp" nel nome:
    "qtp1926827727-86864" #86864 prio=5 os_prio=0 tid=0x00007f320894a800 nid=0x79f0 runnable [0x00007f31d7109000]
       java.lang.Thread.State: RUNNABLE
    • Oppure thread con IP e riga di richiesta nel nome:
    "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. Oltre alla richiesta di thread, ricerca di thread con il nome "FelixStartLevel". Questo thread gestisce l'avvio e l'arresto di tutti i bundle e componenti di OSGi e fornisce qualche indicazione di ciò che ritarda l'arresto. 

    "FelixStartLevel" #18 daemon prio=5 os_prio=0 tid=0x00007f32ad8c2800 nid=0x6992 runnable [0x00007f32946d7000]
       java.lang.Thread.State: RUNNABLE
  5.  Cercare i pattern nella traccia dello stack del "FelixStartLevel" attraverso le thread dump. Controlla se si è bloccato interrompendo un bundle o disattivando un particolare componente OSGi in molti dei thread dump. È possibile utilizzare uno strumento come "grep" per analizzarlo. Ad esempio, se si osserva che il componente SlingServletResolver OSGi è stato disattivato in più thread dump, si può usare il comando seguente. Il comando sottostante conta quanti thread dump hanno una thread FelixStartLevel con SlingServletResolver nel suo stack trace:

    grep -A 50 FelixStartLevel jstack.* | grep SlingServletResolver | awk '{print $1 }' | uniq | wc -l
  6. Una volta capito che cosa ritarda l'arresto, determina se si tratta di un problema di applicazione o meno.  Se è correlato al codice prodotto AEM, contatta il Servizio Clienti AEM.

    Nota:

    Visualizzare questo articolo per i dettagli sull'analisi del thread dump.

 Adobe

Ottieni supporto in modo più facile e veloce

Nuovo utente?

Adobe MAX 2024

Adobe MAX
La conferenza sulla creatività

14-16 ottobre Miami Beach e online

Adobe MAX

La conferenza sulla creatività

14-16 ottobre Miami Beach e online

Adobe MAX 2024

Adobe MAX
La conferenza sulla creatività

14-16 ottobre Miami Beach e online

Adobe MAX

La conferenza sulla creatività

14-16 ottobre Miami Beach e online