Analizza processi lenti e bloccati

DOMANDE FREQUENTI

Quali sono le situazioni tipiche che causano un elevato consumo di CPU?

Alcune attività di manutenzione possono causare un maggiore utilizzo della CPU rispetto al solito: compattazione del tar, raccolta dei rifiuti del datastore, backup online, attivazione ad albero, distribuzione di un aggiornamento di un'applicazione che causa la compressione della cache, ....

Quale può essere la ragione di un consumo di CPU dello 0%?

Una situazione di stallo a livello Java può causare tale situazione. In questo caso, prendi alcune immagini di thread, solleva un biglietto di supporto e riavvia l'istanza AEM.

Sono disponibili suggerimenti per prestazioni tuning?

Sì, all'indirizzo https://helpx.adobe.com/it/experience-manager/kb/performance-tuning-tips.html

Vedi anche la sessione gemma: http://dev.day.com/content/ddc/en/gems/dispatcher-caching---new-features-and-optimizations.html

Soluzioni

Video gem - sessione di analisi dettagliata tecnica

Sessione video gem disponibile su http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html

Adobe Experience Manager 5.6 o successivo e CRX 2.3 o successivo

Utilizza http://localhost:4502/system/console/profiler per almeno alcuni minuti durante il periodo di utilizzo lento o elevato della CPU. L'output aiuta a determinare quali thread JVM stanno consumando la maggior parte dei cicli CPU e i pacchetti e le classi associate.

Fino a CRX 2.2 

Utilizza il semplice strumento di profilazione della CPU incluso in CRX 2.0.x. Per avviarlo, apri il file

http://localhost:7402/crx/diagnostic/prof.jsp

CRX 1.x

Per aiutare ad analizzare il problema, crea alcune immagini di thread intere. Quelle immagini di thread possono poi essere analizzate. Creare immagini di thread intere

Ottieni l'ID del processo

Per ottenere l'id di processo del processo Java, usa

jps -l

Se questo non funziona (percorso non impostato, JDK non installato, o la vecchia versione di Java), usa

ps -el | grep java

Immagini di thread intere

Per analizzare un problema di prestazioni o un processo bloccato, crea circa dieci dump di thread intere con un ritardo di circa un secondo. Se il problema può essere correlato al clustering, crea almeno dieci immagini di thread intere su ogni nodo del cluster. Se possibile, le immagini di thread devono essere create all'incirca nello stesso momento (non è necessario che sia esatto).

Un'immagine di thread intera sta iniziando con queste informazioni come esempio:

2015-07-22 10:26:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04):

"Thread-76273" daemon prio=3 tid=0x111061 nid=0x111061 running [0x111061]
... stack and locked object MUST be present

Se l'immagine du thread non ha l'aspetto di cui sopra, allora non è possibile effettuare indagini adeguate.

Puoi usare lo "strumento" fornito nella condivisione del pacchetto come descritto nella pagina. Fornisce uno strumento Immagini di thread che ti permette di creare immagini di thread multiple, che viene scaricato nel formato precedente.

In alternativa, se installato, utilizza jstack. Questo comando stampa le immagini di thread nel sistema:

jstack <pid>

Questo comando aggiunge un'immagine di thread completa ad un file:

jstack <pid> >> threadDumpNode1.txt

Su alcuni sistemi potresti dover utilizzare utilizzare: sudo -u aem jstack -J-d64 -l <pid>

Se questo non funziona, usa kill-QUIT. Questo comando stampa le immagini di thread nel file di log:

termina -QUIT <pid>

Se non ci sono immagini di thread nell'output standard dell'ultimo comando, magari aggiungerlo ai parametri java

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log

Nota: Se i passaggi sopra descritti per ottenere le immagini di thread non funzionano nel tuo ambiente, consulta questo articolo.

Controlla l'utilizzo della CPU

Per analizzare il problema, è importante sapere se CRX /CQ è in esecuzione in un ciclo infinito, o se sta semplicemente dormendo. Per scoprirlo, digita

in alto

Questo comando fornisce l'elenco dei processi, ordinati in base all'uso della CPU. Se il processo principale è un "processo Java, e se il PID corrisponde a CRX/CQ, allora il processo viene eseguito a piena velocità.

Se non sei sicuro di come interpretare i risultati, esegui la seguente dichiarazione e quindi includi il file top.txt nella segnalazione del problema:

top -l5 -s5 > top.txt

Controlla il conteggio delle sessioni

In molti casi il problema è il numero di sessioni aperte troppo grande. Ad un certo punto, rallenta l'elaborazione. Per scoprire se questo è il caso, esegui

jps -l (per ottenere l'id di processo del processo Java)

jmap -histo <pid> | grep CRXSession (per ottenere il numero di sessioni aperte)

Infatti se è questo, il problema (il numero è superiore a qualche centinaio di sessioni) allora deve essere analizzato. Forse viene utilizzato un pool sessioni (a seconda della versione di CRX / CQ potrebbe esserci un hot fix per il problema dato), o una cache interna (possibilmente a livello di applicazione) per le sessioni di riferimento. Per analizzare dove sono aperte queste sessioni, vedi la pagina "Analizza sessioni non chiuse".

Non terminare il processo

Il processo CRX non deve mai essere terminato, anche se l'arresto richiede troppo tempo. Se hai bisogno di terminare un processo che non risponde, crea prima un'immagine di thread completa e registra un bug.

Se si interrompe il processo CRX, la prossima volta che lo si avvia il PM Tar può creare file backup_.tar.

Strumenti di supporto

Utilizza lo strumento di Raccolta e Analisi delle immagini di thread per prelevare le immagini di thread da un'istanza di CQ in esecuzione per la risoluzione dei seguenti problemi:
- svolgimento

- blocco conflitto

- deadlock

- altre questioni relative al thread