Come monitorare il TarMK | AEM 6.3 | OAK 1.6

* Le seguenti informazioni sono applicabili per Oak versione 1.6+ e AEM 6.3+.

Problema
A causa della limitata memoria disponibile (off e on heap), quando l'archivio dell'istanza cresce ad un certo livello, le cache si sovraccaricano.
Come risultato, la maggior parte degli archivi accede ai dati letti direttamente dal disco, che è molto più lento, il che si traduce in una cattiva esperienza dell'utente finale.

Sintomi
Nel complesso, l'istanza diventa lenta: il tempo di risposta aumenta e la pulizia delle revisioni online richiede molto più tempo per essere completata, a volte superando la finestra di manutenzione assegnata.
A livello di sistema, si osserva un'attività IO costantemente elevata.

Passaggi

Risoluzione dei problemi

Ci sono diversi punti finali che vengono monitorati per determinare quando il sistema diventa IO bound. 
Nei paragrafi che seguono vengono discussi gli punti finali disponibili e i principali indicatori.

Monitoraggio dei punti finali

Ci sono vari punti finali per il monitoraggio delle metriche relative all'OI in AEM, JVM e OS. 

Insieme forniscono diverse prospettive sul produttività complessiva del sistema ai vari livelli: dalle sessioni JCR al commit nel TarMK fino all'IO su disco del TarMK.

In combinazione con le informazioni raccolte con JVM e gli strumenti a livello di OS, forniscono una grande quantità di informazioni sulla salute del sistema e per aiutare a trovare i colli di bottiglia.

• Ogni sessione espone un'istanza di SessionMBean , che contiene contatori come il numero e la velocità di lettura e scrittura della sessione.
• Il RepositoryStatsMBean espone i punti finali per monitorare il numero di sessioni aperte, il tasso di accesso alla sessione, il carico complessivo di lettura e scrittura in tutte le sessioni, i tempi complessivi di lettura e scrittura in tutte le sessioni e il carico complessivo e i tempi per le query e l'osservazione.
• Il SegmentNodeStoreStatsMBean espone i punti finali per monitorare le conferme: numero e tasso, numero di conferme in coda e tempi di coda.
• Il FileStoreStatsMBean espone i punti di fine che riflettono la quantità di dati scritti su disco, il numero di file tar su disco e l'impronta totale su disco.

Oltre a questi punti finali, ci sono molti strumenti specifici per JVM e sistemi operativi che aiutano ad ottenere ulteriori informazioni su ciò con cui il sistema è impegnato:

• Java Mission Control (jmc) è un potente strumento per raccogliere ogni aspetto delle prestazioni di una JVM in esecuzione. La sua capacità di registrare l'IO per processo Java a volte può essere inestimabile.
• Gli strumenti a riga di comando jstat, jstack e jmap sono utili per entrare rispettivamente nel garbage collector di JVM, nei thread di JVM e nell'heap di JVM.
• Gli strumenti a livello di sistema operativo vmstat e iostat sono utilizzati per esaminare l'utilizzo di IO e CPU a livello di sistema operativo.

Monitoraggio Disco IO

Cosa: il numero di operazioni su disco (lettura/scrittura) per unità di tempo (secondo)

Come: Strumenti a livello di OS (per esempio: vmstat, iostat su UNIX)

Normale: basso livello di lettura del disco (vicino allo zero); costante, basso numero di scritture (vedi immagine). Picchi durante la pulizia di revisione.

Attenzione: l'alto e crescente livello di lettura dei dischi è segno di sottodimensionamento della memoria (vedi immagine).

DISCLAIMER: un alto volume di IO del disco è dovuto ad altre operazioni in esecuzione su AEM (per esempio: ingestione di risorse) o da un altro processo (per esempio: scansione di virus), quindi assicuratevi di escludere qualsiasi altra causa prima della diagnosi Segment Tar come colpevole. In generale, l'andamento nel corso dei giorni è più rilevante rispetto ai picchi locali.

Monitoraggio della CPU

• Cosa: tempo speso dalla CPU per varie operazioni, soprattutto in attesa di IO.
• Come: Strumenti a livello di OS (per esempio: vmstat su UNIX). Non tutti gli strumenti lo segnalano (per esempio: top).
• Normale: La CPU è utilizzata principalmente dall'applicazione a livello utente e l'attesa per l'IO è una piccola percentuale.
• Attenzione: La CPU sta spendendo la maggior parte dei cicli in attesa di IO, con una tendenza al rialzo, a scapito dell'applicazione utente.
• DICHIARAZIONE DI NON RESPONSABILITÀ: un'alta percentuale di CPU in attesa di IO è dovuta ad altre operazioni in esecuzione su AEM (per esempio: ingestione di risorse) o da un altro processo (per esempio: scansione di virus), quindi assicuratevi di escludere qualsiasi altra causa prima di diagnosticare come colpevole il Segment Tar. In generale, l'andamento nel corso dei giorni è più rilevante rispetto ai picchi locali.

Monitoraggio della coda degli impegni

• Cosa: la coda di commit è un meccanismo di buffering utilizzato da Segment Tar quando il volume di commit in entrata è superiore alla velocità di elaborazione.
• Come: la dimensione della coda di commit in tempo reale è esposta tramite la MBean di JMX: org.apache.jackrabbit.oak: COMMIT_QUEUEUE_SIZE (Metriche) (/system/console/jmx/org.apache.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUEUEUE_SIZE%2Ctype%3DMetrics). L'accesso avviene tramite http sulla console di sistema o utilizzando un client JMX.
• Normale: una coda vuota (size=0) mostra che il sistema è in buono stato e può processare tutti i commit alla velocità con cui arrivano. Sono normali anche i picchi locali che vengono elaborati velocemente.
• Attenzione: una coda costante con un valore diverso da zero, con un trend crescente significa che il segmento TAR non può elaborare i commit alla velocità in entrata. C'è il rischio che la coda si riempia e che i nuovi commits siano rifiutati.
• DICHIARAZIONE DI NON RESPONSABILITÀ: un'alta coda temporanea (picco) è dovuta ad un'operazione intensiva (per esempio: replicazione o roll-out) o ad un alto traffico, quindi assicuratevi di escludere qualsiasi altra causa prima di diagnosticare il segmento TAR come colpevole. In generale, la tendenza è più rilevante dei picchi locali.