Pulizia revisioni
- Argomenti:
- Configuring
Creato per:
- Developer
CAUTIONIntroduzione
Ogni aggiornamento del repository crea una nuova revisione del contenuto. Di conseguenza, con ogni aggiornamento le dimensioni dell'archivio crescono. Per evitare una crescita incontrollata dell'archivio, è necessario ripulire le vecchie revisioni per liberare le risorse del disco. Questa funzionalità di manutenzione è denominata Revision Cleanup (Pulizia delle revisioni). È disponibile come routine offline dal AEM 6.0.
Con AEM 6.3 è 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:
-
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
-
Passa il cursore Finestra Manutenzione giornaliera e fai clic su Impostazioni icona.
-
Immetti i valori desiderati (ricorrenza, ora di inizio, ora di fine) e fai clic su Salva.
In alternativa, se si desidera eseguire manualmente l'attività di pulizia della revisione, è possibile:
-
Vai a Strumenti - Operazioni - Dashboard - Manutenzione o sfogliare direttamente in
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html -
Fai clic sul pulsante Finestra Manutenzione giornaliera.
-
Passa il puntatore del mouse Pulizia revisioni icona.
-
Fai clic su Esegui.
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:
- 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.
- 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.4 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.4 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.4 rispetto alla 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 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
RevisionCleanupTaskHealthCheckindica 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.4
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.
Migrazione a Oak Segment Tar
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.
Esecuzione del cleanup delle revisioni online
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.
Monitoraggio del 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.
È 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.
- 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 "
- 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 "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/{}).".
- Lo spazio viene recuperato solo al completamento della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di log "T
- 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.
TarMK GC #3: cleanup completed" che include le dimensioni dell'archivio e la quantità di rifiuti recuperati.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.
Risoluzione dei problemi del cleanup delle revisioni online
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
forceCompactciclo, 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.
- Se i registri mostrano cinque cicli compatti persi e un timeout sul
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:
- 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.
- 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.
- 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:
Come eseguire il cleanup delle revisioni offline
CAUTION-
Per le versioni Oak Da 1.0.0 a 1.0.11 o Da 1.1.0 a 1.1.6, utilizza la versione oak-run 1.0.11
-
Per le versioni Oak più recente di quanto sopra, utilizza la versione di Oak-run che corrisponde al nucleo Oak dell'installazione di AEM.
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.
NOTE-
Assicurati sempre di avere un backup recente dell'istanza AEM.
AEM.
-
(Facoltativo) Utilizza lo strumento per trovare i vecchi checkpoint:
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore -
(Facoltativo) Quindi, elimina i punti di controllo senza riferimento:
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced -
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.
CAUTION--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:
- Apri la console JMX da http://localhost:4502/system/console/jmx
- Fai clic sul pulsante RevisionGarbageCollection MBean.
- Nella finestra successiva, fai clic su startRevisionGC() e poi Richiama per avviare il processo Revision Garbage Collection.
Domande frequenti sul cleanup delle revisioni offline
- 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.
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.