Pulizia revisioni

Introduzione

Ogni aggiornamento del repository crea una nuova revisione del contenuto. Di conseguenza, con ogni aggiornamento, le dimensioni dell'archivio crescono. Le vecchie revisioni devono essere ripulite per liberare risorse su disco - questo è importante per evitare una crescita incontrollata del repository. Questa funzionalità di manutenzione è denominata Revision Cleanup (Pulizia delle revisioni). È disponibile come routine offline dal AEM 6.0.

Con AEM 6.3 e versioni successive, è stata introdotta una versione online di questa funzionalità chiamata Pulizia revisioni online. Rispetto al cleanup delle revisioni offline in cui l'istanza AEM deve essere chiusa, il cleanup delle revisioni online può essere eseguito mentre l'istanza AEM è online. Il cleanup delle revisioni online è attivato per impostazione predefinita ed è il modo consigliato per eseguire una pulizia delle revisioni.

Nota: Guarda il video per un'introduzione e come utilizzare il cleanup delle revisioni online.

Il processo di pulizia della revisione si articola in tre fasi: stima, compattazione e pulire. La stima determina se eseguire la fase successiva (compattazione) o meno in base alla quantità di rifiuti che potrebbero essere raccolti. Durante la fase di compattazione i segmenti e i file tar vengono riscritti lasciando fuori qualsiasi contenuto non utilizzato. La fase di pulizia rimuove successivamente i vecchi segmenti, compresi eventuali rifiuti che potrebbero contenere. In genere, la modalità offline può recuperare più spazio perché la modalità online deve tenere conto AEM set di lavoro che mantiene i segmenti aggiuntivi da raccogliere.

Per ulteriori dettagli sul cleanup delle revisioni, vedere i seguenti collegamenti:

Inoltre, puoi anche leggere il documentazione ufficiale Oak.

Quando utilizzare il cleanup delle revisioni online anziché il cleanup delle revisioni offline?

Pulizia revisioni online è il modo consigliato per eseguire la pulizia revisioni. Il cleanup delle revisioni offline deve essere utilizzato solo su base eccezionale, ad esempio prima di eseguire la migrazione al nuovo formato di archiviazione o se l'Assistenza clienti Adobe ti richiede di farlo.

Come eseguire il cleanup delle revisioni online

Il cleanup delle revisioni online è configurato per impostazione predefinita per essere eseguito automaticamente una volta al giorno sia sulle istanze di AEM Author che Publish. È sufficiente definire la finestra di manutenzione durante un periodo con la minore attività dell’utente. È possibile configurare l'attività Pulizia revisioni online come segue:

  1. Nella finestra AEM principale, vai a Strumenti - Operazioni - Dashboard - Manutenzione o rivolgiti al tuo browser per: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Passa il cursore Finestra Manutenzione giornaliera e fai clic su Impostazioni icona.

    chlimage_1-91

  3. Immetti i valori desiderati (ricorrenza, ora di inizio, ora di fine) e fai clic su Salva.

    chlimage_1-92

In alternativa, se si desidera eseguire manualmente l'attività di pulizia della revisione, è possibile:

  1. Vai a Strumenti - Operazioni - Dashboard - Manutenzione o sfogliare direttamente in https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. Fai clic sul pulsante Finestra Manutenzione giornaliera.

  3. Passa il puntatore del mouse Pulizia revisioni icona.

  4. Fai clic su Esegui.

    chlimage_1-93

Esecuzione del cleanup delle revisioni online dopo il cleanup delle revisioni offline

Il processo di pulizia revisioni recupera vecchie revisioni per generazioni. Ciò significa che ogni volta che si esegue il cleanup delle revisioni viene creata e mantenuta una nuova generazione sul disco. Esiste tuttavia una differenza tra i due tipi di pulizia revisioni: la pulizia revisioni offline mantiene una generazione mentre la pulizia revisioni online mantiene due generazioni. Quindi, quando esegui la pulizia revisioni online dopo la pulizia della revisione offline avviene come segue:

  1. Dopo la prima esecuzione di pulizia della revisione online, la dimensione dell'archivio raddoppierà. Questo accade perché ci sono due generazioni che vengono conservate sul disco.
  2. Durante le esecuzioni successive, l'archivio cresce temporaneamente durante la creazione della nuova generazione e quindi si stabilizza di nuovo alle dimensioni che aveva dopo la prima esecuzione, in quanto il processo di pulizia della revisione online rireclama la generazione precedente.

Inoltre, ricorda 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.

A causa di questo fatto, si raccomanda di dimensionare il disco almeno due o tre volte più grande della dimensione dell'archivio inizialmente stimata.

Modalità Di Compattazione Completa E Dettagliata

AEM 6.5 Introduce due nuove modalità per compattazione fase del processo di pulizia delle revisioni online:

  • La compattazione completa la modalità riscrive tutti i segmenti e i file tar nell'intero archivio. La successiva fase di pulizia può quindi rimuovere la quantità massima di rifiuti nel repository. Dal momento che la compattazione completa interessa l'intero archivio, richiede una notevole quantità di risorse di sistema e tempo per essere completata. La compattazione completa corrisponde alla fase di compattazione del AEM 6.3.
  • La compattazione della coda la modalità riscrive solo i segmenti e i file tar più recenti nell’archivio. I segmenti e i file tar più recenti sono quelli che sono stati aggiunti dopo l’ultima esecuzione della compattazione completa o tail. La successiva fase di pulizia può quindi rimuovere solo i rifiuti contenuti nella parte recente dell'archivio. Poiché la compattazione di coda influisce solo su una parte dell'archivio, richiede notevolmente meno risorse di sistema e tempo per completare la compattazione completa.

Tali modalità di compattazione costituiscono un compromesso tra efficienza e consumo di 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 anche un meccanismo di deduplicazione dei contenuti più efficiente durante la compattazione, che riduce ulteriormente l’impronta su disco dell’archivio.

I due grafici qui di seguito, presentano i risultati di prove interne di laboratorio che illustrano la riduzione dei tempi medi di esecuzione e l'impronta media su disco nella AEM 6.5 rispetto alla AEM 6.3:

onrc-duration-6_4vs63 segmentstore-6_4vs63

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 di configurazione full.gc.days del RevisionCleanupTask operazione di manutenzione.

Quando configuri le full.gc.days Il valore indica che la compattazione completa verrà eseguita durante i giorni definiti nel valore e la compattazione tail verrà eseguita nei giorni non definiti nel valore. Ad esempio, se configuri la compattazione completa da eseguire domenica, la compattazione della coda viene eseguita dal lunedì al sabato. Se, ad esempio, si configura la compattazione completa per l'esecuzione ogni giorno della settimana, la compattazione della coda non verrà eseguita affatto.

Inoltre, prendere in considerazione che:

  • Compattazione della coda è meno efficace e ha un minore impatto sulle normali operazioni del sistema. Esso è pertanto destinato ad essere eseguito nei giorni lavorativi.
  • Compattazione completa è più efficace, ma ha anche un impatto maggiore sulle normali operazioni del sistema. È pertanto destinato ad essere utilizzato fuori dei giorni lavorativi.
  • La compattazione della coda e 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:

  • Puoi monitorare l’attività di input/output (I/O), ad esempio: Operazioni I/O, CPU in attesa di IO, dimensione della coda di commit. Questo aiuta a determinare se il sistema sta diventando legato a I/O e richiede l'upsize.
  • La RevisionCleanupTaskHealthCheck indica lo stato di integrità generale del cleanup delle revisioni online. Funziona come nel AEM 6.3 e non distingue tra compattazione completa e compattazione della coda.
  • I messaggi di log contengono informazioni pertinenti sulle modalità di compattazione. Ad esempio, all'avvio del cleanup delle revisioni online, i messaggi di log corrispondenti indicheranno la modalità di compattazione. Inoltre, in alcuni casi d’angolo, il sistema ripristina la compattazione completa quando è stato pianificato l’esecuzione di una compattazione di coda e i messaggi di log indicheranno questa modifica. I campioni di log qui sotto indicano la modalità di compattazione e il passaggio dalla coda alla completa compattazione:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Limitazioni note

In alcuni casi, alternando tra la coda e le modalità di compattazione completa ritarda il processo di pulizia. Più precisamente, l’archivio crescerà dopo una compattazione completa (raddoppierà le dimensioni). Lo spazio aggiuntivo verrà recuperato nella successiva compattazione tail, quando l’archivio scende al di sotto della dimensione di compattazione precompleta. È inoltre necessario evitare l’esecuzione di operazioni di manutenzione parallele.

Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione dell'archivio inizialmente stimata.

Domande frequenti sul cleanup delle revisioni online

Considerazioni sull'aggiornamento a AEM 6.5

Domande Risposte
Cosa devo sapere quando eseguo l’aggiornamento a AEM 6.5?

Il formato di persistenza di TarMK cambierà con AEM 6.5. Queste modifiche non richiedono un passaggio di migrazione proattivo. Gli archivi esistenti passeranno attraverso una migrazione continua, trasparente per l’utente. Il processo di migrazione viene avviato la prima volta AEM 6.5 (o strumenti correlati) accedono all’archivio.

Una volta avviata la migrazione al formato di persistenza AEM 6.5, l’archivio non può essere ripristinato al precedente formato di persistenza AEM 6.3.

Migrazione a Oak Segment Tar

Domande Risposte
Perché devo migrare l’archivio?

In AEM 6.3 erano necessarie modifiche al formato di storage, soprattutto per migliorare le prestazioni e l'efficacia del cleanup delle revisioni online. Queste modifiche non sono compatibili con le versioni precedenti e gli archivi creati con il vecchio segmento Oak (AEM 6.2 e precedenti) devono essere migrati.

Ulteriori vantaggi della modifica del formato di storage:
Il formato Tar precedente è ancora supportato? È supportato solo il nuovo Segment Tar di Oak con AEM 6.3 o versione successiva.
La migrazione dei contenuti è sempre obbligatoria? Sì. A meno che non inizi con una nuova istanza, dovrai sempre eseguire la migrazione del contenuto.
Posso effettuare l’aggiornamento alla versione 6.3 o successiva e 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. Questo è uno sforzo una tantum che non può essere fatto su un'istanza in esecuzione.
Cosa succede se accidentalmente eseguo con un formato di archivio errato? Se tenti di eseguire il modulo oak-segment su un archivio oak-segment-tar (o viceversa), l'avvio avrà esito negativo con un EccezioneStatoIllegale con il messaggio "Formato del segmento non valido". Non si verificherà alcun danneggiamento dei dati.
Sarà necessaria una reindicizzazione degli indici di ricerca? No. La migrazione da oak-segment a oak-segment-tar introduce modifiche nel formato del contenitore. I dati contenuti non sono interessati e non verranno modificati.
Come calcolare al meglio lo spazio su disco previsto 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 archivio segmenti può essere eliminato per recuperare spazio.
Come stimare al meglio la durata della migrazione? Le prestazioni di migrazione possono essere notevolmente migliorate se pulizia revisioni offline viene eseguito prima della migrazione. Tutti i clienti sono invitati a eseguirlo come prerequisito del processo di aggiornamento. In generale, la durata della migrazione dovrebbe 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 del cleanup delle revisioni online

Domande Risposte
Con quale frequenza deve essere eseguito il cleanup delle revisioni online? Una volta al giorno. Questa è la configurazione predefinita nel dashboard delle operazioni.
Come posso configurare l'ora di inizio dell'attività di manutenzione Pulizia revisioni online? Consulta la sezione Come eseguire il cleanup delle revisioni online sezione .
Esiste una frequenza massima che non deve essere superata per il cleanup delle revisioni online? Si consiglia di eseguire il cleanup 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 eseguito il cleanup delle revisioni online? Non è necessario determinare la frequenza in quanto il cleanup delle revisioni online è configurato come attività di manutenzione e viene eseguito automaticamente ogni giorno.
Perché il cleanup delle revisioni online non recupera spazio quando viene eseguito per la prima volta? Pulizia revisioni online recupera 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 sarà recuperato, il che significa che in una prima fase non c'è nulla da recuperare.
Perché il primo cleanup delle revisioni online non recupera spazio quando viene eseguito dopo il cleanup delle revisioni offline?

Il cleanup delle revisioni offline sta reclamando tutto tranne l'ultima generazione rispetto alle ultime due generazioni per il cleanup delle revisioni online. Nel caso di un nuovo archivio, il cleanup delle revisioni online non recupererà spazio quando viene eseguito per la prima volta dopo il cleanup delle revisioni offline perché non c'è generazione abbastanza vecchia da essere recuperata.

Inoltre, leggere la sezione "Esecuzione del cleanup delle revisioni online dopo il cleanup delle revisioni offline" in presente capitolo.
In genere le finestre di Pulizia revisioni in linea sono diverse per Author e Publish? Questo dipende dagli orari dell'ufficio e dai modelli di traffico della presenza online del cliente. Le finestre di manutenzione devono essere configurate al di fuori dei principali tempi di produzione per consentire la migliore efficacia di pulizia. Per più istanze di pubblicazione AEM (TarMK Farm), le finestre di manutenzione per il cleanup delle revisioni online devono essere scaglionate.
Ci sono dei prerequisiti prima di eseguire il cleanup delle revisioni online?

Il cleanup delle revisioni online è disponibile solo con le versioni AEM 6.3 e successive. Inoltre, se utilizzi una versione precedente di AEM, devi effettuare la migrazione al nuovo Oak Segment Tar.
Quali sono i fattori che determinano la durata del cleanup delle revisioni online? I fattori sono:
  • Dimensione archivio
  • Carica sul sistema (richieste al minuto, in particolare operazioni di scrittura)
  • Pattern di attività (letture e scritture)
  • Specifiche hardware (prestazioni CPU, memoria, IOPS)
Gli autori possono continuare a lavorare mentre è in esecuzione il cleanup delle revisioni online? Sì, il cleanup delle revisioni online può far fronte alle scritture simultanee. Tuttavia, il cleanup delle 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 in un tempo relativamente tranquillo senza traffico molto intenso.
Quali sono i requisiti minimi per lo spazio su disco e la memoria heap quando si esegue il cleanup delle revisioni online?

Lo spazio su disco viene costantemente monitorato durante il cleanup delle revisioni online. Se lo spazio su disco disponibile scende al di sotto di un valore critico, il processo verrà annullato. Il valore critico è pari al 25% dell'attuale spazio su disco dell'archivio e non è configurabile.

Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione dell'archivio inizialmente stimata.

Lo spazio libero di heap viene monitorato continuamente durante il processo di pulizia. Se lo spazio heap libero scende 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%.

Recommendations per il dimensionamento minimo dell'heap di compattazione non è separato dai consigli di dimensionamento della memoria AEM. Come regola generale: Se un'istanza AEM ha dimensioni sufficienti per far fronte ai casi d'uso e al relativo payload previsto, il processo di pulizia otterrà memoria sufficiente.
Qual è l'impatto previsto sulle prestazioni durante l'esecuzione del cleanup delle revisioni online? Il cleanup delle revisioni online è un processo in background che legge e scrive nell'archivio contemporaneamente alle normali operazioni di sistema. In particolare, potrebbe essere necessario acquisire l’accesso esclusivo all’archivio per un breve periodo di tempo, impedendo ad altri thread di scrivere nell’archivio.
Quanto tempo è previsto per l'esecuzione del cleanup delle revisioni online? L’esecuzione non dovrebbe richiedere più di 2 ore in base agli ultimi test delle prestazioni eseguiti internamente.
Cosa fare se il cleanup delle revisioni online richiede più tempo?
  • Assicurati che venga eseguito ogni giorno.
  • Assicurati che venga eseguito durante attività di repository minime configurando le finestre di manutenzione in Dashboard operazioni di conseguenza.
  • Scala le risorse di sistema (CPU, memoria, I/O).
Cosa succede se il cleanup delle revisioni online supera le finestre di manutenzione configurate? Assicurati che altre attività di manutenzione non ne ritardino l’esecuzione. Ciò potrebbe accadere se più attività di manutenzione rispetto a Pulizia revisioni online vengono eseguite all'interno della stessa finestra di manutenzione. Le attività di manutenzione vengono eseguite in sequenza senza un ordine configurabile.
Perché la revisione della raccolta degli oggetti inattivi viene ignorata?

Revision Cleanup si basa su una fase di stima per decidere se ci sono abbastanza rifiuti da pulire. Il calcolatore confronta la dimensione corrente rispetto alla dimensione dell’archivio dopo l’ultima compattazione. Se la dimensione supera il delta configurato, verrà eseguita la pulizia. Il delta della dimensione è impostato a 1 GB. Ciò significa che, se la dimensione dell’archivio non è cresciuta di 1 GB dall’ultima esecuzione di pulizia, la nuova iterazione di pulizia della revisione verrà saltata.

Di seguito sono riportate le voci di log pertinenti per la fase di stima:

  • Revision GC verrà eseguita: Il delta delle dimensioni è N% o N/N (N/N byte), quindi la compattazione in esecuzione
  • Revisione GC not esegui: Il delta delle dimensioni è N% o N/N (N/N byte), pertanto per il momento la compattazione viene saltata
È possibile interrompere in modo sicuro la compattazione automatica se l'impatto sulle 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 dashboard delle operazioni o tramite JMX.
Se l'istanza di AEM viene chiusa durante un'attività di pulizia pianificata, il processo si interrompe in modo sicuro o l'arresto viene bloccato fino al termine della compattazione? Il cleanup delle revisioni verrà interrotto e l'archivio verrà chiuso in modo sicuro.
Cosa succede quando il sistema si blocca durante il cleanup delle revisioni online? In tali casi non vi è alcun rischio di corruzione dei dati. Gli avanzi dei rifiuti verranno ripuliti da una successiva esecuzione.
Qual è l'impatto dell'impossibilità di eseguire il cleanup delle revisioni online? Degradazione delle prestazioni nel tempo.
Quali revisioni vengono raccolte? Per impostazione predefinita, il cleanup delle revisioni online raccoglie solo revisioni di almeno 24 ore.
Cosa succede in caso di troppa interferenza da scritture simultanee al repository?

Se nel sistema è presente una concorrenza di scrittura, la pulizia di revisione online potrebbe richiedere l'accesso in scrittura esclusivo per eseguire il commit delle modifiche alla fine di un ciclo di compattazione. Il sistema entrerà in modalità forceCompact, come spiegato più in dettaglio nella sezione documentazione oak. Durante la forza compatta, viene acquisito un blocco di scrittura esclusivo per commettere 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 il compatto della forza non viene completato entro 1 minuto il processo di compattazione verrà interrotto in favore dei commit simultanei.

La durata della forza compatta dipende dai seguenti fattori:

  • hardware: IOPS. La durata diminuisce con più IOPS.
  • dimensioni archivio segmenti: La durata aumenta con le dimensioni dell’archivio segmenti.

Come viene eseguito il cleanup delle revisioni online su un'istanza in standby?

In una configurazione in standby a freddo, solo l'istanza principale deve essere configurata per eseguire il cleanup delle revisioni online. Nell'istanza di standby non è necessario pianificare in modo specifico il cleanup delle revisioni online.

L'operazione corrispondente in un'istanza di standby è il cleanup automatico, corrispondente alla fase di pulizia del cleanup delle revisioni online. Il cleanup automatico viene eseguito sull'istanza di standby dopo l'esecuzione del cleanup delle revisioni online sull'istanza primaria.

Le fasi di stima e compattazione non verranno eseguite in un'istanza di standby.
Il cleanup delle revisioni offline è in grado di liberare più spazio su disco rispetto al cleanup delle revisioni online?

Il cleanup delle revisioni offline può rimuovere immediatamente le vecchie revisioni mentre il cleanup delle revisioni online deve tenere conto delle vecchie revisioni a cui lo stack dell'applicazione fa ancora riferimento. Il primo può così rimuovere i rifiuti in modo più aggressivo rispetto a quest'ultimo dove l'effetto è ammortizzato nel corso di alcuni cicli di raccolta dei rifiuti.

Inoltre, leggere la sezione "Esecuzione del cleanup delle revisioni online dopo il cleanup delle revisioni offline" in presente capitolo.
Considerazioni sulle operazioni dei file mappati in memoria?
  • In ambienti Windows, l’accesso regolare ai file viene sempre applicato, pertanto l’accesso mappato alla memoria non viene utilizzato. Come consiglio generale, tutta la RAM disponibile dovrebbe essere assegnata all'heap e la dimensione segmentCache dovrebbe essere aumentata. Aumenta il segmentCache aggiungendo l'opzione segmentCache.size all'org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (per esempio, segmentCache.size=20480). Ricordarsi di lasciare fuori un po' di RAM per il sistema operativo e altri processi.
  • In ambienti non Windows, aumenta le dimensioni della memoria fisica per migliorare la mappatura della memoria dell'archivio.

Monitoraggio del cleanup delle revisioni online

Cosa è necessario monitorare durante il cleanup delle revisioni online?
  • Lo spazio su disco deve essere monitorato quando il cleanup delle revisioni online è abilitato. La pulizia non verrà eseguita o verrà interrotta in modo preventivo quando lo spazio su disco non è sufficiente.
  • Controllare i registri per l'orario di completamento del cleanup delle revisioni online. Non dovrebbe richiedere più di 2 ore.
  • Numero di punti di controllo. Se durante l’esecuzione della compattazione sono presenti più di 3 punti di controllo, è consigliabile ripulire i punti di controllo.
Come verificare se il cleanup delle revisioni online è stato completato con successo?

È possibile verificare se il cleanup delle revisioni online è stato completato correttamente controllando i registri.

Ad esempio, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" indica la fase di compattazione completata con successo, a meno che non sia preceduta dal messaggio "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", il che significa che c'era troppo carico simultaneo.

Di conseguenza c'è un messaggio "TarMK GC #{}: cleanup completed in {} ({} ms" per il completamento del passaggio di pulizia.

Dove possiamo trovare le statistiche delle ultime esecuzioni di Pulizia revisioni online?

Lo stato, il progresso e le statistiche sono esposti tramite JMX (SegmentRevisionGarbageCollection MBean). Per ulteriori dettagli sulla SegmentRevisionGarbageCollection MBean, leggi il paragrafo seguente.

L’avanzamento può essere tracciato tramite il EstimatedRevisionGCCompletion dell'attributo SegmentRevisionGarbageCollection MBean.

È possibile ottenere un riferimento a MBean utilizzando 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 sfruttare gli strumenti di monitoraggio esterni per mantenere i dati oltre il tempo AEM. Vedi la documentazione AEM relativa all'allegato dei controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.
Quali sono le voci di registro rilevanti?
  • Pulizia revisioni online avviata/interrotta
    • Il cleanup delle revisioni online si articola in tre fasi: stima, compattazione e pulizia. La stima può forzare la compattazione e la pulizia per saltare se l'archivio non contiene abbastanza rifiuti. Nell'ultima versione di AEM, il messaggio "TarMK GC #{}: estimation started" segna l'inizio della stima, "TarMK GC #{}: compaction started, strategy={}" indica l'inizio della compattazione e "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" indica l'inizio della pulizia.
  • Spazio su disco ottenuto dalla pulizia revisioni
    • Lo spazio viene recuperato solo al completamento della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di log "TarMK 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 che fissano con "TarMK GC".

Inoltre, consulta la sezione Risoluzione dei problemi in base ai messaggi di errore di seguito.
Come controllare quanto spazio è stato recuperato dopo il completamento del cleanup delle revisioni online? Nel registro è presente un messaggio alla fine del ciclo di pulizia: "TarMK GC #3: cleanup completed" che include le dimensioni dell'archivio e la quantità di rifiuti recuperati.
Come verificare l'integrità dell'archivio dopo il completamento del cleanup delle revisioni online?

Dopo il cleanup delle revisioni online non è necessario un controllo dell'integrità dell'archivio.

Tuttavia, puoi eseguire le seguenti azioni per controllare lo stato dell’archivio dopo la pulizia:

  • Un archivio controllo traversale
  • Usa lo strumento oak-run dopo che il processo di pulizia è stato completato per verificare la presenza di incongruenze. Per ulteriori informazioni su come eseguire questa operazione, controlla il Documentazione di Apache. Non è necessario arrestare AEM per eseguire lo strumento.
Come rilevare se il cleanup delle revisioni online non è riuscito e quali sono i passaggi da recuperare? Le condizioni di errore sono contrassegnate dai messaggi di log WARN o ERROR che iniziano con "TarMK GC". Inoltre, consulta la sezione Risoluzione dei problemi in base ai messaggi di errore di seguito.
Quali informazioni sono esposte nel controllo dello stato del cleanup delle revisioni? Come e quando contribuiscono ai livelli di stato codificati del colore?

Il controllo dello stato di pulizia delle revisioni fa parte del Dashboard delle operazioni.

Lo stato sarà VERDE se l'ultima esecuzione dell'attività di manutenzione Pulizia revisioni online è stata completata con successo.

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 un'interazione manuale È probabile che il cleanup delle revisioni online non riesca di nuovo. Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi di seguito.

Inoltre, lo stato di Verifica stato verrà ripristinato dopo il riavvio del sistema. Quindi, un'istanza appena riavviata mostrerà uno stato verde sul controllo di integrità del cleanup delle revisioni. È possibile sfruttare gli strumenti di monitoraggio esterni per mantenere i dati oltre il tempo AEM. Vedi la documentazione AEM relativa all'allegato dei controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.

Come monitorare il cleanup automatico in un'istanza di standby?

Lo stato, il progresso e le statistiche sono esposti tramite JMX utilizzando SegmentRevisionGarbageCollection MBean. Vedi anche quanto segue Documentazione Oak.

È possibile ottenere un riferimento a MBean utilizzando il 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 sfruttare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività AEM. Vedi anche la documentazione AEM relativa all'allegato dei controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.

I file di registro possono inoltre essere utilizzati per controllare lo stato, l'avanzamento e le statistiche del cleanup automatico.

Cosa è necessario monitorare durante il cleanup automatico in un'istanza di standby?
  • Lo spazio su disco deve essere monitorato quando si esegue il cleanup automatico.
  • Tempo di completamento (tramite i registri) per garantire che non vengano superate le 2 ore.
  • Dimensione dell'archivio segmenti dopo l'esecuzione del cleanup automatico. La dimensione del segmentstore sull'istanza di standby deve essere approssimativamente la stessa di quella sull'istanza primaria.

Risoluzione dei problemi del cleanup delle revisioni online

Qual è il peggio che può accadere se non si esegue il cleanup delle revisioni online? Lo spazio su disco nell'istanza AEM verrà esaurito, causando interruzioni nella produzione.
L'elevato traffico degli utenti è problematico per l'esecuzione del cleanup delle revisioni online su 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, il cleanup delle revisioni online non è stato completato con successo tre volte di fila. Cosa è necessario per completare il cleanup delle revisioni online con successo? Puoi intraprendere diversi passaggi per trovare e risolvere il problema:
  • Per prima cosa, controlla le voci del registro
  • A seconda delle informazioni contenute nei registri, adotta le azioni appropriate:
    • Se i registri mostrano cinque cicli compatti persi e un timeout sul forceCompact ciclo, pianificare la finestra di manutenzione in un momento tranquillo quando la quantità di scritture del repository è bassa. Puoi controllare le scritture dell'archivio nello strumento di monitoraggio delle metriche dell'archivio che si trova in https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
    • Se la pulizia viene interrotta alla fine della finestra di manutenzione, verificare che la configurazione della finestra di manutenzione nell'interfaccia utente Attività di manutenzione sia sufficientemente grande
    • Se la memoria heap disponibile non è sufficiente, assicurati che l'istanza disponga di memoria sufficiente.
    • In caso di reazione tardiva, il segmentstore potrebbe crescere troppo per il completamento del cleanup delle revisioni online anche all'interno di una finestra di manutenzione più lunga. Ad esempio, se non è stato completato con successo il cleanup delle revisioni online nell'ultima settimana, si consiglia di pianificare una manutenzione offline ed eseguire il cleanup delle revisioni offline per riportare il segmenstore a una dimensione gestibile.
Cosa fare una volta attivato l'avviso di Healthcheck? Vedi il punto precedente.
Cosa succede se il cleanup delle revisioni online esaurisce il tempo durante la finestra di manutenzione programmata? Il cleanup delle revisioni online verrà annullato e gli avanzi saranno rimossi. La finestra di manutenzione verrà riavviata al successivo avvio.
Cosa causa SegmentNotFoundException istanze da registrare nel error.log e come posso recuperare?

A SegmentNotFoundException viene registrato da TarMK quando tenta di accedere a un'unità di archiviazione (un segmento) che non trova. Ci sono tre scenari che potrebbero causare questo 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 all’archivio 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 dal cleanup delle revisioni online (24 ore per impostazione predefinita). Questo caso è transitorio e non causa corruzione dei dati. Per recuperare, lo strumento oak-run deve essere utilizzato per confermare la natura transitoria dell'eccezione (il controllo oak-run non dovrebbe segnalare alcun errore). Per farlo, l’istanza deve essere portata offline e riavviata in seguito.
  2. Un evento esterno ha causato la corruzione dei dati sul disco. Può trattarsi di un errore del disco, di uno spazio su disco insufficiente o di una modifica accidentale dei file di dati richiesti. In questo caso, l'istanza deve essere portata offline e riparata utilizzando il controllo oak-run. Per ulteriori dettagli su come eseguire il controllo oak-run, leggi quanto segue Documentazione di Apache.
  3. Tutte le altre occorrenze devono essere affrontate tramite la Adobe Customer Care.

Risoluzione Dei Problemi In Base Ai Messaggi Di Errore

Il file error.log sarà dettagliato se si verificano incidenti durante il processo di pulizia della revisione online. La seguente matrice ha lo scopo di spiegare i messaggi più comuni e fornire soluzioni possibili:

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 è disabilitata sul sistema dalla configurazione. Abilita Pulizia revisioni online.
N/D TarMK GC #2: stima interrotta: ${REASON}. 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.
Compattazione TarMK GC #2: compattazione sospesa. Se la fase di compattazione viene sospesa dalla configurazione, non verrà eseguita né la fase di stima né la fase di compattazione. Abilita la pulizia revisioni online.
N/D TarMK GC #2: compattazione annullata: ${REASON}. 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 cancellandolo esplicitamente tramite interfacce amministrative come la finestra di manutenzione all'interno del dashboard delle operazioni. Dipende dal motivo dato.
N/D TarMK GC #2: compattazione fallita in 32.902 min (1974140 ms), dopo 5 cicli. Questo messaggio non significa che si sia verificato un errore irreversibile, ma solo che la compattazione è stata terminata dopo un certo numero di tentativi. Inoltre, leggi il paragrafo seguente. Leggi quanto segue Documentazione Oak, e l'ultima domanda della sezione Running Online Revision Cleanup (Pulizia delle revisioni online in esecuzione).
Pulizia TarMK GC #2: pulizia interrotta. Il cleanup è stato annullato chiudendo l'archivio. Non è previsto alcun impatto sulla coerenza. Inoltre, molto probabilmente lo spazio su disco non verrà recuperato completamente. Verrà ririchiesto durante il prossimo ciclo di pulizia della revisione. Scopri perché l’archivio è stato chiuso e in futuro cerca di evitare di chiudere l’archivio durante le finestre di manutenzione.

Come eseguire il cleanup delle revisioni offline

ATTENZIONE

Utilizza una versione dello strumento Oak-run che ha un numero di versione (sia principale che secondario) corrispondente alla versione di base Oak dell'installazione AEM. Ad esempio, se l’istanza di AEM ha Oak core versione 1.2.x, utilizza l’ultima versione di Oak-run tool 1.22.x.

Adobe fornisce uno strumento chiamato corsa Oak per eseguire la pulizia revisioni. Può essere scaricato nel seguente percorso:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

Lo strumento è un jar eseguibile che può essere eseguito manualmente per compattare l'archivio. Il processo viene chiamato pulizia revisioni offline perché l'archivio deve essere chiuso per eseguire correttamente lo strumento. Pianifica la pulizia in base alla finestra di manutenzione.

Per suggerimenti su come aumentare le prestazioni del processo di pulizia, vedi Aumento delle prestazioni del cleanup delle revisioni offline.

NOTA

È inoltre possibile eliminare i vecchi checkpoint prima della manutenzione (passaggi 2 e 3 nella procedura seguente). Questa opzione è consigliata solo per le istanze con più di 100 punti di controllo.

  1. Assicurati sempre di avere un backup recente dell'istanza AEM.

    AEM.

  2. (Facoltativo) Utilizza lo strumento per trovare i vecchi checkpoint:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore

  3. (Facoltativo) Quindi, elimina i punti di controllo senza riferimento:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced

  4. Esegui la compattazione e attendine il completamento:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore

Aumento delle prestazioni del cleanup delle revisioni offline

Lo strumento oak-run introduce diverse funzioni che mirano ad aumentare le prestazioni del processo di pulizia della revisione e ridurre al minimo la finestra di manutenzione.

L’elenco include diversi parametri della riga di comando, come descritto di seguito:

  • Mappa. È possibile impostare questo valore come 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 specificato, l'accesso mappato alla memoria viene utilizzato su sistemi a 64 bit e l'accesso ai file viene utilizzato su 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.

  • -Intervallo depressa. 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, è necessario aumentare questo valore a un numero ancora più alto per il throughput più rapido. Questo parametro è stato rimosso nella versione 1.6 di Oak e non ha alcun effetto.

  • -Dcompaction-progress-log. Il numero di nodi compatti che verranno registrati. Il valore predefinito è 150000, il che significa che i primi 150000 nodi compattati verranno registrati durante l'operazione. Utilizza questo insieme al parametro successivo documentato di seguito.

  • -Dtar.PersistCompactionMap. Imposta questo parametro su true per utilizzare lo spazio su disco invece della memoria heap per la persistenza della mappa di compattazione. Richiede lo strumento oak-run versioni 1.4 e superiore. Per ulteriori dettagli, cfr. la domanda 3 nel Domande frequenti sul cleanup delle revisioni offline sezione . Questo parametro è stato rimosso nella versione 1.6 di Oak e non ha alcun effetto.

  • —forza. Forza la compattazione e ignora una versione non corrispondente dell’archivio segmenti.

ATTENZIONE

Utilizzo della --force Il parametro aggiornerà l’archivio segmenti alla versione più recente, incompatibile con le versioni Oak precedenti. Inoltre, prendere in considerazione che non è possibile alcun 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 il cleanup delle revisioni

Oltre ai metodi descritti in precedenza, puoi anche attivare il meccanismo di pulizia revisioni utilizzando la console JMX come segue:

  1. Apri la console JMX da http://localhost:4502/system/console/jmx
  2. Fai clic sul pulsante RevisionGarbageCollection MBean.
  3. Nella finestra successiva, fai clic su startRevisionGC() e poi Richiama per avviare il processo Revision Garbage Collection.

Domande frequenti sul cleanup delle revisioni offline

Quali sono i fattori che determinano la durata del cleanup 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 costituita da nodi e proprietà. Ogni istantanea o revisione di questa struttura di contenuto è immutabile e le modifiche alla struttura sono espresse come una sequenza di nuove revisioni. In genere, ogni modifica del contenuto attiva una nuova revisione. Vedi anche Segui collegamento.
  • Versione pagina: Il controllo delle versioni crea uno "snapshot" di una pagina in un momento specifico. In genere, quando una pagina viene attivata viene creata una nuova versione. Per ulteriori informazioni, consulta Utilizzo delle versioni di una pagina.
Come accelerare 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 la immagini di thread rivelare che il punto attivo principale è InMemoryCompactionMap.findEntry, utilizza il seguente parametro con lo strumento oak-run versioni 1.4 o superiore: -Dtar.PersistCompactionMap=true. Tieni presente che -Dtar.PersistCompactionMap Il parametro è stato rimosso nella versione 1.6 di Oak.

In questa pagina