Show Menu
ARGOMENTI×

Pulizia revisioni

Introduzione

Ogni aggiornamento al repository crea una nuova revisione del contenuto. Di conseguenza, con ogni aggiornamento le dimensioni del repository aumentano. Per evitare una crescita incontrollata del repository, le vecchie revisioni devono essere pulite per liberare risorse su disco. Questa funzionalità di manutenzione è denominata Revision Cleanup (Pulizia revisioni). È disponibile come routine offline da AEM 6.0.
Con AEM 6.3 è stata introdotta una versione online di questa funzionalità, denominata Pulizia revisioni online. Rispetto alla funzione di pulizia revisioni offline in cui l’istanza di AEM deve essere chiusa, è possibile eseguire la pulizia revisioni online mentre l’istanza di AEM è online. Pulizia revisioni online è attivata per impostazione predefinita ed è il metodo consigliato per eseguire una pulizia revisioni.
Nota : Per un’introduzione consultate il video e come utilizzare la funzione Pulizia revisioni online.
Il processo di pulizia della revisione è costituito da tre fasi: stima , compattazione e pulizia . La stima determina se eseguire o meno la fase successiva (compazione) in base alla quantità di rifiuti che potrebbe essere raccolta. Durante la fase di compattazione i segmenti e i file tar vengono riscritti, lasciando fuori qualsiasi contenuto inutilizzato. La fase di pulizia in seguito rimuove i vecchi segmenti, inclusi eventuali rifiuti che potrebbero contenere. In genere, la modalità offline può recuperare più spazio perché la modalità online deve tenere conto del set di lavoro di AEM, che consente di mantenere ulteriori segmenti da raccogliere.
Per ulteriori dettagli sulla pulizia delle revisioni, consultate i seguenti collegamenti:
È inoltre possibile leggere la documentazione ufficiale Oak.

Quando utilizzare la funzione di pulizia revisioni online invece della funzione di pulizia revisioni offline?

Pulizia revisioni online è il metodo consigliato per eseguire la pulizia revisioni. La pulizia della revisione offline deve essere utilizzata solo in modo eccezionale, ad esempio prima di eseguire la migrazione al nuovo formato di storage o se l'Assistenza clienti Adobe richiede tale operazione.

Come eseguire la pulizia revisioni online

Per impostazione predefinita, la funzione Pulizia revisioni online è configurata per essere eseguita automaticamente una volta al giorno sia nelle istanze di AEM Author che Publish. È sufficiente definire la finestra di manutenzione durante un periodo con la minore attività utente. È possibile configurare l'attività Pulizia revisioni online come segue:
  1. Nella finestra principale di AEM, andate a Strumenti - Operazioni - Dashboard - Manutenzione o fate clic sul browser per: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
  2. Passa il cursore del mouse sulla finestra Manutenzione giornaliera e fai clic sull’icona Impostazioni .
  3. Immettete i valori desiderati (ricorrenza, ora di inizio e ora di fine) e fate clic su Salva .
In alternativa, se si desidera eseguire manualmente l'attività di pulizia revisioni, è possibile:
  1. Vai a Strumenti - Operazioni - Dashboard - Manutenzione o passa direttamente a https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
  2. Fare clic sulla finestra Manutenzione giornaliera.
  3. Passate il puntatore del mouse sull'icona Revision Cleanup (Pulizia revisione).
  4. Fate clic su Esegui .

Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline

Il processo di pulizia revisioni richiama le precedenti revisioni per generazioni. Ciò significa che ogni volta che si esegue la pulizia revisioni viene creata e mantenuta sul disco una nuova generazione. Esiste tuttavia una differenza tra i due tipi di pulizia revisioni: la pulizia delle revisioni offline consente di mantenere una generazione mentre la pulizia delle revisioni online consente di mantenere due generazioni. Pertanto, quando si esegue la pulizia delle revisioni online dopo la revisione offline, si verifica quanto segue:
  1. Dopo la prima esecuzione della pulizia della revisione online, la dimensione del repository raddoppierà. Ciò accade perché ora ci sono due generazioni che vengono conservate sul disco.
  2. Durante le esecuzioni successive, il repository crescerà temporaneamente durante la creazione della nuova generazione e quindi stabilizzerà nuovamente le dimensioni che aveva dopo la prima esecuzione, in quanto il processo di pulizia della revisione online rireclama la generazione precedente.
Inoltre, tenete presente che, a seconda del tipo e del numero di commit, ogni generazione può variare in dimensione rispetto a quella precedente, in modo che la dimensione finale possa variare da un'esecuzione all'altra.
Per questo motivo, si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione del repository inizialmente stimata.

Modalità Di Compattazione Completa E Coda

AEM 6.5 introduce due nuove modalità per la fase di compattazione del processo di pulizia delle revisioni online:
  • La modalità di compattazione ​completa riscrive tutti i segmenti e i file tar nell'intero repository. La successiva fase di pulizia può quindi rimuovere la quantità massima di rifiuti nel repository. Poiché la compattazione completa interessa l'intero repository, richiede una notevole quantità di risorse di sistema e tempo per il completamento. La compattazione completa corrisponde alla fase di compattazione in AEM 6.3.
  • La modalità di compattazione ​della coda riscrive solo i segmenti e i file tar più recenti presenti nella directory archivio. I segmenti e i file tar più recenti sono quelli aggiunti dall’ultima esecuzione della compattazione completa o coda. La successiva fase di pulizia può quindi rimuovere solo i rifiuti contenuti nella parte recente del repository. Poiché la compattazione di coda interessa solo una parte del repository, richiede molto meno risorse di sistema e tempo per il completamento rispetto alla compattazione completa.
Queste modalità di compattazione costituiscono un compromesso tra efficienza e consumo delle risorse: mentre la compattazione della coda è meno efficace ha anche un minore impatto sul normale funzionamento del sistema. Al contrario, la compattazione completa è più efficace ma ha un impatto maggiore sul normale funzionamento del sistema.
AEM 6.5 introduce inoltre un meccanismo di deduplicazione dei contenuti più efficiente durante la compattazione, che riduce ulteriormente l'ingombro sul disco del repository.
I due grafici riportati di seguito illustrano i risultati dei test di laboratorio interni che illustrano la riduzione dei tempi di esecuzione medi e l’impronta media su disco in AEM 6.5 rispetto a AEM 6.3:

Come configurare la compattazione completa e dettagliata

La configurazione predefinita esegue la compattazione della coda nei giorni della settimana e la compattazione completa la domenica. La configurazione predefinita può essere modificata utilizzando il nuovo valore full.gc.days di configurazione dell'attività RevisionCleanupTask di Come eseguire la pulizia revisioni online manutenzione.
Quando si configura il full.gc.days valore, tenere presente che la compattazione completa verrà eseguita nei giorni definiti nel valore e la compattazione coda verrà eseguita nei giorni non definiti nel valore. Ad esempio, se configuri la compattazione completa per l'esecuzione di domenica, la compattazione della coda verrà eseguita dal lunedì al sabato. Se, ad esempio, si configura la compattazione completa per l'esecuzione ogni giorno della settimana, la compattazione coda non verrà eseguita affatto.
Inoltre, prendere in considerazione che:
  • La compattazione della coda è meno efficace e ha meno impatto sulle normali operazioni del sistema. Essa è pertanto destinata ad essere eseguita durante le giornate lavorative.
  • La compattazione completa è più efficace ma ha anche un impatto maggiore sulle normali operazioni del sistema. È pertanto destinato ad essere utilizzato fuori dei giorni lavorativi.
  • Sia la compattazione della coda che la compattazione completa dovrebbero essere programmate per funzionare durante le ore di punta.

Risoluzione dei problemi

Quando si utilizzano le nuove modalità di compattazione, tenere presente quanto segue:
  • È possibile monitorare l'attività di ingresso/uscita (I/O), ad esempio: Operazioni I/O, CPU in attesa di IO, dimensione della coda di commit. Questo consente di determinare se il sistema sta diventando un binding di I/O e richiede il ridimensionamento.
  • Indica RevisionCleanupTaskHealthCheck lo stato di integrità generale della pulizia delle revisioni online. Funziona allo stesso modo di AEM 6.3 e non fa distinzione tra compattazione completa e compattazione coda.
  • I messaggi di registro contengono informazioni rilevanti sulle modalità di compattazione. Ad esempio, all'avvio della funzione Pulizia revisioni online, i messaggi di registro corrispondenti indicheranno la modalità compattazione. Inoltre, in alcuni casi d'angolo, il sistema tornerà alla compattazione completa quando era pianificato per eseguire una compattazione coda e i messaggi di registro indicheranno questa modifica. I seguenti esempi di registro indicano la modalità di compattazione e il passaggio dalla coda alla compattazione completa:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Limitazioni note

In alcuni casi, l'alternanza tra la coda e le modalità di compattazione completa ritarda il processo di pulizia. Più precisamente, il repository crescerà dopo una compattazione completa (raddoppierà le dimensioni). Lo spazio aggiuntivo verrà riutilizzato nella successiva compattazione della coda, quando il repository scenderà al di sotto della dimensione di compattazione precompleta. È inoltre necessario evitare l'esecuzione parallela delle attività di manutenzione.
Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione del repository inizialmente stimata.

Pulizia della revisione online - Domande frequenti

Considerazioni sull'aggiornamento AEM 6.5

Domande Risposte
Cosa devo sapere quando si effettua l’aggiornamento ad AEM 6.5?
Il formato di persistenza di TarMK cambierà con AEM 6.5. Queste modifiche non richiedono un passaggio di migrazione proattiva. I repository esistenti passeranno attraverso una migrazione continua, trasparente per l'utente. Il processo di migrazione viene avviato la prima volta che AEM 6.5 (o strumenti correlati) accede al repository.
Una volta avviata la migrazione al formato di persistenza AEM 6.5, l’archivio non può più essere ripristinato al precedente formato di persistenza AEM 6.3.

Migrazione alla barra dei segmenti Oak

Domande Risposte
Perché è necessario migrare il repository?
In AEM 6.3 erano necessarie modifiche al formato di storage, in particolare per migliorare le prestazioni e l'efficacia della pulizia delle revisioni online. Queste modifiche non sono compatibili con le versioni precedenti e i repository creati con il vecchio segmento Oak (AEM 6.2 e versioni precedenti) devono essere migrati.
Ulteriori vantaggi della modifica del formato di storage:
Il formato Tar precedente è ancora supportato? Con AEM 6.3 è supportato solo il nuovo segmento Oak.
La migrazione dei contenuti è sempre obbligatoria? Sì. Se non iniziate con una nuova istanza, dovrete sempre migrare il contenuto.
Posso effettuare l’aggiornamento alla versione 6.3 ed eseguire la migrazione in un secondo momento (ad esempio, utilizzando un’altra finestra di manutenzione)? No, come spiegato in precedenza, la migrazione dei contenuti è obbligatoria.
È possibile evitare i tempi di inattività durante la migrazione? No. Si tratta di uno sforzo una tantum che non può essere eseguito su un'istanza in esecuzione.
Cosa succede se si esegue accidentalmente un'esecuzione in base al formato di repository errato? Se si tenta di eseguire il modulo del segmento di rovere su un repository tar segmento-roak (o viceversa), l'avvio non riuscirà con un'eccezione IllegalStateException con il messaggio "Formato segmento non valido". Nessun danneggiamento dei dati.
Sarà necessario reindicizzare gli indici di ricerca? No. La migrazione dal segmento di quercia al segmento di quercia introduce modifiche nel formato contenitore. I dati contenuti non vengono modificati.
Come calcolare al meglio lo spazio su disco necessario durante e dopo la migrazione? La migrazione equivale a ricreare l'archivio segmenti nel nuovo formato. Questo può essere utilizzato per stimare lo spazio su disco aggiuntivo necessario durante la migrazione. Dopo la migrazione, il vecchio store di segmenti può essere eliminato per recuperare spazio.
Come stimare al meglio la durata della migrazione? Le prestazioni di migrazione possono essere notevolmente migliorate se la pulizia delle revisioni offline viene eseguita prima della migrazione. Tutti i clienti sono invitati a eseguirla come prerequisito del processo di aggiornamento. In generale, la durata della migrazione deve essere simile alla durata dell'attività di pulizia della revisione offline, partendo dal presupposto che l'attività di pulizia della revisione offline sia stata eseguita prima della migrazione.

Esecuzione pulizia revisioni online

Domande Risposte
Con quale frequenza deve essere eseguita la pulizia delle revisioni online? Una volta al giorno. Questa è la configurazione predefinita nel Pannello operazioni.
Come posso configurare l'ora di inizio dell'attività di manutenzione Pulizia revisioni online? Vedere Modalità di esecuzione della pulizia delle revisioni online.
Esiste una frequenza massima che non deve essere superata per la pulizia delle revisioni online? Si consiglia di eseguire la pulizia delle revisioni online una volta al giorno, come configurato per impostazione predefinita.
Quali sono gli indicatori chiave che determinano la frequenza con cui deve essere eseguita la pulizia delle revisioni online? Non è necessario determinare la frequenza, in quanto la funzione di pulizia revisioni online è configurata come attività di manutenzione e viene eseguita automaticamente ogni giorno.
Perché la pulizia della revisione online non recupera spazio se eseguita per la prima volta? Pulizia revisioni online recupera le vecchie revisioni per generazioni. Viene generata una nuova generazione ogni volta che viene eseguita la pulizia della revisione. Solo il contenuto che ha almeno due generazioni di età sarà riutilizzato, il che significa che in una prima fase non c'è nulla da recuperare.
Perché la prima Pulizia revisioni online non recupera spazio se eseguita dopo la pulizia revisioni offline?
Pulizia revisioni offline sta recuperando tutto tranne l'ultima generazione rispetto alle ultime due generazioni per la pulizia revisioni online. Nel caso di un nuovo repository, la funzione di pulizia revisioni online non recupererà alcuno spazio se eseguita per la prima volta dopo la pulizia revisioni offline, perché non esiste una generazione abbastanza grande per essere rigenerata.
Inoltre, leggere la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo .
In genere, Author e Publish dispongono di diverse finestre di pulizia revisioni online? Questo dipende dalle ore di ufficio e dai percorsi di traffico della presenza online del cliente. Le finestre di manutenzione devono essere configurate al di fuori dei principali tempi di produzione per garantire la migliore efficacia di pulizia. Per più istanze di AEM Publish (farm TarMK), le finestre di manutenzione per la pulizia delle revisioni online devono essere barrate.
Esistono prerequisiti prima di eseguire la pulizia revisioni online?
La pulizia delle revisioni online è disponibile solo con AEM 6.3 e versioni successive. Inoltre, se utilizzi una versione precedente di AEM, devi effettuare la migrazione alla nuova ar segmento Oak.
Quali sono i fattori che determinano la durata della pulizia della revisione online? I fattori sono:
  • Dimensione archivio
  • Carica sul sistema (richieste al minuto, in particolare operazioni di scrittura)
  • Pattern di attività (letture e scrittura)
  • Specifiche hardware (prestazioni CPU, memoria, IOPS)
Gli autori possono continuare a funzionare mentre è in esecuzione la pulizia delle revisioni online? Sì, Online Revision Cleanup può gestire le scritture simultanee. Tuttavia, la funzione di pulizia revisioni online funziona in modo più rapido ed efficiente senza transazioni di scrittura simultanee. Si consiglia di pianificare l'attività di manutenzione Pulizia revisioni online per un tempo relativamente tranquillo senza traffico eccessivo.
Quali sono i requisiti minimi per lo spazio su disco e la memoria heap durante l'esecuzione della pulizia delle revisioni online?
Lo spazio su disco viene monitorato continuamente durante la pulizia delle revisioni online. Se lo spazio disponibile su disco scende al di sotto di un valore critico, il processo verrà annullato. Il valore critico è il 25% dell'attuale spazio su disco del repository e non è configurabile.
Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione del repository inizialmente stimata.
Durante il processo di pulizia, lo spazio libero dell'heap viene monitorato in modo continuo. Se lo spazio di heap gratuito si riduce al di sotto di un valore critico, il processo viene annullato. Il valore critico è configurato tramite org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. Il valore predefinito è 15%.
Le raccomandazioni per il ridimensionamento dell'heap di compattazione minimo non sono separate dalle raccomandazioni di ridimensionamento della memoria di AEM. Come regola generale: Se un’istanza di AEM ha dimensioni sufficienti per far fronte ai casi di utilizzo e al relativo payload previsto, il processo di pulizia otterrà memoria sufficiente.
Qual è l'impatto previsto sulle prestazioni durante l'esecuzione della pulizia delle revisioni online? Pulizia revisioni online è un processo in background che legge e scrive nel repository contemporaneamente alle normali operazioni di sistema. In particolare, potrebbe essere necessario acquisire l'accesso esclusivo al repository per un breve periodo di tempo, impedendo ad altri thread di scrivere nel repository.
Per quanto tempo è prevista l'esecuzione di Online Revision Cleanup? L'esecuzione non dovrebbe richiedere più di 2 ore in base agli ultimi test di prestazioni eseguiti internamente.
Cosa fare se la pulizia della revisione online richiede più tempo?
  • Assicurarsi che venga eseguito ogni giorno.
  • Assicurarsi che venga eseguito durante le attività minime del repository configurando di conseguenza le finestre di manutenzione in Operations Dashboard.
  • Scalabilità delle risorse di sistema (CPU, memoria, I/O).
Cosa succede se la funzione di pulizia revisioni online supera le finestre di manutenzione configurate? Assicuratevi che le altre attività di manutenzione non rallentino l’esecuzione. Ciò potrebbe verificarsi se all'interno della stessa finestra di manutenzione vengono eseguite più attività di manutenzione rispetto a Pulizia revisioni online. Le attività di manutenzione vengono eseguite in sequenza senza un ordine configurabile.
Perché il processo di garbage collection delle revisioni viene ignorato?
Revision Cleanup si basa su una fase di stima per decidere se ci sono abbastanza rifiuti da pulire. Lo stimatore confronta la dimensione corrente con quella dell'archivio dopo l'ultima compattazione. Se la dimensione supera il delta configurato, la pulizia viene eseguita. La dimensione delta è impostata su 1 GB. Questo significa che se la dimensione del repository non è cresciuta di 1 GB dall'ultima esecuzione della pulizia, la nuova iterazione di pulizia della revisione verrà ignorata.
Di seguito sono riportate le voci di registro rilevanti per la fase di stima:
  • Verrà eseguito il GC di revisione: Il delta delle dimensioni è N% o N/N (N/N byte), quindi la compattazione in esecuzione
  • La revisione GC non verrà eseguita: Il delta delle dimensioni è N% o N/N (N/N byte), pertanto la compattazione per il momento viene ignorata
È possibile interrompere in modo sicuro la compattazione automatica se l'impatto delle prestazioni è troppo alto? Sì. A partire da AEM 6.3, può essere arrestato in modo sicuro tramite la finestra Attività di manutenzione all’interno del Pannello operazioni o tramite JMX.
Se l’istanza di AEM viene chiusa durante un’attività di pulizia pianificata, il processo si interrompe in modo sicuro oppure l’arresto viene bloccato fino al termine della compattazione? La pulizia delle revisioni verrà interrotta e la directory archivio verrà chiusa in modo sicuro.
Cosa succede quando il sistema si arresta in modo anomalo durante la pulizia delle revisioni online? In tali casi non vi è alcun rischio di corruzione dei dati. Gli avanzi della spazzatura verranno ripuliti da un'esecuzione successiva.
Qual è l'impatto dell'assenza di pulizia revisioni online? Diminuzione delle prestazioni nel tempo.
Quali revisioni vengono raccolte? Per impostazione predefinita, la funzione Pulizia revisioni online raccoglie solo le revisioni risalenti almeno a 24 ore prima.
Cosa succede in caso di troppa interferenza da scritture simultanee al repository?
In presenza di concorrenza di scrittura nel sistema, la pulizia della revisione online potrebbe richiedere l'accesso in scrittura esclusivo per poter eseguire il commit delle modifiche alla fine di un ciclo di compattazione. Il sistema entrerà in modalità ForceCompact , come spiegato più dettagliatamente nella documentazione di rovere. Durante la forza compatta, viene acquisito un blocco di scrittura esclusivo per eseguire finalmente le modifiche senza interferenze di scrittura simultanea. Per limitare l'impatto sui tempi di risposta è possibile definire un valore di timeout. Questo valore è impostato su 1 minuto per impostazione predefinita, il che significa che se la forza compatta non viene completata entro 1 minuto, il processo di compattazione verrà interrotto in favore di commit simultanei.
La durata della forza compatta dipende dai seguenti fattori:
  • hardware: IOPS. La durata diminuisce con più IOPS.
  • dimensione dell'archivio segmenti: la durata aumenta con la dimensione dell'archivio segmenti.
In che modo viene eseguita la pulizia delle revisioni online in un'istanza in standby?
In una configurazione in standby freddo, solo l'istanza principale deve essere configurata per eseguire la pulizia revisioni online. Nell’istanza standby, la funzione Pulizia revisioni online non deve essere pianificata in modo specifico.
L'operazione corrispondente in un'istanza in standby è la Pulizia automatica, corrispondente alla fase di pulizia della Pulizia revisioni online. La pulizia automatica viene eseguita nell'istanza standby dopo l'esecuzione della pulizia della revisione online sull'istanza principale.
Le fasi di stima e compattazione non verranno eseguite in un'istanza in standby.
La funzione di pulizia revisioni offline è in grado di liberare più spazio su disco rispetto alla funzione di pulizia revisioni online?
Pulizia revisioni offline può rimuovere immediatamente le vecchie revisioni mentre Pulizia revisioni online deve tenere conto delle precedenti revisioni a cui lo stack dell'applicazione fa ancora riferimento. Il primo può quindi rimuovere i rifiuti in modo più aggressivo rispetto al secondo in cui l'effetto viene ammortizzato nel corso di alcuni cicli di raccolta dei rifiuti.
Inoltre, leggere la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo .
Considerazioni sulle operazioni dei file mappati sulla memoria?
  • Negli ambienti Windows, l'accesso regolare ai file viene sempre imposto, pertanto l'accesso mappato alla memoria non viene utilizzato. Come consiglio generale, tutta la RAM disponibile deve essere assegnata all'heap e la dimensione segmentCache deve essere aumentata. Puoi aumentare la cache segmento aggiungendo l'opzione segmentCache.size all'org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (ad esempio, segmentCache.size=20480). Ricordate di lasciare una parte di RAM per il sistema operativo e altri processi.
  • Negli ambienti non Windows, aumentare la dimensione della memoria fisica per migliorare la mappatura della memoria del repository.

Monitoraggio della pulizia delle revisioni online

Cosa è necessario monitorare durante la pulizia delle revisioni online?
  • Lo spazio su disco deve essere monitorato quando è abilitata la funzione di pulizia revisioni online. La pulizia non verrà eseguita o verrà terminata in modo preventivo quando lo spazio su disco è insufficiente.
  • Controllate i registri per verificare l’ora di completamento della pulizia revisioni online. Non dovrebbe richiedere più di due ore.
  • Numero di checkpoint. Se durante l'esecuzione della compattazione sono presenti più di 3 checkpoint, si consiglia di pulire i checkpoint.
Come verificare se la pulizia delle revisioni online è stata completata correttamente?
È possibile verificare se la pulizia della revisione online è stata completata correttamente controllando i registri.
Ad esempio, " TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles " indica il passaggio di compattazione completato correttamente, a meno che non sia preceduto dal messaggio " TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles ", il che significa che il carico simultaneo era eccessivo.
Di conseguenza, viene visualizzato un messaggio " TarMK GC #{}: cleanup completed in {} ({} ms " per completare con successo la fase di pulizia.
Dove possiamo trovare le statistiche delle ultime esecuzioni Online Revision Cleanup?
Stato, avanzamento e statistiche sono esposti tramite JMX ( SegmentRevisionGarbageCollection MBean). Per ulteriori dettagli sull' SegmentRevisionGarbageCollection MBean, leggete il seguente paragrafo .
I progressi possono essere tracciati tramite l' EstimatedRevisionGCCompletion attributo SegmentRevisionGarbageCollection MBean.
È possibile ottenere un riferimento dell'MBean utilizzando l' ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection” .
Le statistiche sono disponibili solo dall'ultimo avvio del sistema. È possibile utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività di AEM. Vedi la documentazione di AEM per allegare controlli dello stato a Nagios come esempio per uno strumento di monitoraggio esterno.
Quali sono le voci di registro rilevanti?
  • Pulizia revisioni online avviata/interrotta
    • La pulizia della revisione online è composta da tre fasi: stima, compattazione e pulizia. La stima può forzare la compattazione e la pulizia a saltare se il repository non contiene abbastanza rifiuti. Nell’ultima versione di AEM, il messaggio " TarMK GC #{}: estimation started " indica l’inizio della stima, " TarMK GC #{}: compaction started, strategy={} " indica l’inizio della compattazione e "T arMK GC #{}: cleanup started. Current repository size is {} ({} bytes " indica l’inizio della pulizia.
  • Spazio su disco ottenuto dalla pulizia della revisione
    • Lo spazio viene recuperato solo al termine della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di registro "T arMK GC #{}: cleanup completed in {} ({} ms ". La dimensione della pulizia del post è {} ({} byte) e lo spazio è stato recuperato {} ({} byte). Peso/profondità della mappa di compattazione: {}/{} ({} byte/{})."
  • Si è verificato un problema durante la pulizia della revisione
    • Ci sono molte condizioni di errore, tutte sono contrassegnate da messaggi di log WARN o ERROR con "TarMK GC".
Consultare anche la sezione Risoluzione dei problemi in base ai messaggi di errore di seguito.
Come controllare quanto spazio è stato recuperato dopo il completamento della pulizia delle revisioni online? Nel registro è presente un messaggio alla fine del ciclo di pulizia: " TarMK GC #3: cleanup completed " che include la dimensione del repository e la quantità di rifiuti recuperati.
Come verificare l'integrità del repository dopo il completamento della pulizia delle revisioni online?
Una verifica dell'integrità dell'archivio non è necessaria dopo la pulizia delle revisioni online.
Tuttavia, potete eseguire le azioni seguenti per verificare lo stato dell’archivio dopo la pulizia:
  • Controllo incrociato repository
  • Dopo il completamento del processo di pulizia, usate lo strumento di esecuzione della quercia per verificare la presenza di incoerenze. Per ulteriori informazioni su come eseguire questa operazione, consulta la Documentazione Apache. Non è necessario arrestare AEM per eseguire lo strumento.
Come rilevare se la pulizia della revisione online non è riuscita e quali sono i passaggi da ripristinare? Le condizioni di errore sono contrassegnate dai messaggi di registro AVVERTENZA o ERRORE che iniziano con "TarMK GC". Consultare anche la sezione Risoluzione dei problemi in base ai messaggi di errore di seguito.
Quali informazioni sono disponibili nel controllo integrità pulizia revisioni? Come e quando contribuiscono ai livelli di stato dei colori codificati?
Il controllo dello stato di pulizia delle revisioni fa parte del Pannello operazioni.
Lo stato sarà VERDE se l'ultima esecuzione dell'attività di manutenzione Pulizia revisioni online è stata completata correttamente.
Sarà GIALLO se l'attività di manutenzione Pulizia revisioni online è stata annullata una volta.
Sarà rosso se l'attività di manutenzione Pulizia revisioni online è stata annullata tre volte di seguito. In questo caso è necessaria l'interazione manuale oppure è probabile che la pulizia della revisione online restituisca un errore. Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi di seguito.
Inoltre, lo stato del controllo dello stato verrà ripristinato dopo il riavvio del sistema. Di conseguenza, un'istanza appena riavviata mostrerà uno stato verde nel controllo dello stato di pulizia revisioni. È possibile utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività di AEM. Vedi la documentazione di AEM per allegare controlli dello stato a Nagios come esempio per uno strumento di monitoraggio esterno.
Come monitorare la pulizia automatica in un'istanza in standby?
Lo stato, l'avanzamento e le statistiche sono esposti tramite JMX utilizzando l' SegmentRevisionGarbageCollection MBean. Vedi anche la seguente documentazione overview.html#monitoring-via-jmx Oak.
È possibile ottenere un riferimento dell'MBean utilizzando l' ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection” .
Le statistiche sono disponibili solo dall'ultimo avvio del sistema. È possibile utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività di AEM. Consulta anche la documentazione di AEM per l’associazione di controlli dello stato a Nagios come esempio per uno strumento di monitoraggio esterno.
I file di registro possono essere utilizzati anche per verificare lo stato, l’avanzamento e le statistiche della pulizia automatica.
Cosa è necessario monitorare durante la pulizia automatica in un'istanza in standby?
  • Durante l'esecuzione della pulizia automatica è necessario controllare lo spazio su disco.
  • Tempo di completamento (tramite i registri) per garantire che non vengano superate 2 ore.
  • Dimensione dell’archivio segmenti dopo l’esecuzione della pulizia automatica. La dimensione dell'archivio segmenti nell'istanza standby deve essere circa la stessa dell'istanza principale.

Risoluzione dei problemi di pulizia revisioni online

Qual è il peggio che può accadere se non si esegue la pulizia delle revisioni online? L'istanza di AEM non dispone di spazio su disco sufficiente a causare interruzioni nella produzione.
Il traffico degli utenti è problematico per l’esecuzione della pulizia delle revisioni online in un’istanza di pubblicazione? L'elevato traffico degli utenti influisce sulla capacità o meno della fase di compattazione di terminare con successo.
In base al controllo dello stato e alle voci di registro, la pulizia della revisione online non è stata completata con successo tre volte di seguito. Cosa è necessario per completare la pulizia della revisione online? Per trovare e risolvere il problema, potete effettuare diverse operazioni:
  • Innanzitutto, controllare le voci di registro
  • A seconda delle informazioni contenute nei registri, intraprendere le azioni appropriate:
    • Se i registri mostrano cinque cicli compatti persi e un timeout nel forceCompact ciclo, pianificare la finestra di manutenzione in un momento tranquillo in cui la quantità di scritture repository è bassa. È possibile controllare le scritture del repository nello strumento di monitoraggio delle metriche di repository disponibile all'indirizzo https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
    • Se la pulizia viene interrotta alla fine della finestra di manutenzione, accertatevi che la configurazione della finestra di manutenzione nell’interfaccia utente Attività di manutenzione sia sufficientemente grande
    • Se la memoria heap disponibile non è sufficiente, assicurarsi che l'istanza disponga di memoria sufficiente.
    • In caso di reazione tardiva, l'archivio segmenti potrebbe crescere troppo per il completamento della pulizia delle revisioni online anche entro una finestra di manutenzione più lunga. Ad esempio, se non è stata completata la pulizia delle revisioni online con esito positivo nell'ultima settimana, si consiglia di pianificare una manutenzione offline ed eseguire la pulizia delle revisioni offline per riportare il segmentstore a una dimensione gestibile.
Cosa fare una volta attivato l'allarme Healthcheck? Vedere il punto precedente.
Cosa succede se la funzione di pulizia revisioni online non ha più tempo a disposizione durante la finestra di manutenzione programmata? La pulizia delle revisioni online verrà annullata e gli avanzi verranno rimossi. Verrà riavviata la prossima volta che la finestra di manutenzione sarà pianificata.
Cosa causa l' SegmentNotFoundException accesso alle istanze error.log e come posso recuperare?
Un SegmentNotFoundException file viene registrato da TarMK quando tenta di accedere a un'unità di archiviazione (un segmento) che non riesce a trovare. Esistono tre scenari che potrebbero causare il problema:
  1. Un'applicazione che aggira i meccanismi di accesso consigliati (come Sling e l'API JCR) e utilizza un API/SPI di livello inferiore per accedere al repository e quindi supera il tempo di conservazione di un segmento. In altre parole, mantiene un riferimento a un'entità più lungo del tempo di conservazione consentito dalla pulizia della revisione online (per impostazione predefinita, 24 ore). Questo caso è transitorio e non porta alla corruzione dei dati. Per recuperare, l'utensile di rovere deve essere utilizzato per confermare la natura transitoria dell'eccezione (il controllo di esecuzione della quercia non deve segnalare errori). A tal fine, l'istanza deve essere portata offline e riavviata successivamente.
  2. Un evento esterno ha causato il danneggiamento dei dati presenti sul disco. Può trattarsi di un errore del disco, di una mancanza di spazio su disco o di una modifica accidentale dei file di dati richiesti. In questo caso, l'istanza deve essere portata offline e riparata utilizzando il controllo di esecuzione della quercia. Per ulteriori dettagli su come eseguire il controllo di esecuzione della quercia, consultare la seguente documentazione overview.md#check Apache.
  3. Tutte le altre occorrenze devono essere risolte tramite l'Assistenza clienti Adobe.

Risoluzione Dei Problemi In Base Ai Messaggi Di Errore

Il file error.log sarà dettagliato se si verificano degli incidenti durante il processo di pulizia della revisione online. La seguente matrice ha lo scopo di spiegare i messaggi più comuni e fornire possibili soluzioni:
Fase
Messaggi del registro
Spiegazione
Passaggi successivi
Stima
TarMK GC #2: stima ignorata perché la compattazione è in pausa
La fase di stima viene saltata quando la compattazione viene disabilitata nel sistema dalla configurazione.
Abilita pulizia revisioni online.
TarMK GC #2: stima interrotta: $. Salta la compattazione.
La fase di stima è terminata prematuramente. Alcuni esempi di eventi che potrebbero interrompere la fase di stima: memoria o spazio su disco insufficiente nel sistema host.
Dipende dal motivo dato.
Compaction
TarMK GC #2: compattazione in pausa
Finché la fase di compattazione viene messa in pausa dalla configurazione, non verrà eseguita né la fase di stima né la fase di compattazione.
Abilita pulizia revisioni online.
TarMK GC #2: compaction annullata: $.
La fase di compattazione è terminata prematuramente. Alcuni esempi di eventi che potrebbero interrompere la fase di compattazione: memoria o spazio su disco insufficiente nel sistema host. Inoltre, la compattazione può essere annullata anche chiudendo il sistema o annullandolo esplicitamente tramite interfacce amministrative come la finestra di manutenzione all'interno del dashboard delle operazioni.
Dipende dal motivo dato.
TarMK GC #2: compattazione non riuscita in 32.902 min (1974140 ms), dopo 5 cicli
Questo messaggio non indica un errore irreversibile, ma solo che la compattazione è stata terminata dopo un certo numero di tentativi. Inoltre, leggete il seguente paragrafo .
Leggete la seguente documentazione overview.html#how-does-compaction-works-with-concurrent-writes Oak e l’ultima domanda della sezione Esecuzione della pulizia delle revisioni online.
Pulizia
TarMK GC #2: pulizia interrotta
La pulizia è stata annullata chiudendo la directory archivio. Non è previsto alcun impatto sulla coerenza. Inoltre, è probabile che lo spazio su disco non venga recuperato completamente. Verrà recuperato durante il prossimo ciclo di pulizia revisioni.
Verificare il motivo per cui il repository è stato chiuso e continuare a cercare di evitare la chiusura del repository durante le finestre di manutenzione.

Come eseguire la pulizia revisioni offline

È necessario utilizzare diverse versioni dello strumento Oak-run a seconda della versione Oak utilizzata con l’installazione di AEM. Prima di utilizzare lo strumento, controllare l'elenco dei requisiti di versione riportato di seguito:
  • Per le versioni Oak da 1.0.0 a 1.0.11 o da 1.1.0 a 1.1.6 , utilizzate la versione di esecuzione Oak​*** 1.0.11**
  • Per le versioni Oak più recenti rispetto a quelle precedenti , utilizzate la versione di Oak-run che corrisponda al core Oak dell’installazione AEM.
Adobe fornisce uno strumento denominato Oak-run per eseguire la pulizia revisioni. Può essere scaricato nel seguente percorso:
Lo strumento è un barattolo eseguibile che può essere eseguito manualmente per comprimere il repository. Il processo è denominato pulizia revisioni offline perché l'archivio deve essere chiuso per poter eseguire correttamente lo strumento. Pianificare la pulizia in base alla finestra di manutenzione.
Per suggerimenti su come migliorare le prestazioni del processo di pulizia, consultate Incremento delle prestazioni della pulizia delle revisioni offline.
È inoltre possibile cancellare i vecchi checkpoint prima che venga effettuata la manutenzione (passaggi 2 e 3 nella procedura seguente). Questa opzione è consigliata solo per le istanze con più di 100 punti di controllo.
  1. Accertatevi sempre di disporre di un backup recente dell’istanza AEM.
    Arrestate AEM.
  2. (Facoltativo) Utilizzate lo strumento per individuare i vecchi checkpoint:
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
    
  3. (Facoltativo) Quindi, eliminate i punti di controllo senza riferimento:
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
    
  4. Eseguire la compattazione e attendere il completamento:
    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    
    

Aumento delle prestazioni della pulizia delle revisioni offline

Lo strumento di esecuzione della quercia introduce diverse funzioni che mirano ad aumentare le prestazioni del processo di pulizia della revisione e ridurre il più possibile la finestra di manutenzione.
L'elenco include diversi parametri della riga di comando, come descritto di seguito:
  • -mmap. È possibile impostare questo valore su true o false. Se impostato su true, viene utilizzato l'accesso mappato alla memoria. Se è impostato su false, viene utilizzato l'accesso ai file. Se non viene specificato, l'accesso mappato alla memoria viene utilizzato sui sistemi a 64 bit e l'accesso ai file viene utilizzato sui sistemi a 32 bit. In Windows, l'accesso regolare ai file viene sempre applicato e questa opzione viene ignorata. Questo parametro ha sostituito il parametro -Dtar.memoryMapped.
  • -Dupdate.limit . Definisce la soglia per lo scaricamento su disco di una transazione temporanea. Il valore predefinito è 10000.
  • -Dcompress-interval . Numero di voci della mappa di compattazione da mantenere fino alla compressione della mappa corrente. Il valore predefinito è 1000000. Se è disponibile una quantità sufficiente di memoria heap, è consigliabile aumentare questo valore fino a un numero ancora più elevato. Questo parametro è stato rimosso nella versione 1.6 di Oak e non ha alcun effetto.
  • -Dcompaction-progress-log . Numero di nodi compatti che verranno registrati. Il valore predefinito è 150000, il che significa che i primi 150000 nodi compatti verranno registrati durante l'operazione. Utilizzate questo insieme al parametro successivo descritto di seguito.
  • -Dtar.PersistCompactionMap. Impostate questo parametro su true per utilizzare lo spazio su disco invece della memoria heap per la persistenza della mappa di compattazione. Richiede le versioni 1.4 e successive dello strumento di esecuzione della quercia. Per ulteriori dettagli, consultate la domanda 3 nella sezione Offline Revision Cleanup Frequently Asked Questions (Pulizia della revisione offline) . Questo parametro è stato rimosso nella versione 1.6 di Oak e non ha alcun effetto.
  • —force. Forza la compattazione e ignora una versione dell’archivio segmenti non corrispondente.
L'utilizzo del --force parametro consente di aggiornare lo store del segmento alla versione più recente, che è incompatibile con le versioni precedenti di Oak. Inoltre, tenete in considerazione che non è possibile eseguire il downgrade. Come regola generale, è necessario utilizzare questi parametri con cautela e solo se si è esperti su come utilizzarli.
Esempio dei parametri in uso:
java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Metodi aggiuntivi per attivare la pulizia delle revisioni

Oltre ai metodi descritti qui sopra, potete attivare il meccanismo di pulizia revisioni utilizzando la console JMX come segue:
  1. Aprite la console JMX accedendo a http://localhost:4502/system/console/jmx
  2. Fare clic su RevisionGarbageCollection MBean.
  3. Nella finestra successiva, fare clic su startRevisionGC() , quindi su Invoke per avviare il processo di raccolta dei rifiuti di revisione.

Pulizia revisioni offline - Domande frequenti

Quali sono i fattori che determinano la durata della pulizia delle revisioni offline?
La dimensione del repository e la quantità di revisioni da pulire determinano la durata della pulizia.
Qual è la differenza tra una revisione e una versione di pagina?
  • Revisione Oak: Oak organizza tutto il contenuto in una grande gerarchia ad albero che consiste di nodi e proprietà. Ogni istantanea o revisione di questa struttura del contenuto è immutabile e le modifiche alla struttura sono espresse come una sequenza di nuove revisioni. In genere, ogni modifica di contenuto attiva una nuova revisione. Vedi anche Collegamento Segui.
  • Versione pagina:Quando si crea una versione, viene creata un’istantanea di una pagina in un momento specifico. In genere, quando si attiva una pagina viene creata una nuova versione. Per ulteriori informazioni, vedere Uso delle versioni di pagina.
Come velocizzare l'attività di pulizia revisioni offline se non viene completata entro 8 ore? Se l’attività di revisione non viene completata entro 8 ore e i thread dumps rivelano che il punto di attivazione principale è InMemoryCompactionMap.findEntry , utilizzare il seguente parametro con le versioni 1.4 o superiori dello strumento di esecuzione della quercia: -Dtar.PersistCompactionMap=true . Il -Dtar.PersistCompactionMap parametro è stato rimosso nella versione 1.6 di Oak.