Show Menu
ARGOMENTI×

Monitoraggio e manutenzione dell’istanza AEM

Dopo l’implementazione delle istanze AEM, saranno necessarie alcune attività per monitorare e mantenere il funzionamento, le prestazioni e l’integrità.
Un fattore chiave in questo caso è che per riconoscere i potenziali problemi è necessario sapere come si presentano e si comportano i sistemi in condizioni normali. Ciò è meglio monitorando il sistema e raccogliendo informazioni in un determinato periodo di tempo.
Seleziona
Considerazioni
Commento/Azioni
piano di backup.
Piano di ripristino di emergenza.
Linee guida aziendali sul disaster recovery.
Per segnalare i problemi è disponibile un sistema di monitoraggio degli errori.
Ad esempio, bugzilla , jira o uno dei tanti altri.
I file system vengono monitorati.
Se lo spazio disponibile su disco è insufficiente, il repository CRX si blocca. e riprenderà quando sarà disponibile lo spazio.
" *ERROR* LowDiskSpaceBlocker " i messaggi possono essere visualizzati nel file di registro quando lo spazio disponibile diventa insufficiente.
I file di registro vengono monitorati.
Il monitoraggio del sistema viene eseguito (in modo costante) in background.
CPU, memoria, disco e utilizzo della rete. Ad esempio, iostat / vmstat / perfmon.
I dati registrati vengono visualizzati e possono essere utilizzati per tenere traccia dei problemi di prestazioni. Anche i dati non elaborati sono accessibili.
Inclusi i contatori delle richieste per monitorare i livelli di traffico.
Se si riscontra una perdita significativa, o a lungo termine, dei risultati ottenuti, occorre effettuare un'indagine approfondita.
Stai monitorando i tuoi agenti di replica. "
Elimina regolarmente le istanze del flusso di lavoro.
Dimensioni dell'archivio e prestazioni del flusso di lavoro.
Consultate Sgancio regolare delle istanze del flusso di lavoro.

Backup

È buona prassi effettuare backup di:
  • Installazione del software - prima/dopo modifiche significative nella configurazione
  • Contenuto custodito nel repository - regolarmente
La vostra azienda avrà probabilmente una politica di backup da seguire, considerazioni aggiuntive su cosa eseguire il backup e quando includere:
  • quanto sono critici il sistema e i dati.
  • la frequenza con cui vengono apportate modifiche al software o ai dati.
  • volume dei dati; la capacità può occasionalmente essere un problema, così come il tempo necessario per eseguire il backup.
  • se è possibile eseguire il backup mentre gli utenti sono online; e, se possibile, qual è l'impatto sulle prestazioni.
  • la distribuzione geografica degli utilizzatori; ad esempio, quando è il momento migliore per eseguire il backup (per ridurre al minimo l'impatto)?
  • la politica di disaster recovery; esistono linee guida sulle aree in cui i dati di backup devono essere memorizzati (ad esempio fuori sede, supporto specifico, ecc.).
Spesso un backup completo viene eseguito a intervalli regolari (ad esempio, giornalieri, settimanali o mensili), con backup incrementali intermedi (ad esempio orari, giornalieri o settimanali).
Durante l'implementazione dei backup delle istanze di produzione, è necessario eseguire dei test per verificare che il backup possa essere ripristinato correttamente.
Senza questo, il backup è potenzialmente inutile (scenario peggiore).
Per ulteriori informazioni sulle prestazioni di backup, consulta la sezione Prestazioni di backup.

Backup dell'installazione software

Dopo l'installazione, o modifiche significative nella configurazione, eseguire un backup dell'installazione software.
A questo scopo, è necessario eseguire il backup dell'intero repository , quindi:
  1. Arrestate AEM.
  2. Eseguire il backup dell'intero <cq-installation-dir> file system.
Se si utilizza un server applicazioni di terze parti, è possibile che altre cartelle si trovino in un percorso diverso e che sia necessario eseguire il backup. Consultate Come installare AEM con un server applicazioni per informazioni sull'installazione dei server applicazioni.
È supportato il backup incrementale dell'archivio dati del file; quando si utilizza il backup incrementale per altri componenti (come l'indice Lucene), assicurarsi che anche i file eliminati siano contrassegnati come eliminati nel backup.
Il mirroring del disco può essere utilizzato anche come meccanismo di backup.

Backup del repository

La sezione Backup e ripristino della documentazione CRX illustra tutti i problemi relativi ai backup del repository CRX.
Per informazioni dettagliate sulla creazione di un backup online "hot", consultate Creazione di un backup online.

Rimozione delle versioni

Lo strumento Versioni di eliminazione è destinato a eliminare le versioni di un nodo o di una gerarchia di nodi nel repository. Lo scopo principale è quello di ridurre le dimensioni del repository rimuovendo le versioni precedenti dei nodi.
Questa sezione descrive le operazioni di manutenzione relative alla funzione di controllo delle versioni di AEM. Lo strumento Svuota versione è destinato ad eliminare le versioni di un nodo o di una gerarchia di nodi nel repository. Lo scopo principale è quello di ridurre le dimensioni del repository rimuovendo le versioni precedenti dei nodi.

Panoramica

Lo strumento Rimuovi versioni è disponibile nella console Console strumenti Strumenti ​in Gestione​ versioni ​o direttamente all’indirizzo: "
https://<server>:<port>/etc/versioning/purge.html
Percorso iniziale Un percorso assoluto sul quale eseguire la rimozione. Per selezionare il Percorso iniziale, fare clic sul Navigator della struttura della directory archivio.
Ricorsivo Quando si eliminano i dati è possibile scegliere se eseguire l'operazione su un nodo o su un'intera gerarchia selezionando Ricorsivo. Nell'ultimo caso il percorso specificato definisce il nodo principale della gerarchia.
Numero massimo di versioni per mantenere il numero massimo di versioni da mantenere per un nodo. Quando questo numero supera questo valore, vengono eliminate le versioni precedenti.
Età massima versione L'età massima della versione di un nodo. Quando l'età di una versione supera questo valore, viene eliminata.
Prova a secco Poiché la rimozione di versioni del contenuto è definita e non può essere ripristinata senza il ripristino di un backup, lo strumento Rimuovi versioni fornisce una modalità di esecuzione a secco che consente di visualizzare in anteprima le versioni eliminate. Per avviare una prova del processo di eliminazione, fare clic su Prova.
Elimina Avvia la rimozione delle versioni sul nodo definito dal Percorso iniziale.

Rimozione delle versioni di un sito Web

Per eliminare le versioni di un sito Web, procedere come segue:
  1. Passate alla console Console strumenti Strumenti , selezionate Gestione​ versioni ​e fate doppio clic su​ Rimuovi versioni .
  2. Impostate il percorso iniziale del contenuto da rimuovere (ad es. /content/geometrixx-outdoors ).
    • Per eliminare solo il nodo definito dal percorso, deselezionare Ricorsivo .
    • Per eliminare il nodo definito dal percorso e dai relativi discendenti, selezionare Ricorsivo .
  3. Impostate il numero massimo di versioni (per ciascun nodo) che desiderate mantenere. Lasciate vuoto per non utilizzare questa impostazione.
  4. Impostate l'età massima della versione in giorni (per ogni nodo) che desiderate mantenere. Lasciate vuoto per non utilizzare questa impostazione.
  5. Fate clic su Prova per visualizzare un'anteprima delle operazioni di eliminazione.
  6. Fate clic su Elimina per avviare il processo.
I nodi eliminati non possono essere ripristinati senza ripristinare il repository. Si dovrebbe prendersi cura della configurazione, quindi si consiglia di eseguire sempre una prova a secco prima di rimuovere.

Analisi della console

I processi Prova e Svuota elencano tutti i nodi elaborati. Durante il processo, un nodo può avere uno dei seguenti stati:
  • ignore (not versionnable) : il nodo non supporta il controllo delle versioni e viene ignorato durante il processo.
  • ignore (no version) : il nodo non dispone di alcuna versione e viene ignorato durante il processo. "
  • retained : il nodo non viene eliminato.
  • purged : il nodo viene eliminato.
Inoltre, la console fornisce informazioni utili sulle versioni:
  • V 1.0 : il numero di versione.
  • V 1.0.1 &ast;: la stella indica che la versione è quella corrente.
  • Thu Mar 15 2012 08:37:32 GMT+0100 : la data della versione.
Nell'esempio seguente:
  • Le versioni Shirts vengono eliminate perché la loro età è superiore a 2 giorni.
  • Le Moda Tonga! le versioni vengono eliminate perché il loro numero è maggiore di 5.

Utilizzo dei record di controllo e dei file di registro

I record e i file di registro di controllo relativi ad Adobe Experience Manager (AEM) possono essere trovati in varie posizioni. Di seguito viene fornita una panoramica di ciò che è possibile trovare.

Utilizzo dei registri

AEM WCM registra i registri dettagliati. Dopo aver decompresso e avviato Quickstart, puoi trovare i registri in:
  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotazione del file di registro

La rotazione del file di registro si riferisce al processo che limita la crescita del file creando periodicamente un nuovo file. In AEM, un file di registro denominato error.log viene ruotato una volta al giorno in base alle regole specificate:
  • Il error.log file viene rinominato in base al pattern .yyyy-MM-dd . Ad esempio, l’11 luglio 2010, il file di registro corrente viene rinominato error.log-2010-07-10 , quindi error.og viene creato un nuovo file.
  • I file di registro precedenti non vengono eliminati, quindi è responsabilità dell'utente pulire i vecchi file di registro periodicamente per limitare l'utilizzo del disco.
Se aggiorni l’installazione di AEM, qualsiasi file di registro esistente non più utilizzato da AEM rimarrà sul disco. Potete rimuoverli senza rischi. Tutte le nuove voci di registro verranno scritte nei nuovi file di registro.

Ricerca dei file di registro

Diversi file di registro sono memorizzati nel file server in cui è stato installato AEM:
  • <cq-installation-dir>/crx-quickstart/logs
    • access.log
      Tutte le richieste di accesso ad AEM WCM e all'archivio sono registrate qui.
    • audit.log
      Le azioni di moderazione sono registrate qui.
    • error.log
      I messaggi di errore (con vari livelli di gravità) sono registrati qui.
    • Questo registro viene utilizzato solo se è abilitato il supporto dinamico. Fornisce informazioni statistiche e analitiche utilizzate per analizzare il comportamento del processo ImageServer interno.
    • request.log
      Ogni richiesta di accesso è registrata qui insieme alla risposta.
    • Questo registro viene utilizzato solo se è abilitato il supporto dinamico. Il registro s7access registra ogni richiesta effettuata a Dynamic Media tramite /is/image e /is/content .
    • stderr.log
      Contiene messaggi di errore, di nuovo con diversi livelli di gravità, generati durante l'avvio. Per impostazione predefinita, il livello di registro è impostato su Warning ( WARN )
    • stdout.log
      Contiene i messaggi di registrazione che indicano gli eventi durante l'avvio.
    • upgrade.log
      Fornisce un registro di tutte le operazioni di aggiornamento in esecuzione dai com.day.compat.codeupgrade pacchetti e com.adobe.cq.upgradesexecutor .
  • <cq-installation-dir>/crx-quickstart/repository
    • revision.log
      Informazioni sulla registrazione delle revisioni.
I registri ImageServer e s7access non sono inclusi nel pacchetto Download Full generato dalla pagina di elenco dei sistemi/console/status-Bundlelist . Per motivi di supporto, in caso di problemi relativi ai file multimediali dinamici aggiungi i registri ImageServer e s7access quando contatta l’Assistenza clienti.

Attivazione del livello di registro DEBUG

Il livello di registro predefinito Configurazione registrazione Apache Sling è Informazioni, quindi i messaggi di debug non vengono registrati.
Per attivare il livello di registro di debug per un logger, impostare la proprietà org.apache.sling.commons.log.level su debug nell'archivio. Ad esempio, per configurare /libs/sling/config/org.apache.sling.commons.log.LogManager la registrazione Sling Apache globale .
Non lasciare il registro a livello di registro di debug più lungo del necessario, in quanto genera molte voci di registro, consumando quindi risorse.
Una riga nel file di debug in genere inizia con DEBUG, quindi fornisce il livello di registro, l'azione del programma di installazione e il messaggio di registro. Ad esempio:
DEBUG 3 WebApp Panel: WebApp successfully deployed

I livelli di registro sono i seguenti:
0
Errore irreversibile
L'azione non è riuscita e il programma di installazione non può proseguire.
1
Errore
L'azione non è riuscita. L'installazione continua, ma una parte di AEM WCM non è stata installata correttamente e non funzionerà.
2
Avvertenza
L'azione è riuscita ma ha incontrato dei problemi. AEM WCM potrebbe funzionare o meno correttamente.
3
Informazioni
L'azione è riuscita.

Creare un file di registro personalizzato

When working with Adobe Experience Manager there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.
In alcune circostanze può essere utile creare un file di registro personalizzato con un livello di registro diverso. È possibile eseguire questa operazione nella directory archivio:
  1. Se non già esistente, create una nuova cartella di configurazione ( sling:Folder ) per il progetto /apps/<project-name>/config .
  2. In /apps/<project-name>/config , create un nodo per la nuova configurazione del log di registrazione Apache Sling:
    • Nome: org.apache.sling.commons.log.LogManager.factory.config-<identifier> (poiché si tratta di un logger)
    Dove <identifier> viene sostituito da testo libero che è necessario immettere per identificare l’istanza (non è possibile omettere tali informazioni). Ad esempio: org.apache.sling.commons.log.LogManager.factory.config-MINE
    • Tipo: sling:OsgiConfig
    Anche se non è un requisito tecnico, è consigliabile rendere <identifier> unico.
  3. Imposta le seguenti proprietà su questo nodo:
    • Nome: org.apache.sling.commons.log.file
      Tipo:Stringa
      Valore: specifica il file di registro; ad esempio, logs/myLogFile.log
    • Nome: org.apache.sling.commons.log.names
      Tipo: String[] (String + Multi)
      Valore: specificare i servizi OSGi per i quali il logger deve registrare i messaggi; ad esempio, tutti i seguenti elementi:
      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nome: org.apache.sling.commons.log.level
      Tipo:Stringa
      Valore: specificare il livello di registro richiesto ( debug , info , warn o error );ad esempio debug
    • Configurate gli altri parametri come richiesto:
      • Nome: org.apache.sling.commons.log.pattern
        Tipo: String
        Valore: specificare il pattern del messaggio di registro come richiesto; ad esempio,
        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
    org.apache.sling.commons.log.pattern supporta fino a sei argomenti.
    {0} Il timestamp del tipo java.util.Date {1} il marcatore di registro {2} nome del thread corrente {3} nome del logger {4} il livello di registro {5} il messaggio di registro
    Se la chiamata di registro include una traccia Throwable di stack, questa viene aggiunta al messaggio.
    org.apache.sling.commons.log.names deve avere un valore.
    I percorsi di scrittura del registro sono relativi alla crx-quickstart posizione.
    Pertanto, un file di registro specificato come:
    logs/thelog.log
    scrive in:
    <cq-installation-dir>/crx-quickstart/logs/thelog.log .
    E un file di registro specificato come:
    ../logs/thelog.log
    scrive in una directory:
    <cq-installation-dir>/logs/ (cioè accanto a <cq-installation-dir>/crx-quickstart/ )
  4. Questo passaggio è necessario solo quando è necessario un nuovo Writer (ad es. con una configurazione diversa da quella del Writer predefinito).
    È necessaria una nuova configurazione per l'utente che esegue l'accesso solo se l'impostazione predefinita esistente non è adatta. Se non è configurato alcun Writer esplicito, il sistema genererà automaticamente un Writer implicito in base all'impostazione predefinita.
    In /apps/<project-name>/config , create un nodo per la nuova configurazione del writer di registrazione Apache Sling:
    • Nome: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (come lo scrittore)
      Come per il logger, <identifier> viene sostituito da testo libero che è necessario immettere per identificare l’istanza (non è possibile omettere tali informazioni). Ad esempio: org.apache.sling.commons.log.LogManager.factory.writer-MINE
    • Tipo: sling:OsgiConfig
    Anche se non è un requisito tecnico, è consigliabile rendere <identifier> unico.
    Imposta le seguenti proprietà su questo nodo:
    • Nome: org.apache.sling.commons.log.file
      Tipo: String
      Valore: specificare il file di registro in modo che corrisponda al file specificato nel logger;
      in questo esempio, ../logs/myLogFile.log .
    • Configurate gli altri parametri come richiesto:
      • Nome: org.apache.sling.commons.log.file.number
        Tipo: Long
        Valore: specificare il numero di file di registro da conservare; ad esempio, 5
      • Nome: org.apache.sling.commons.log.file.size
        Tipo: String
        Valore: specificare come necessario per controllare la rotazione del file per dimensione/data; ad esempio, '.'yyyy-MM-dd
    org.apache.sling.commons.log.file.size controlla la rotazione del file di registro impostando:
    • una dimensione massima del file
    • una pianificazione di ora/data
    per indicare quando verrà creato un nuovo file (e il file esistente verrà rinominato in base al pattern del nome).
    • È possibile specificare un limite di dimensioni con un numero. Se non viene fornito alcun indicatore di dimensione, questo viene considerato come il numero di byte, oppure è possibile aggiungere uno degli indicatori di dimensione - KB , MB o GB (il caso viene ignorato).
    • È possibile specificare come java.util.SimpleDateFormat pattern una pianificazione di ora/data. Definisce il periodo di tempo dopo il quale il file verrà ruotato; inoltre il suffisso aggiunto al file ruotato (per l’identificazione).
    Il valore predefinito è '.'yyyy-MM-dd (per la rotazione giornaliera del registro).
    Ad esempio, a mezzanotte del 20 gennaio 2010 (o quando il primo messaggio di registro dopo tale data sarà preciso), ../logs/error.log verrà rinominato in ../logs/error.log.2010-01-20. La registrazione per il 21 gennaio verrà restituita a (un nuovo e vuoto) ../logs/error.log finché non viene eseguito il rollback al cambio di giorno successivo.
    '.'yyyy-MM
    Rotazione all'inizio di ogni mese
    '.'yyyy-ww
    Rotazione al primo giorno di ogni settimana (a seconda delle impostazioni internazionali).
    '.'yyyy-MM-dd
    Rotazione a mezzanotte ogni giorno.
    '.'yyyy-MM-dd-a
    Rotazione a mezzanotte e a mezzogiorno di ogni giorno.
    '.'yyyy-MM-dd-HH
    Rotazione nella parte superiore di ogni ora.
    '.'yyyy-MM-dd-HH-mm
    Rotazione all'inizio di ogni minuto.
    Nota: Quando si specifica un'ora/data:
    1. È necessario "escape" testo letterale all'interno di una coppia di virgolette singole (' ');
      per evitare che alcuni caratteri vengano interpretati come lettere del pattern.
    2. Utilizzate solo i caratteri consentiti per un nome di file valido in qualsiasi punto dell'opzione.
  5. Leggere il nuovo file di registro con lo strumento scelto.
    Il file di registro creato da questo esempio sarà ../crx-quickstart/logs/myLogFile.log .
La console Felix fornisce inoltre informazioni sul supporto dei log Sling in ../system/console/slinglog ; ad esempio http://localhost:4502/system/console/slinglog .

Ricerca dei record di controllo

I record di audit sono tenuti per fornire un record di chi ha fatto cosa e quando. Vengono generati record di controllo diversi per gli eventi AEM WCM e OSGi.

Record di controllo AEM WCM visualizzati durante l’authoring delle pagine

  1. Aprite una pagina.
  2. Dalla barra laterale è possibile selezionare la scheda con l'icona a forma di lucchetto, quindi fare doppio clic su Audit Log...
  3. Viene aperta una nuova finestra che mostra l'elenco dei record di controllo per la pagina corrente.
  4. Fare clic su OK per chiudere la finestra.

Record di AEM WCM Auditing nella directory archivio

All'interno della /var/audit cartella, i record di controllo vengono conservati in base alla risorsa. È possibile approfondire la struttura fino a visualizzare i singoli record e le informazioni che contengono.
Queste voci contengono le stesse informazioni visualizzate durante la modifica di una pagina.

Record di audit OSGi dalla console Web

Gli eventi OSGi generano inoltre record di controllo che possono essere visualizzati dalla scheda Stato ​configurazione -> File di registro ​nella console Web di AEM:

Monitoraggio degli agenti di replica

È possibile monitorare le code di replica per rilevare quando una coda è inattiva o bloccata, il che potrebbe a sua volta indicare un problema con un'istanza di pubblicazione o con un sistema esterno:
  • tutte le code richieste sono abilitate?
  • sono ancora necessarie code per i disabili?
  • tutte enabled le code devono avere lo stato idle o active , che indicano il normale funzionamento; non devono essere presenti code blocked , che è spesso un segno di problemi da parte dei ricevitori.
  • se le dimensioni della coda aumentano nel tempo, potrebbe indicare una coda bloccata.
Per monitorare un agente di replica:
  1. Accedete alla scheda Strumenti in AEM.
  2. Fate clic su Replica .
  3. Fare doppio clic sul collegamento agli agenti per l'ambiente appropriato (il riquadro a sinistra o a destra); ad esempio Agenti sull’autore .
    Nella finestra visualizzata viene visualizzata una panoramica di tutti gli agenti di replica per l’ambiente di authoring, inclusi il target e lo stato.
  4. Fate clic sul nome agente appropriato (collegamento) per visualizzare informazioni dettagliate su tale agente:
    È possibile:
    • Verificare se l'agente è abilitato.
    • Visualizzare la destinazione di qualsiasi replica.
    • Verificare se la coda di replica è attualmente attiva (abilitata).
    • Verificare se sono presenti elementi nella coda.
    • Aggiorna o Cancella per aggiornare la visualizzazione delle voci della coda; questo consente di vedere gli elementi entrare e uscire dalla coda.
    • Visualizzare il registro per accedere al registro di eventuali azioni dell'agente di replica.
    • Verificare la connessione all'istanza di destinazione.
    • Se necessario, forza il tentativo su qualsiasi elemento della coda.
    Non utilizzate il collegamento "Test Connection" per la replica inversa in uscita in un'istanza pubblicata.
    Se viene eseguito un test di replica per una coda in uscita, tutti gli elementi precedenti alla replica di test verranno rielaborati con ogni replica inversa.
    Se tali elementi esistono già in una coda, possono essere trovati con la seguente query XPath JCR e devono essere rimossi.
    /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']
È inoltre possibile sviluppare una soluzione per rilevare tutti gli agenti di replica (situati sotto /etc/replication/author o /etc/replication/publish ), quindi controllare lo stato dell'agente ( enabled , disabled ) e la coda sottostante ( active , idle , blocked ).

Prestazioni di monitoraggio

Ottimizzazione delle prestazioni è un processo interattivo che viene messo a fuoco durante lo sviluppo. Dopo la distribuzione viene in genere rivisto dopo specifici intervalli o eventi.
I metodi utilizzati per la raccolta di informazioni per l'ottimizzazione possono essere utilizzati anche per il monitoraggio continuo.
Di seguito sono elencati i problemi comuni di prestazioni che si verificano, insieme alle proposte su come individuarli e contrastarli.
Area
Sintomi
Per aumentare la capacità...
Per ridurre il volume...
Client
Utilizzo CPU client elevato.
Installare una CPU client con prestazioni più elevate.
Semplificare il layout (HTML).
Utilizzo CPU server insufficiente.
Eseguire l'aggiornamento a un browser più veloce.
Miglioramento della cache lato client.
Alcuni clienti veloci, un po' lenti.
Server
Rete
Utilizzo della CPU basso sia su server che su client.
Rimuovere eventuali colli di bottiglia della rete.
Migliorate/ottimizzate la configurazione della cache client.
La navigazione locale sul server è (relativamente) veloce.
Aumento della larghezza di banda della rete.
Riducete il peso delle pagine Web (ad es. meno immagini, HTML ottimizzato).
Web-server
L'utilizzo della CPU sul server Web è elevato.
Cluster dei server Web.
Ridurre gli hit per pagina (visita).
Utilizzare un sistema hardware di bilanciamento del carico.
Applicazione
L'utilizzo della CPU del server è elevato.
Cluster delle istanze AEM.
Cercare ed eliminare i cani della CPU e della memoria (usare la revisione del codice, l'output dei tempi, ecc.).
Consumo di memoria elevato.
Miglioramento della memorizzazione nella cache a tutti i livelli.
Tempi di risposta ridotti.
Ottimizzare modelli e componenti (ad esempio struttura, logica).
Archivio
Cache
I problemi di prestazioni possono derivare da una serie di cause che non hanno nulla a che fare con il sito Web, tra cui rallentamenti temporanei nella velocità di connessione, il carico della CPU e molti altri.
Può anche avere un impatto su tutti i visitatori, o solo su un sottoinsieme di essi.
Tutte queste informazioni devono essere ottenute, ordinate e analizzate prima di poter ottimizzare le prestazioni generali o risolvere problemi specifici.
  • Prima di un problema di prestazioni:
    • raccogliere il maggior numero possibile di informazioni per sviluppare una buona conoscenza del sistema in circostanze normali
  • In caso di problemi di prestazioni:
    • provare a replicarlo con uno (o preferibilmente più) browser web standard, su un client diverso che si sa che ha buone prestazioni generali e/o sul server stesso (se possibile)
    • verificare se qualcosa (correlato al sistema) è cambiato entro uno spazio temporale appropriato e se una di queste modifiche potrebbe avere avuto un impatto sulle prestazioni
    • fate domande come:
      • il problema si verifica solo in momenti specifici?
      • il problema si verifica solo su pagine specifiche?
      • le altre richieste sono interessate?
    • raccogliere il maggior numero possibile di informazioni da confrontare con la vostra conoscenza del sistema in circostanze normali:

Strumenti per monitorare e analizzare le prestazioni

Di seguito viene fornita una breve panoramica di alcuni degli strumenti disponibili per monitorare e analizzare le prestazioni.
Alcuni di questi dipenderanno dal sistema operativo in uso.
Strumento Utilizzato per analizzare... Utilizzo / Ulteriori informazioni...
request.log Tempi di risposta e concorrenza. Interpretazione di request.log .
truss/strass Caricamenti pagina
Comandi Unix/Linux per tracciare chiamate di sistema e segnali. Impostare il livello di registro su INFO .
Analizzare il numero di caricamenti di pagina per richiesta, quali pagine, ecc.
Fanelli di filetto Osservare i thread JVM. Identificare i conteggi, le serrature e i corridori lunghi.
A seconda del sistema operativo: - Unix/Linux: kill -QUIT < pid > - Windows (modalità console): Ctrl-Break
Sono disponibili anche strumenti di analisi, come TDA .
Cassetti heap Problemi di memoria esauriti che provocano prestazioni lente.
Aggiungi: opzione -XX:+HeapDumpOnOutOfMemoryError per la chiamata Java ad AEM.
Chiamate di sistema Identificare i problemi di temporizzazione.
Le chiamate a System.currentTimeMillis() or com.day.util .Timing vengono utilizzate per generare marche temporali dal codice o tramite commenti #html-commentsHTML.
Nota: Tali misure dovrebbero essere attuate in modo che possano essere attivate o disattivate secondo necessità; quando un sistema funziona senza problemi, l'onere della raccolta delle statistiche non sarà necessario.
Apache Bench Identificare le perdite di memoria, analizzare in modo selettivo il tempo di risposta.
utilizzo di base:
ab -k -n < requests > -c < concurrency > < url >
Per maggiori informazioni, consulta Apache Bench e la pagina man ab.
Analisi di ricerca Eseguire query di ricerca offline, identificare il tempo di risposta della query, verificare e confermare il set di risultati.
JMeter Carico e prove funzionali. https://jakarta.apache.org/jmeter/
JProfiler Profiling approfondito della CPU e della memoria. https://www.ej-technologies.com/
JConsole Osservare le metriche e i thread JVM.
Utilizzo: jconsole
Nota: Con JDK 1.6, JConsole è estensibile con i plug-in; ad esempio, Top o TDA (Thread Dump Analyzer).
Java VisualVM Osservare le metriche JVM, i thread, la memoria e il profiling.
Utilizzo: jvisualvm o visualvm
Nota: Con JDK 1.6, VisualVM è estensibile con i plug-in.
tronco/striscia, elenco Approfondimenti di chiamata e analisi del processo del kernel (Unix). Comandi Unix/Linux.
Statistiche temporali Consultate le statistiche sui tempi per il rendering della pagina.
Per visualizzare le statistiche sui tempi di rendering della pagina, potete usare Ctrl+Maiusc+U insieme a ?debugClientLibs=true un’impostazione nell’URL.
Strumento di profilazione CPU e memoria Utilizzato per analizzare le richieste lente durante lo sviluppo . Ad esempio, YourKit .
Raccolta informazioni Lo stato dell’installazione in corso. Conoscere il più possibile l'installazione può anche aiutarti a tenere traccia di ciò che potrebbe aver causato un cambiamento nelle prestazioni e se queste modifiche sono giustificate. Queste metriche devono essere raccolte a intervalli regolari per poter vedere facilmente cambiamenti significativi.

Interpretazione di request.log

Questo file registra le informazioni di base su ogni richiesta effettuata ad AEM. Da queste preziose conclusioni si possono trarre.
L' request.log offerta offre un modo integrato per vedere quanto tempo le richieste richiedono. A scopo di sviluppo è utile per tail -f il request.log e guardare per tempi di risposta lenti. Per analizzare un numero maggiore request.log consigliamo l' utilizzo di di risposta.
Si consiglia di isolare le pagine "lente" dal request.log pannello, quindi di sintonizzarle singolarmente per ottenere prestazioni migliori. In genere questo viene fatto includendo le metriche delle prestazioni per componente o utilizzando uno strumento di profiling delle prestazioni come [yourkit](https://www.yourkit.com/) .

Monitoraggio del traffico sul sito Web

Il registro delle richieste registra ogni richiesta effettuata, insieme alla risposta ricevuta:
09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Compilando tutte le voci GET entro un periodo specifico (ad esempio per diversi periodi di 24 ore), è possibile fare delle dichiarazioni sul traffico medio sul sito Web.

Monitoraggio dei tempi di risposta con request.log

Un buon punto di partenza per l'analisi delle prestazioni è il registro delle richieste:
<cq-installation-dir>/crx-quickstart/logs/request.log
Il registro si presenta come segue (le righe vengono abbreviate per semplicità):
31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1 
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms 
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1 
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Questo registro ha una riga per richiesta o risposta:
  • Data in cui è stata effettuata ogni richiesta o risposta.
  • Il numero della richiesta, tra parentesi quadre. Questo numero corrisponde alla richiesta e alla risposta.
  • Una freccia che indica se si tratta di una richiesta (freccia rivolta verso destra) o di una risposta (freccia verso sinistra).
  • Per le richieste, la riga contiene:
    • il metodo (in genere, GET, HEAD o POST)
    • la pagina richiesta
    • il protocollo
  • Per le risposte, la riga contiene:
    • il codice di stato (200 significa "successo", 404 significa "pagina non trovata"
    • il tipo MIME
    • il tempo di risposta
Utilizzando script di piccole dimensioni, è possibile estrarre le informazioni richieste dal file di registro e assemblare le statistiche desiderate. Da questi elementi potete vedere quali pagine o tipi di pagine sono lenti e se le prestazioni complessive sono soddisfacenti.

Monitoraggio dei tempi di risposta della ricerca con request.log

Le richieste di ricerca sono registrate anche nel file di registro:
31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Come sopra, potete utilizzare gli script per estrarre le informazioni rilevanti e generare statistiche.
Tuttavia, una volta determinato il tempo di risposta, potrebbe essere necessario analizzare il motivo per cui la richiesta prende il tempo necessario e cosa può essere fatto per migliorare la risposta.

Monitoraggio del numero e dell’impatto degli utenti simultanei

Anche in questo caso, request.log è possibile monitorare la concorrenza e la reazione del sistema.
Devono essere eseguiti test per determinare quanti utenti simultanei il sistema può gestire prima che venga visto un impatto negativo. Anche in questo caso gli script possono essere utilizzati per estrarre i risultati dal file di registro:
  • monitorare il numero di richieste effettuate entro un periodo di tempo specifico, ad esempio un minuto
  • sottoporre a test gli effetti di un numero specifico di utenti che fanno tutte le stesse richieste allo stesso tempo (il più vicino possibile); Ad esempio, 30 utenti fanno clic su Salva contemporaneamente.
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilizzo di rlog.jar per trovare le richieste con tempi di durata prolungati

AEM include vari strumenti di supporto disponibili in: <cq-installation-dir>/crx-quickstart/opt/helpers
Una di queste rlog.jar funzioni può essere utilizzata per ordinare rapidamente request.log in modo che le richieste vengano visualizzate per durata, dal più lungo al più breve tempo possibile.
Il seguente comando mostra gli argomenti possibili:
$java -jar rlog.jar 
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG 
Usage: 
  java -jar rlog.jar [options] <filename> 
Options: 
  -h               Prints this usage. 
  -n <maxResults>  Limits output to <maxResults> lines. 
  -m <maxRequests> Limits input to <maxRequest> requests. 
  -xdev            Exclude POST request to CRXDE.

Ad esempio, potete eseguirlo specificando request.log il file come parametro e mostrare le 10 prime richieste con la durata più lunga:
$ java -jar ../opt/helpers/rlog.jar -n 10 request.log 
*Info * Parsed 464 requests. 
*Info * Time for parsing: 22ms 
*Info * Time for sorting: 2ms 
*Info * Total Memory: 1mb 
*Info * Free Memory: 1mb 
*Info * Used Memory: 0mb 
------------------------------------------------------ 
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html 
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript 
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html 
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html 
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript 
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript 
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8 
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json 
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8 

Se è necessario eseguire questa operazione su un esempio di dati di grandi dimensioni, potrebbe essere necessario concatenare request.log i singoli file.

Apache Bench

Per ridurre al minimo l'impatto di casi speciali (come il processo di garbage collection, ecc.), si consiglia di utilizzare uno strumento come apachebench (vedere, ad esempio, ab per ulteriori documenti) per identificare le perdite di memoria e analizzare in modo selettivo il tempo di risposta.
Apache Bench può essere utilizzato nel modo seguente:
$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

I numeri riportati sopra sono tratti da un notebook standard MAcBook Pro (metà 2010) che accede alla pagina aziendale geometrixx, come incluso in un'installazione AEM predefinita. La pagina è molto semplice, ma non ottimizzata per le prestazioni.
apachebench visualizza anche il tempo per richiesta come media, per tutte le richieste simultanee; vedere Time per request: 54.595 [ms] (media, per tutte le richieste simultanee). Potete modificare il valore del parametro di concorrenza -c (numero di richieste multiple da eseguire alla volta) per visualizzare eventuali effetti.

Contatori richieste

Le informazioni sul traffico delle richieste (numero di richieste durante un periodo di tempo specifico) indicano il carico sull’istanza. Queste informazioni possono essere estratte da request.log , anche se l'utilizzo di contatori automatizza la raccolta dei dati per consentirti di visualizzare:
  • differenze significative nell'attività (ossia distinguere tra "molte richieste" e "attività bassa"
  • quando un'istanza non viene utilizzata
  • eventuali riavvii (i contatori vengono reimpostati su 0)
Per automatizzare la raccolta delle informazioni è inoltre possibile installare RequestFilter per incrementare un contatore su ogni richiesta. Più contatori possono essere utilizzati per periodi di tempo diversi.
Le informazioni raccolte possono essere utilizzate per indicare:
  • cambiamenti significativi dell'attività
  • un'istanza ridondante
  • eventuali riavvii (contatore reimpostato su 0)

Commenti HTML

È consigliabile che ogni progetto includa html comments le prestazioni del server. Si possono trovare molti buoni esempi pubblici; selezionate una pagina, aprite l’origine della pagina per visualizzarla e scorrete verso il basso, con un codice come quello che segue:
</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitoraggio delle prestazioni con JConsole

Il comando tool jconsole è disponibile con il JDK.
  1. Avviate l’istanza AEM.
  2. Esegui jconsole.
  3. Selezionate l’istanza AEM e Connect .
  4. Dall’interno dell’ Local applicazione, fare doppio clic com.day.crx.quickstart.Main ; la Panoramica verrà visualizzata come impostazione predefinita:
    Dopo questo è possibile selezionare altre opzioni.

Monitoraggio delle prestazioni con (J)VisualVM

A partire da JDK 1.6, il comando tool jvisualvm è disponibile. Dopo aver installato JDK 1.6 è possibile:
  1. Avviate l’istanza AEM.
    Se si utilizza Java 5 è possibile aggiungere l' -Dcom.sun.management.jmxremote argomento alla riga di comando java che avvia la JVM. JMX è abilitato per impostazione predefinita con Java 6.
  2. Eseguire:
    • jvisualvm : nella cartella bin JDK 1.6 (versione testata)
    • visualvm : può essere scaricato da VisualVM (versione del bordo di dissanguamento)
  3. Dall’interno dell’ Local applicazione, fare doppio clic com.day.crx.quickstart.Main ; la Panoramica verrà visualizzata come impostazione predefinita:
    Dopo questo, potete selezionare altre opzioni, tra cui Monitor:
È possibile utilizzare questo strumento per generare i ribaltamenti di filettatura e i rigetti di testine di memoria. Queste informazioni sono spesso richieste dal team di assistenza tecnica.

Raccolta informazioni

Conoscere il più possibile l'installazione può aiutarti a tenere traccia di ciò che potrebbe aver causato un cambiamento nelle prestazioni e se queste modifiche sono giustificate. Queste metriche devono essere raccolte a intervalli regolari per poter vedere facilmente cambiamenti significativi.
Le seguenti informazioni possono essere utili:

Quanti autori lavorano con il sistema?

Per visualizzare il numero di autori che hanno utilizzato il sistema dall'installazione, utilizzare la riga di comando:
cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Per visualizzare il numero di autori che lavorano su una data specifica:
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Qual è il numero medio di attivazioni di pagina al giorno?

Per visualizzare il numero totale di attivazioni di pagina dall'installazione del server, utilizzare una query del repository; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:AuditEvent)[@cq:type='Activate']
Quindi calcolare il numero di giorni trascorsi dall'installazione per calcolare la media.

Quante pagine si trovano attualmente nel sistema?

Per visualizzare il numero di pagine attualmente sul server, utilizzare una query sull'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:Page)

Se utilizzate MSM, qual è il numero medio di rollout al mese?

Per determinare il numero totale di rollout dall'installazione utilizzando una query dell'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
Calcolare il numero di mesi trascorsi dall'installazione per calcolare la media.

Qual è il numero medio di Live Copy al mese?

Per determinare il numero totale di Live Copy effettuate dall'installazione utilizzando una query sull'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:LiveSyncConfig)
Utilizzate di nuovo il numero di mesi trascorsi dall'installazione per calcolare la media.

Se usi Risorse AEM, quante risorse attualmente mantieni in Risorse?

Per verificare il numero di risorse DAM attualmente gestite, utilizzate una query sull'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query /jcr:root/content/dam//element(*, dam:Asset)

Qual è la dimensione media delle risorse?

Per determinare la dimensione totale della /var/dam cartella:
  1. Utilizzare WebDAV per mappare l'archivio sul file system locale.
  2. Utilizzare la riga di comando:
    cd /Volumes/localhost/var
    du -sh dam/
    
    
    Per ottenere la dimensione media, dividete la dimensione globale per il numero totale di risorse in /var/dam (ottenuto sopra).

Quanti modelli sono attualmente utilizzati?

Per visualizzare il numero di modelli attualmente sul server, utilizzare una query sull'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:Template)

Quanti componenti sono attualmente utilizzati?

Per visualizzare il numero di componenti attualmente presenti sul server, utilizzare una query dell'archivio; tramite CRXDE - Strumenti - Query:
  • Tipo XPath
  • Percorso /
  • Query //element(*, cq:Component)

Quante richieste all’ora si verificano nel sistema di authoring in fase di picco?

Per determinare le richieste per ora nel sistema di creazione in fase di picco:
  1. Per determinare il numero totale di richieste dall'installazione, utilizzare la riga di comando:
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
    
  2. Per determinare le date di inizio e di fine:
    vim request.log
    G / 1G: for the last/first lines
    
    
    Utilizzate questi valori per calcolare il numero di ore trascorse dall'installazione, quindi il numero medio di richieste all'ora.

Quante richieste all’ora si verificano nel sistema di pubblicazione in fase di picco?

Ripetete la procedura descritta sopra nell’istanza di pubblicazione.

Analisi di scenari specifici

Di seguito è riportato un elenco di suggerimenti su come verificare se si verificano alcuni problemi di prestazioni. L'elenco non è (purtroppo) del tutto esaustivo.

CPU al 100%

Se la CPU del sistema è in esecuzione costantemente al 100%, vedere:

Memoria insufficiente

Anche se tali errori devono essere rilevati durante lo sviluppo e la verifica, alcuni scenari possono scivolare.
Se il sistema non dispone di memoria sufficiente, questo può essere visualizzato in vari modi, tra cui il degrado delle prestazioni e i messaggi di errore, incluso il sottotitolo:
java.lang.OutOfMemoryError
In questi casi controllare:

I/O disco

Se il sistema non dispone di spazio su disco sufficiente, oppure se si nota che il disco è danneggiato, vedere:

Degradazione regolare delle prestazioni

Se le prestazioni dell’istanza si deteriorano dopo ogni riavvio (a volte una settimana o più dopo), è possibile verificare quanto segue:

Sintonizzazione JVM

Java Virtual Machine (JVM) è notevolmente migliorata rispetto al tuning (soprattutto da Java 7). Per questo motivo, spesso è consigliabile specificare una dimensione JVM fissa ragionevole e utilizzare i valori predefiniti.
Se le impostazioni predefinite non sono adatte, è importante stabilire un metodo per monitorare e valutare le prestazioni GC prima di tentare di sintonizzare la JVM; questo può includere fattori di monitoraggio, tra cui la dimensione dell'heap, l'algoritmo e altri aspetti.
Alcune scelte comuni sono:
  • VerboseGC:
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    
    
Il registro risultante può essere assimilato da un visualizzatore GC, ad esempio:
[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)
O JConsole:
  • Queste impostazioni sono per una connessione JMX "wide open":
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
    
  • Collegare quindi la JVM con la JConsole; vedere: [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)
Questo vi aiuterà a vedere quanto memoria viene utilizzata, quali algoritmi GC vengono utilizzati, quanto tempo sono necessari per l'esecuzione e quale effetto ha sulle prestazioni dell'applicazione. Senza questo, sintonizzazione è solo "manopole casuali".
Per la VM di Oracle sono inoltre disponibili informazioni su: