Monitoraggio e manutenzione dell’istanza AEM monitoring-and-maintaining-your-aem-instance

CAUTION
AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.

Dopo la distribuzione delle istanze AEM, saranno necessarie alcune attività per monitorare e mantenere il funzionamento, le prestazioni e l’integrità delle istanze.

Un fattore chiave in questo caso è che per riconoscere potenziali problemi è necessario conoscere l'aspetto e il comportamento dei sistemi in condizioni normali. Il modo migliore per farlo è monitorare il sistema e raccogliere informazioni in un periodo di tempo.

Seleziona
Considerazioni
Commento/Azioni
Piano di backup.
Scopri come Esegui il backup dell'istanza.
Piano di ripristino di emergenza.
Le linee guida aziendali sul disaster recovery.
È disponibile un sistema di tracciamento degli errori per segnalare i problemi.
Ad esempio: bugzilla, giirao uno dei tanti altri.
I file system vengono monitorati.
L'archivio CRX si "blocca" se lo spazio libero su disco è insufficiente. Lo spazio riprende quando lo spazio diventa disponibile.
" *ERROR* LowDiskSpaceBlocker" i messaggi possono essere visti nel file di log quando lo spazio libero diventa basso.
File di registro vengono monitorati.
Il monitoraggio del sistema viene eseguito (costantemente) in background.
Compresi CPU, memoria, disco e utilizzo della rete. Utilizzando, 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.
Monitoraggio delle prestazioni AEM.
Incluso Contatori richieste per monitorare i livelli di traffico.
Se si riscontra una perdita significativa o a lungo termine dei risultati, occorre procedere a un'indagine approfondita.
Monitoraggio Agenti di replica.
Eliminare regolarmente le istanze del flusso di lavoro.
Dimensione dell’archivio e prestazioni del flusso di lavoro.
Vedi Rimozione regolare delle istanze del flusso di lavoro.

Backup backups

È buona prassi effettuare backup di:

  • Installazione del software - prima/dopo modifiche significative nella configurazione
  • Il contenuto all’interno dell’archivio - regolarmente

La tua azienda avrà probabilmente una politica di backup che sarà necessario 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; occasionalmente può 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 il backup (per ridurre al minimo l'impatto)?
  • la sua politica di ripristino di emergenza; esistono linee guida su dove devono essere archiviati i dati di backup (ad esempio fuori sede, supporto specifico, ecc.).

Spesso il backup completo viene eseguito a intervalli regolari (ad esempio quotidianamente, settimanalmente o mensilmente), con backup incrementali intermedi (ad esempio a cadenza oraria, giornaliera o settimanale).

CAUTION
Quando si implementano i backup delle istanze di produzione, i test deve per garantire il corretto ripristino del backup.
Senza questo, il backup è potenzialmente inutile (scenario peggiore).
NOTE
Per ulteriori informazioni sulle prestazioni di backup, leggere il Prestazioni di backup sezione .

Backup dell'installazione software backing-up-your-software-installation

Dopo l'installazione, o modifiche significative nella configurazione, eseguire un backup dell'installazione del software.

Per fare questo, devi eseguire il backup dell’intero archivio e quindi:

  1. AEM.
  2. Backup completo <cq-installation-dir> dal file system.
CAUTION
Se si utilizza un server applicazioni di terze parti, è possibile che altre cartelle si trovino in una posizione diversa e che sia necessario eseguire il backup. Vedi Come installare AEM con un server applicazioni per informazioni sull'installazione dei server applicazioni.
CAUTION
È supportato il backup incrementale dell’archivio dati del file; quando utilizzi il backup incrementale per altri componenti (come l'indice Lucene), assicurati che anche i file eliminati siano contrassegnati come eliminati nel backup.
NOTE
Il mirroring del disco può essere utilizzato anche come meccanismo di backup.

Backup dell'archivio backing-up-your-repository

La Backup e ripristino la sezione della documentazione CRX tratta tutti i problemi relativi ai backup dell'archivio CRX.

Per maggiori dettagli su come effettuare un backup "a caldo" online, vedi Creazione di un backup online.

Rimozione delle versioni version-purging

La Eliminare le versioni strumento è destinato a eliminare le versioni di un nodo o una gerarchia di nodi nel tuo archivio. Il suo scopo principale è quello di aiutarti a ridurre le dimensioni dell’archivio rimuovendo le vecchie versioni dei nodi.

Questa sezione tratta le operazioni di manutenzione relative alla funzione di controllo delle versioni di AEM. La Elimina versione strumento è destinato a eliminare le versioni di un nodo o una gerarchia di nodi nel tuo archivio. Il suo scopo principale è quello di aiutarti a ridurre le dimensioni dell’archivio rimuovendo le vecchie versioni dei nodi.

Panoramica overview

La Eliminare le versioni lo strumento è disponibile nella Strumenti console sotto Controllo delle versioni o direttamente da:

https://<server>:<port>/etc/versioning/purge.html

screen_shot_2012-03-15at14418pm

Percorso iniziale Un percorso assoluto su cui deve essere fatta la pulizia. È possibile selezionare il Percorso iniziale facendo clic sul navigatore della struttura dell'archivio.

Ricorsivo Durante l'eliminazione dei 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 da mantenere Il numero massimo di versioni da mantenere per un nodo. Quando questo numero supera questo valore, le versioni meno recenti vengono eliminate.

Età massima della 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 delle versioni del contenuto è definita e non può essere ripristinata senza il ripristino di un backup, lo strumento Purge Versions 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 l'eliminazione delle versioni sul nodo definito dal Percorso iniziale.

Rimozione di versioni di un sito Web purging-versions-of-a-web-site

Per eliminare le versioni di un sito Web, procedere come segue:

  1. Passa a Strumenti console, seleziona Controllo delle versioni e fai doppio clic Eliminare le versioni.

  2. Imposta il percorso iniziale del contenuto da eliminare (ad es. /content/geometrixx-outdoors).

    • Per eliminare solo il nodo definito dal percorso, deselezionare Ricorsivo.
    • Se desideri eliminare il nodo definito dal percorso e dai relativi discendenti, seleziona Ricorsivo.
  3. Imposta il numero massimo di versioni (per ogni nodo) che desideri mantenere. Lascia vuoto per non utilizzare questa impostazione.

  4. Imposta l'età massima della versione in giorni (per ogni nodo) che desideri mantenere. Lascia vuoto per non utilizzare questa impostazione.

  5. Fai clic su Prova a secco per visualizzare un'anteprima del processo di eliminazione.

  6. Fai clic su Elimina per avviare il processo.

CAUTION
I nodi eliminati non possono essere ripristinati senza il ripristino dell'archivio. È necessario prendersi cura della configurazione, quindi si consiglia di eseguire sempre una prova prima di eliminare.

Analisi della console analyzing-the-console

La Prova a secco e Elimina I processi elencano tutti i nodi che sono stati 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 ha alcuna versione e viene ignorato durante il processo.
  • retained: il nodo non viene eliminato.
  • purged: il nodo viene eliminato.

Inoltre, la console fornisce utili informazioni sulle versioni:

  • V 1.0: il numero di versione.
  • V 1.0.1*: la stella indica che la versione è quella corrente.
  • Thu Mar 15 2012 08:37:32 GMT+0100: la data della versione.

Nell’esempio seguente:

  • La Camicie le versioni vengono eliminate perché la loro età di versione è superiore a 2 giorni.
  • La Moda Tonga! le versioni vengono eliminate perché il loro numero di versioni è maggiore di 5.

global_version_screenshot

Utilizzo dei record di controllo e dei file di registro working-with-audit-records-and-log-files

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

Utilizzo dei registri working-with-logs

AEM WCM registra i registri dettagliati. Dopo aver decompresso e avviato Quickstart, puoi trovare i log in:

  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotazione dei file di registro log-file-rotation

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:

  • La error.log il file viene rinominato in base al pattern {original_filename} .yyyy-MM-dd. Ad esempio, l’11 luglio 2010, il file di registro corrente viene rinominato error.log-2010-07-10, quindi un nuovo error.og viene creato.
  • I file di log precedenti non vengono eliminati, quindi è tua responsabilità pulire i vecchi file di log periodicamente per limitare l'utilizzo del disco.
NOTE
Se aggiorni l'installazione AEM, tieni presente che qualsiasi file di registro esistente non più utilizzato da AEM rimarrà sul disco. Puoi rimuoverli senza rischi. Tutte le nuove voci di registro verranno scritte nei nuovi file di registro.

Ricerca dei file di registro finding-the-log-files

Sul file server in cui è stato installato AEM vengono memorizzati diversi file di registro:

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log

      Tutte le richieste di accesso a AEM WCM e all’archivio sono registrate qui.

    • audit.log

      Le azioni di moderazione sono registrate qui.

    • error.log

      I messaggi di errore (con diversi livelli di gravità) sono registrati qui.

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log

      Questo registro viene utilizzato solo se gli elementi multimediali dinamici sono abilitati. Fornisce informazioni statistiche e analitiche utilizzate per analizzare il comportamento del processo interno ImageServer.

    • request.log

      Ogni richiesta di accesso viene registrata qui insieme alla risposta.

    • s7access-<yyyy>-<mm>-<dd>.log

      Questo registro viene utilizzato solo se gli elementi multimediali dinamici sono abilitati. Il registro s7access registra ogni richiesta effettuata a Dynamic Media tramite /is/image e /is/content.

    • stderr.log

      Contiene i messaggi di errore, generati durante l'avvio, di nuovo con diversi livelli di gravità. Per impostazione predefinita, il livello di registro è impostato su Warning ( WARN)

    • stdout.log

      Blocca i messaggi di registrazione che indicano gli eventi durante l'avvio.

    • upgrade.log

      Fornisce un registro di tutte le operazioni di aggiornamento eseguite da com.day.compat.codeupgrade e com.adobe.cq.upgradesexecutor pacchetti.

  • <cq-installation-dir>/crx-quickstart/repository

    • revision.log

      Informazioni sulla registrazione delle revisioni.

NOTE
I registri ImageServer e s7access non sono inclusi nella variabile Scarica pacchetto generato dalla system/console/status-Bundlelist pagina. A scopo di supporto, in caso di problemi con Dynamic Media, aggiungi anche i registri ImageServer e s7access quando contatti l’Assistenza clienti.

Attivazione del livello di registro DEBUG activating-the-debug-log-level

Livello di registro predefinito Configurazione della registrazione Apache Sling è Information, quindi i messaggi di debug non vengono registrati.

Per attivare il livello di log di debug per un logger, impostare la proprietà org.apache.sling.commons.log.level per eseguire il debug nell'archivio. Ad esempio, su /libs/sling/config/org.apache.sling.commons.log.LogManager per configurare registrazione globale di Apache Sling.

CAUTION
Non lasciare il registro a livello di log di debug più a lungo del necessario, in quanto genera molte voci di log, consumando quindi risorse.

Una riga nel file di debug solitamente inizia con DEBUG, quindi fornisce il livello di log, l'azione di installazione e il messaggio di log. Ad esempio:

DEBUG 3 WebApp Panel: WebApp successfully deployed

I livelli di log sono i seguenti:

0
Errore irreversibile
L'azione non è riuscita e non è possibile continuare l'installazione.
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 si sono verificati problemi. AEM WCM potrebbe funzionare correttamente o meno.
3
Informazioni
L'azione è riuscita.

Creare un file di registro personalizzato create-a-custom-log-file

NOTE
Quando si lavora con Adobe Experience Manager, esistono diversi metodi per gestire le impostazioni di configurazione per tali servizi; vedere Configurazione di OSGi per ulteriori dettagli e procedure consigliate.

In alcune circostanze è possibile creare un file di registro personalizzato con un livello di registro diverso. Puoi eseguire questa operazione nell’archivio:

  1. Se non esiste già, crea una nuova cartella di configurazione ( sling:Folder) per il progetto /apps/<project-name>/config.

  2. Sotto /apps/<project-name>/config, crea un nodo per il nuovo Configurazione del logger di registrazione Sling di Apache:

    • Nome:

    org.apache.sling.commons.log.LogManager.factory.config-<identifier> (poiché si tratta di un logger)

    Dove <identifier> viene sostituito dal 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
    note note
    NOTE
    Sebbene non si tratti di un requisito tecnico, è opportuno <identifier> unico.
  3. Imposta le seguenti proprietà su questo nodo:

    • Nome: org.apache.sling.commons.log.file

      Tipo: Stringa

      Valore: specificare il file di registro; ad esempio, logs/myLogFile.log

    • Nome: org.apache.sling.commons.log.names

      Tipo: String[] (String + Multi)

      Valore: specifica i servizi OSGi per i quali il logger registra i messaggi; ad esempio, tutti gli elementi seguenti:

      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nome: org.apache.sling.commons.log.level

      Tipo: Stringa

      Valore: specifica il livello di log richiesto ( debug, info, warn o error); per esempio debug

    • Configura gli altri parametri come richiesto:

      • Nome: org.apache.sling.commons.log.pattern

        Tipo: String

        Valore: specificare il pattern del messaggio di log come richiesto; ad esempio,

        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    note note
    NOTE
    org.apache.sling.commons.log.pattern supporta fino a sei argomenti.
    {0} La marca temporale del tipo java.util.Date
    {1} indicatore di registro
    {2} nome del thread corrente
    {3} nome del logger
    {4} livello di registro
    {5} messaggio di log
    Se la chiamata di registro include un Throwable stacktrace viene aggiunto al messaggio.
    note caution
    CAUTION
    org.apache.sling.commons.log.names deve avere un valore.
    note note
    NOTE
    I percorsi degli autori di log sono relativi crx-quickstart posizione.
    Pertanto, un file di registro specificato come:
    logs/thelog.log
    scrive su:
    <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/
    (ovvero accanto a <cq-installation-dir>/crx-quickstart/)
  4. Questo passaggio è necessario solo quando è necessario un nuovo Writer (ad esempio con una configurazione diversa da quella predefinita di Writer).

    note caution
    CAUTION
    È necessaria una nuova configurazione di Registratore solo quando il valore predefinito esistente non è adatto.
    Se non è configurato alcun writer esplicito, il sistema genererà automaticamente un writer implicito in base al valore predefinito.

    Sotto /apps/<project-name>/config, crea un nodo per il nuovo Configurazione di Apache Sling Logging Writer:

    • Nome: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (in quanto si tratta di uno scrittore)

      Come per il logger, <identifier> viene sostituito dal 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

    note note
    NOTE
    Sebbene non si tratti di un requisito tecnico, è opportuno <identifier> unico.

    Imposta le seguenti proprietà su questo nodo:

    • Nome: org.apache.sling.commons.log.file

      Tipo: String

      Valore: specifica il file di registro in modo che corrisponda al file specificato nel logger;

      per questo esempio, ../logs/myLogFile.log.

    • Configura gli altri parametri come richiesto:

      • Nome: org.apache.sling.commons.log.file.number

        Tipo: Long

        Valore: specificare il numero di file di registro che si desidera conservare; ad esempio, 5

      • Nome: org.apache.sling.commons.log.file.size

        Tipo: String

        Valore: specificare come necessario per controllare la rotazione dei file per dimensione/data; ad esempio, '.'yyyy-MM-dd

    note note
    NOTE
    org.apache.sling.commons.log.file.size controlla la rotazione del file di log 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 dimensione con un numero. Se non viene fornito alcun indicatore di dimensione, questo viene preso come numero di byte, oppure è possibile aggiungere uno degli indicatori di dimensione - KB, MBoppure GB (il caso viene ignorato).
    • È possibile specificare una pianificazione di ora/data come java.util.SimpleDateFormat modello. Definisce il periodo di tempo dopo il quale il file verrà ruotato; anche il suffisso aggiunto al file ruotato (per l'identificazione).
    Il valore predefinito è '.'aaaa-MM-gg (per la rotazione giornaliera del registro).
    Ad esempio, a mezzanotte del 20 gennaio 2010 (o quando si verifica per precisione il primo messaggio di log), …/logs/error.log verrà rinominato in …/logs/error.log.2010-01-20. La registrazione per il 21 gennaio verrà trasmessa a (un nuovo e vuoto) …/logs/error.log fino a quando non viene effettuata il rollover al cambio di giorno successivo.
    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2
    '.'yyyy-MM Rotazione all'inizio di ogni mese
    '.'yyyy-ww La rotazione al primo giorno di ogni settimana (dipende dalle impostazioni internazionali).
    '.'yyyy-MM-dd Rotazione a mezzanotte ogni giorno.
    '.'yyyy-MM-dd-a Rotazione a mezzanotte e 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 eseguire l’escape del testo letterale all’interno di una coppia di virgolette singole (' ');

      per evitare che determinati caratteri vengano interpretati come lettere del pattern.

    2. Utilizza solo i caratteri consentiti per un nome di file valido in qualsiasi punto dell’opzione .

  5. Leggere il nuovo file di log con lo strumento scelto.

    Il file di registro creato da questo esempio sarà ../crx-quickstart/logs/myLogFile.log.

La console Felix fornisce anche informazioni sul supporto per i log Sling all'indirizzo ../system/console/slinglog; per esempio http://localhost:4502/system/console/slinglog.

Ricerca dei record di audit finding-the-audit-records

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

AEM dei record di controllo WCM visualizzati durante l’authoring delle pagine aem-wcm-audit-records-shown-when-page-authoring

  1. Apri una pagina.

  2. Dalla barra laterale potete selezionare la scheda con l’icona a forma di lucchetto, quindi fare doppio clic su Registro di controllo…

  3. Viene visualizzata una nuova finestra che mostra l’elenco dei record di controllo per la pagina corrente.

    screen_shot_2012-02-02at43601pm

  4. Fai clic su OK quando si desidera chiudere la finestra.

AEM i record di WCM Auditing all’interno dell’archivio aem-wcm-auditing-records-within-the-repository

All'interno di /var/audit i record di controllo vengono memorizzati in base alla risorsa. È possibile approfondire la ricerca 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 controllo OSGi dalla console Web osgi-audit-records-from-the-web-console

Gli eventi OSGi generano anche record di audit che possono essere visti dalla Stato della configurazione scheda -> File di registro nella AEM Web Console:

screen_shot_2012-02-13at50346pm

Monitoraggio degli agenti di replica monitoring-your-replication-agents

È possibile monitorare 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 richieste code per disabili?

  • tutto enabled Le code devono avere lo stato idle o active, che indicano il normale funzionamento; nessuna coda blocked, che è spesso un segno di problemi dal lato dei ricevitori.

  • se le dimensioni della coda aumentano nel tempo, ciò può indicare una coda bloccata.

Per monitorare un agente di replica:

  1. Accedere al Strumenti in AEM.

  2. Fai clic su Replica.

  3. Fare doppio clic sul collegamento agli agenti per l’ambiente appropriato (nel riquadro a sinistra o a destra); per esempio Agenti sull'autore.

    La finestra risultante mostra una panoramica di tutti gli agenti di replica per l’ambiente di authoring, inclusi la destinazione e lo stato.

  4. Fai clic sul nome dell'agente appropriato (che è un collegamento) per visualizzare informazioni dettagliate su tale agente:

    chlimage_1-8

    È possibile:

    • Controlla se l'agente è abilitato.
    • Visualizza il target di qualsiasi replica.
    • Controlla se la coda di replica è attualmente attiva (abilitata).
    • Controlla se ci sono elementi nella coda.
    • Aggiorna o Cancella aggiornare la visualizzazione delle voci della coda; questo consente di vedere gli elementi entrare e uscire dalla coda.
    • Visualizza registro per accedere al registro di eventuali azioni dell'agente di replica.
    • Prova connessione all’istanza target.
    • Forza nuovo tentativo su qualsiasi elemento della coda, se necessario.
    note caution
    CAUTION
    Non utilizzare il collegamento "Prova connessione" per la casella in uscita Replicazione inversa in un'istanza di pubblicazione.
    Se viene eseguito un test di replica per una coda in uscita, tutti gli elementi più vecchi della 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']

Anche in questo caso è possibile sviluppare una soluzione per rilevare tutti gli agenti di replica (che si trovano in /etc/replication/author o /etc/replication/publish), quindi controlla lo stato dell'agente ( enabled, disabled) e la coda sottostante ( active, idle, blocked).

Monitoraggio delle prestazioni monitoring-performance

Ottimizzazione delle prestazioni è un processo interattivo che viene messo a fuoco durante lo sviluppo. Dopo la distribuzione viene in genere rivisto dopo intervalli o eventi specifici.

I metodi utilizzati per la raccolta delle informazioni per l'ottimizzazione possono essere utilizzati anche per il monitoraggio continuo.

NOTE
Specifico configurazioni disponibili per migliorare le prestazioni può anche essere controllato.

Di seguito sono elencati i problemi di prestazioni comuni che si verificano, nonché le proposte su come individuarli e contrastarli.

Area
Sintomi
Per aumentare la capacità…
Per ridurre il volume…
Client
Utilizzo elevato della CPU client.
Installa una CPU client con prestazioni migliori.
Semplifica il layout (HTML).
Utilizzo ridotto della CPU del server.
Effettua l’aggiornamento a un browser più veloce.
Migliorare la cache lato client.
Alcuni clienti veloci, un po' lenti.
Server
Rete
Utilizzo ridotto della CPU sia sui server che sui client.
Rimuovere i colli di bottiglia della rete.
Migliorare/ottimizzare la configurazione della cache client.
La navigazione locale sul server è (relativamente) veloce.
Aumento della larghezza di banda della rete.
Riduci il "peso" delle pagine web (ad esempio, meno immagini, ottimizzato HTML).
Server web
L'utilizzo della CPU sul server web è elevato.
Cluster dei server web.
Riduci gli hit per pagina (visita).
Utilizzare un load-balancer hardware.
Applicazione
L'utilizzo della CPU del server è elevato.
Cluster delle istanze AEM.
Cerca ed elimina i log della CPU e della memoria (utilizza la revisione del codice, l'output di temporizzazione, ecc.).
Consumo elevato di memoria.
Migliorare la memorizzazione in cache a tutti i livelli.
Tempi di risposta ridotti.
Ottimizza 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, inclusi rallentamenti temporanei nella velocità di connessione, nel carico della CPU e molto altro.

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 riscontrare un problema di prestazioni:

    • raccogliere il maggior numero possibile di informazioni per acquisire una buona conoscenza operativa del sistema in circostanze normali
  • Quando si verifica un problema di prestazioni:

    • prova a replicarlo con uno (o preferibilmente più) browser web standard, su un client diverso che sai avere buone prestazioni generali e/o sul server stesso (se possibile)

    • controlla se qualcosa (correlato al sistema) è cambiato entro uno spazio di tempo appropriato e se una di queste modifiche potrebbe avere influenzato le prestazioni

    • poni domande quali:

      • il problema si verifica solo in momenti specifici?
      • il problema si verifica solo su pagine specifiche?
      • sono interessate altre richieste?
    • raccogliere il maggior numero possibile di informazioni da confrontare con la vostra conoscenza del sistema in circostanze normali:

Strumenti per il monitoraggio e l’analisi delle prestazioni tools-for-monitoring-and-analyzing-performance

Di seguito viene fornita una breve panoramica di alcuni degli strumenti disponibili per il monitoraggio e l’analisi delle prestazioni.

Alcune dipenderanno dal sistema operativo in uso.

Strumento
Utilizzato per analizzare...
Utilizzo / Ulteriori informazioni..
request.log
Tempi di risposta e concorrenza.
Interpretazione del request.log.
tronco/tratto
Caricamento pagina

Comandi Unix/Linux per tracciare chiamate di sistema e segnali. Aumenta il livello di log a INFO.

Analizza il numero di caricamenti di pagina per richiesta, quali pagine, ecc.

Immagini di thread
Osserva i thread JVM. Identificare le contese, le serrature e i corridori lunghi.

Dipende dal sistema operativo:
- Unix/Linux: kill -QUIT <pid>
- Windows (modalità console): Ctrl-Pausa

Sono disponibili anche strumenti di analisi, quali TDA.

Dump heap
Problemi di memoria esauriti che causano prestazioni lente.

Aggiungi:
-XX:+HeapDumpOnOutOfMemoryError
alla chiamata java a AEM.

Consulta la sezione Guida alla risoluzione dei problemi per Java SE 6 con HotSpot VM.

Chiamate di sistema
Identifica i problemi di temporizzazione.

Chiamate a System.currentTimeMillis() o com.day.util.Timing viene utilizzato per generare marche temporali dal codice o tramite commenti di HTML.

Nota: che devono essere attuate in modo da poter essere attivate o disattivate secondo necessità; quando un sistema funziona senza problemi, il sovraccarico della raccolta delle statistiche non sarà necessario.

Banco Apache
Identifica le perdite di memoria, analizza in modo selettivo il tempo di risposta.

utilizzo di base:

ab -k -n <requests> -c <concurrency> <url>

Vedi Banco Apache e ab man page per informazioni complete.

Analisi della ricerca
Esegui le query di ricerca offline, identifica il tempo di risposta della query, verifica e conferma il set di risultati.
JMeter
Prove di carico e di funzionamento.
https://jakarta.apache.org/jmeter/
JProfiler
Profondità della CPU e del profiling della memoria.
https://www.ej-technologies.com/
JConsole
Osserva le metriche e i thread JVM.

Utilizzo: jconsole

Vedi jconsole e Monitoraggio delle prestazioni tramite JConsole.

Nota: Con JDK 1.6, JConsole è estensibile con i plug-in; ad esempio, Top o TDA (Thread Dump Analyzer).

Java VisualVM
Osserva le metriche, i thread, la memoria e il profiling di JVM.

Utilizzo: jvisualvm o visualvm

Vedi jvisualvm, visualizzazione e Monitoraggio delle prestazioni utilizzando (J)VisualVM.

Nota: Con JDK 1.6, VisualVM è estensibile con i plug-in.

truss/strass, lsof
Analisi approfondita del processo e della chiamata del kernel (Unix).
Comandi Unix/Linux.
Statistiche di temporizzazione
Vedi le statistiche di temporizzazione per il rendering della pagina.
Per visualizzare le statistiche di temporizzazione per il rendering della pagina è possibile utilizzare Ctrl+Maiusc+U insieme ?debugClientLibs=true nell’URL.
Strumento di profilazione della CPU e della memoria
Utilizzato per l'analisi delle richieste lente durante lo sviluppo.
Ad esempio: YourKit.
Raccolta informazioni
Lo stato in corso dell'installazione.
Conoscere il più possibile l'installazione può anche aiutarti a tracciare cosa potrebbe aver causato un cambiamento delle prestazioni e se queste modifiche sono giustificate. Queste metriche devono essere raccolte a intervalli regolari per poter vedere facilmente cambiamenti significativi.

Interpretazione del request.log interpreting-the-request-log

Questo file registra informazioni di base su ogni richiesta effettuata a AEM. Da queste preziose conclusioni si possono trarre.

La request.log offre un modo integrato per vedere quanto tempo richiedono le richieste. Ai fini dello sviluppo è utile tail -f la request.log e controlla i tempi di risposta lenti. Per analizzare un request.log consigliamo utilizzo di rlog.jar che consente di ordinare e filtrare i tempi di risposta.

Si consiglia di isolare le pagine "lente" dal request.logquindi ottimizzarli individualmente per ottenere prestazioni migliori. In genere questo viene fatto includendo le metriche delle prestazioni per componente o utilizzando uno strumento di profilazione delle prestazioni come [yourkit](https://www.yourkit.com/).

Monitoraggio del traffico sul sito web monitoring-traffic-on-your-website

Il registro delle richieste registra ogni richiesta effettuata, unitamente alla risposta effettuata:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Sommando tutte le voci del GET in un determinato periodo (ad esempio per diversi periodi di 24 ore) è possibile fare dichiarazioni sul traffico medio del sito web.

Monitoraggio dei tempi di risposta con request.log monitoring-response-times-with-the-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 log si presenta come segue (le linee sono 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.

  • 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 queste, puoi 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 monitoring-search-response-times-with-the-request-log

Le richieste di ricerca sono anche registrate 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

Quindi, come sopra, puoi usare 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 e cosa può essere fatto per migliorare la risposta.

Monitoraggio del numero e dell’impatto degli utenti simultanei monitoring-the-number-and-impact-of-concurrent-users

Ancora una volta request.log può essere utilizzato per monitorare la concorrenza e la reazione del sistema.

È necessario eseguire dei test per determinare quanti utenti simultanei il sistema può gestire prima di vedere un impatto negativo. Anche in questo caso gli script possono essere utilizzati per estrarre i risultati dal file di log:

  • monitorare quante richieste vengono effettuate entro un intervallo di tempo specifico, ad esempio un minuto
  • verificare gli effetti di un numero specifico di utenti che presentano contemporaneamente le stesse richieste (il più vicino possibile); Ad esempio, 30 utenti che fanno clic su Salva allo stesso tempo.
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 lunghi using-rlog-jar-to-find-requests-with-long-duration-times

AEM include vari strumenti di supporto in:
<cq-installation-dir>/crx-quickstart/opt/helpers

Uno di questi, rlog.jar, può essere utilizzato per ordinare rapidamente request.log in modo che le richieste vengano visualizzate per durata, dal tempo più lungo al più breve.

Il comando seguente 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, puoi eseguirlo specificando request.log come parametro , mostra 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

Potrebbe essere necessario concatenare l’utente request.log file se è necessario eseguire questa operazione su un esempio di dati di grandi dimensioni.

Banco Apache apache-bench

Per ridurre al minimo l’impatto di casi speciali (come raccolta rifiuti, ecc.), si consiglia di utilizzare uno strumento come apachebench (vedi ad esempio, ab per ulteriore documentazione) 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 laptop 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, in tutte le richieste simultanee; vedere Time per request: 54.595 [ms] (media, in tutte le richieste simultanee). È possibile modificare il valore del parametro della concorrenza -c (numero di richieste multiple da eseguire alla volta) per visualizzare eventuali effetti.

Contatori richieste request-counters

Informazioni sul traffico della richiesta (numero di richieste durante un periodo di tempo specifico) forniscono un’indicazione del carico sull’istanza. Queste informazioni possono essere estratte da request.log, anche se l’utilizzo dei contatori automatizza la raccolta dati per consentirti di visualizzare:

  • differenze significative nell’attività (ossia distinguere tra "molte richieste" e "scarsa attività")
  • quando un'istanza non viene utilizzata
  • eventuali riavvii (i contatori vengono reimpostati su 0)

Per automatizzare la raccolta di informazioni è inoltre possibile installare RequestFilter per incrementare un contatore per ogni richiesta. È possibile utilizzare più contatori per diversi periodi di tempo.

Le informazioni raccolte possono essere utilizzate per indicare:

  • cambiamenti significativi nell'attività
  • un'istanza ridondante
  • eventuali riavvii (reimpostazione del contatore su 0)

Commenti di HTML html-comments

È consigliabile che ogni progetto includa html comments per le prestazioni del server. Si possono trovare molti buoni esempi pubblici; seleziona una pagina, apri l’origine della pagina per la visualizzazione e scorri verso il basso, facendo clic sul codice seguente:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitoraggio delle prestazioni tramite JConsole monitoring-performance-using-jconsole

Comando dello strumento jconsole è disponibile con il JDK.

  1. Avvia la tua istanza AEM.

  2. Esegui jconsole.

  3. Seleziona la tua istanza AEM e Connetti.

  4. Da all’interno di Local applicazione, doppio clic com.day.crx.quickstart.Main; la Panoramica verrà visualizzata come predefinita:

    chlimage_1-87

    Dopo questo è possibile selezionare altre opzioni.

Monitoraggio delle prestazioni utilizzando (J)VisualVM monitoring-performance-using-j-visualvm

A partire da JDK 1.6, il comando dello strumento jvisualvm è disponibile. Dopo aver installato JDK 1.6 è possibile:

  1. Avvia la tua istanza AEM.

    note note
    NOTE
    Se utilizzi Java 5 puoi aggiungere la variabile -Dcom.sun.management.jmxremote argomento della riga di comando java che avvia la JVM. JMX è abilitato per impostazione predefinita con Java 6.
  2. Esegui:

    • jvisualvm: nella cartella JDK 1.6 bin (versione testata)
    • visualvm: può essere scaricato da VisualVM (versione del bordo di dissanguamento)
  3. Da all’interno di Local applicazione, doppio clic com.day.crx.quickstart.Main; la Panoramica verrà visualizzata come predefinita:

    chlimage_1-88

    Dopo di questo, puoi selezionare altre opzioni, tra cui Monitor:

    chlimage_1-89

Puoi usare questo strumento per generare immagini di thread e immagini di testina di memoria. Queste informazioni sono spesso richieste dal team di assistenza tecnica.

Raccolta informazioni information-collection

Conoscere il più possibile l'installazione può aiutarti a tracciare cosa potrebbe aver causato un cambiamento delle 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? how-many-authors-are-working-with-the-system

Per visualizzare il numero di autori che hanno utilizzato il sistema dopo l’installazione, utilizza 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 a 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? what-is-the-average-number-of-page-activations-per-day

Per visualizzare il numero totale di attivazioni di pagina dall'installazione del server utilizzando una query del repository; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:AuditEvent)[@cq:type='Activate']

Calcolare quindi il numero di giorni trascorsi dall'installazione per calcolare la media.

Quante pagine si gestiscono attualmente in questo sistema? how-many-pages-do-you-currently-maintain-on-this-system

Per visualizzare il numero di pagine attualmente presenti sul server, utilizzare una query del repository; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:Page)

Se utilizzi MSM, qual è il numero medio di rollout al mese? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Per determinare il numero totale di rollout dall'installazione utilizzando una query del repository; via 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? what-is-the-average-number-of-live-copies-per-month

Per determinare il numero totale di Live Copy effettuate dall’installazione utilizzando una query dell’archivio; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:LiveSyncConfig)

Utilizzare nuovamente il numero di mesi trascorsi dall'installazione per calcolare la media.

Se utilizzi AEM Assets, quante risorse gestisci attualmente in Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Per vedere quante risorse DAM si gestiscono attualmente, utilizza una query dell’archivio; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query /jcr:root/content/dam//element(*, dam:Asset)

Qual è la dimensione media delle risorse? what-is-the-average-size-of-the-assets

Per determinare la dimensione totale del /var/dam cartella:

  1. Utilizzare WebDAV per mappare l'archivio sul file system locale.

  2. Utilizzare la riga di comando:

    code language-shell
    cd /Volumes/localhost/var
    du -sh dam/
    

    Per ottenere la dimensione media, dividi la dimensione globale per il numero totale di risorse in /var/dam (ottenuto sopra).

Quanti modelli sono attualmente utilizzati? how-many-templates-are-currently-used

Per visualizzare il numero di modelli attualmente sul server, utilizzare una query del repository; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:Template)

Quanti componenti sono attualmente utilizzati? how-many-components-are-currently-used

Per visualizzare il numero di componenti attualmente presenti sul server, utilizzare una query del repository; via CRXDE - Strumenti - Query:

  • Tipo XPath

  • Percorso /

  • Query //element(*, cq:Component)

Quante richieste all'ora hai sul sistema di authoring in fase di picco? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Per determinare le richieste all’ora sul sistema di authoring in fase di picco:

  1. Per determinare il numero totale di richieste dall'installazione, utilizzare la riga di comando:

    code language-shell
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
  2. Per determinare le date di inizio e di fine:

    code language-shell
    vim request.log
    G / 1G: for the last/first lines
    

    Utilizzare questi valori per calcolare il numero di ore trascorse dall'installazione, quindi il numero medio di richieste all'ora.

Quante richieste all'ora sul sistema di pubblicazione in fase di picco? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Ripeti la procedura descritta sopra sull’istanza di pubblicazione.

Analisi di scenari specifici analyzing-specific-scenarios

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

CPU al 100% cpu-at

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

Memoria esaurita out-of-memory

Anche se tali errori devono essere rilevati durante lo sviluppo e i test, alcuni scenari possono scivolare nel vuoto.

Se la memoria del sistema è esaurita, questo può essere visualizzato in vari modi, tra cui degradazione delle prestazioni e messaggi di errore, tra cui il sottotesto:

java.lang.OutOfMemoryError

In questi casi controlla:

I/O disco disk-i-o

Se il sistema è a corto di spazio su disco o se noti che il disco sta battendo all'inizio vedi:

Degradazione regolare delle prestazioni regular-performance-degradation

Se si verifica un deterioramento delle prestazioni dell'istanza dopo ogni riavvio (a volte una settimana o più tardi), è possibile controllare quanto segue:

Ottimizzazione JVM jvm-tuning

Java Virtual Machine (JVM) è notevolmente migliorata per quanto riguarda la messa a punto (soprattutto da Java 7). Per questo motivo, spesso è opportuno 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 regolare la JVM; questo può includere fattori di monitoraggio, tra cui le dimensioni dell'heap, l'algoritmo e altri aspetti.

Alcune scelte comuni sono:

  • VerboseGC:

    code language-none
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    

Il registro risultante può essere acquisito da un visualizzatore GC, ad esempio:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Oppure JConsole:

  • Queste impostazioni sono per una connessione JMX "wide open":

    code language-none
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
  • Quindi collegarsi alla JVM con la JConsole; vedi:
    [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 ti aiuterà a vedere quanta memoria viene utilizzata, quali algoritmi GC vengono utilizzati, quanto tempo ci vuole per l'esecuzione e quale effetto ha sulle prestazioni dell'applicazione. Senza questo, sintonizzarsi è solo "manopole casuali di aggancio".

NOTE
Per la VM di Oracle sono disponibili anche le informazioni all'indirizzo:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html
recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56