Pulizia revisioni revision-cleanup

Il formato di persistenza di TarMK cambierà con AEM 6.4. 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.4 (o strumenti correlati) accedono all’archivio.

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

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:

• Migliore scalabilità (dimensioni del segmento ottimizzate).
• Più veloce Raccolta rifiuti dell'archivio dati.
• Lavori a terra per miglioramenti futuri.

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.

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)

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.

• 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).

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

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.

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 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.

• 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.

• 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.

È 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.

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.

• 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.

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.

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.

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.

• 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.

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.

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.

• 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.