Pulizia revisioni
- Si applica a:
- Experience Manager 6.5
- Argomenti:
- Amministrazione
Creato per:
- Amministratore
Introduzione
Ogni aggiornamento del repository crea una revisione del contenuto. Di conseguenza, con ogni aggiornamento, le dimensioni dell’archivio aumentano. Le precedenti revisioni devono essere pulite per liberare le risorse su disco. Questo è importante per evitare una crescita incontrollata dell’archivio. Questa funzionalità di manutenzione è denominata Pulizia revisioni. È disponibile come routine offline a partire da Adobe Experience Manager (AEM) 6.0.
Con AEM 6.3 e versioni successive, è stata introdotta una versione online di questa funzionalità chiamata Online Revision Cleanup (Pulizia delle revisioni online). Rispetto alla funzione di pulizia delle revisioni offline, in cui l'istanza AEM deve essere chiusa, la funzione di pulizia delle revisioni online può essere eseguita mentre l'istanza AEM è online. La funzione Pulizia revisioni online è attivata per impostazione predefinita ed è la modalità consigliata per eseguire la pulizia delle revisioni.
Nota: Guarda il video per un'introduzione e per scoprire come utilizzare la funzione di pulizia delle revisioni in linea.
Il processo di pulizia delle revisioni è costituito da tre fasi: stima, compattazione e pulizia. La stima determina se eseguire la fase successiva (compattazione) o meno in base alla quantità di rifiuti raccolti. Durante la fase di compattazione, i segmenti e i file tar vengono riscritti lasciando fuori il contenuto inutilizzato. La fase di pulizia rimuove quindi i vecchi segmenti, inclusi eventuali rifiuti in essi contenuti. La modalità offline può in genere recuperare più spazio, perché la modalità online deve tenere conto del working set dell’AEM che impedisce la raccolta di segmenti aggiuntivi.
Per ulteriori dettagli sulla pulizia delle revisioni, consulta i seguenti collegamenti:
Inoltre, puoi leggere la documentazione ufficiale di Oak.
Quando utilizzare la pulizia revisioni in linea anziché la pulizia revisioni non in linea?
Pulizia revisioni in linea è la modalità consigliata per eseguire la pulizia revisioni. La pulizia delle revisioni offline deve essere utilizzata solo in casi eccezionali, ad esempio prima della migrazione al nuovo formato di archiviazione o se richiesto dall'Assistenza clienti Adobe.
Eseguire la pulizia delle revisioni online
La funzione di pulizia delle revisioni online è configurata per impostazione predefinita per essere eseguita automaticamente una volta al giorno sia sulle istanze AEM Author che Publish. È sufficiente definire la finestra di manutenzione durante un periodo con l’attività utente meno intensa. È possibile configurare l'attività Pulizia revisioni in linea come indicato di seguito:
-
Nella finestra principale dell'AEM, vai a Strumenti - Operazioni - Dashboard - Manutenzione o punta il browser a:
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
-
Passa il puntatore del mouse su Finestra di manutenzione giornaliera e fai clic sull'icona Impostazioni.
-
Immettere i valori desiderati (ricorrenza, ora di inizio e di fine) e fare clic su Salva.
In alternativa, se si desidera eseguire manualmente l'attività di pulizia delle revisioni, è possibile:
-
Vai a Strumenti - Operazioni - Dashboard - Manutenzione o passa direttamente a
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html -
Fare clic sulla finestra Manutenzione giornaliera.
-
Passa il puntatore sull'icona Pulizia revisioni.
-
Fare clic su Esegui.
Esecuzione della pulizia delle revisioni in linea dopo la pulizia delle revisioni non in linea
Il processo di pulizia delle revisioni consente di recuperare le precedenti revisioni per generazioni. Ciò significa che ogni volta che si esegue la pulizia delle revisioni, viene creata e mantenuta una nuova generazione sul disco. Esiste tuttavia una differenza tra i due tipi di pulizia delle revisioni: la pulizia delle revisioni offline mantiene una generazione mentre la pulizia delle revisioni online ne mantiene due. Pertanto, quando si esegue la pulizia delle revisioni online dopo la pulizia delle revisioni offline si verifica quanto segue:
- Dopo la prima esecuzione della pulizia della revisione online, le dimensioni dell’archivio raddoppiano. Questo accade perché ora ci sono due generazioni che vengono tenute su disco.
- Durante le esecuzioni successive, l’archivio aumenterà temporaneamente durante la creazione della nuova generazione e quindi si stabilizzerà di nuovo alle dimensioni che aveva dopo la prima esecuzione, mentre il processo di pulizia della revisione online recupera la generazione precedente.
Inoltre, tieni presente che a seconda del tipo e del numero di commit, ogni generazione può variare in termini di dimensioni rispetto alla precedente, pertanto la dimensione finale può variare da un’esecuzione all’altra.
Per questo motivo, si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione dell'archivio inizialmente stimata.
Modalità Di Compattazione Completa E Coda
AEM 6.5 introduce due nuove modalità per la fase compattazione del processo di pulizia revisioni in linea:
- La modalità compattazione completa riscrive tutti i segmenti e i file tar nell'intero archivio. La successiva fase di pulizia può quindi rimuovere la quantità massima di oggetti inattivi dall’archivio. Poiché la compattazione completa interessa l'intero archivio, richiede una quantità considerevole di risorse di sistema e tempo per il completamento. La compattazione completa corrisponde alla fase di compattazione nell'AEM 6.3.
- La modalità compattazione tail 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 dall’ultima esecuzione della compattazione completa o di coda. La successiva fase di pulizia può quindi rimuovere solo i rifiuti contenuti nella parte recente dell’archivio. Poiché la compattazione finale interessa solo una parte dell’archivio, richiede notevolmente meno risorse di sistema e meno tempo rispetto alla compattazione completa.
Queste modalità di compattazione rappresentano un compromesso tra efficienza e consumo di risorse: mentre la compattazione di coda è meno efficace, ha anche un impatto minore sul normale funzionamento del sistema. Al contrario, la compattazione completa è più efficace, ma ha un impatto maggiore sul normale funzionamento del sistema.
AEM 6.5 introduce inoltre un meccanismo di deduplicazione dei contenuti più efficiente durante la compattazione, che riduce ulteriormente l'ingombro su disco dell'archivio.
I due grafici seguenti, presentano i risultati dei test di laboratorio interni che illustrano la riduzione dei tempi medi di esecuzione e l'impronta media su disco nel AEM 6.5 rispetto al AEM 6.3:
Come configurare la compattazione completa e finale
La configurazione predefinita esegue la compattazione finale nei giorni feriali e la compattazione completa nelle domeniche. È possibile modificare la configurazione predefinita utilizzando il nuovo valore di configurazione full.gc.days dell'RevisionCleanupTask attività di manutenzione.
Quando si configura il valore full.gc.days, la compattazione completa viene eseguita nei giorni definiti nel valore e la compattazione finale viene eseguita nei giorni non definiti nel valore. Ad esempio, se configuri la compattazione completa per l’esecuzione la domenica, la compattazione finale viene eseguita dal lunedì al sabato. Ad esempio, se configuri la compattazione completa in modo che venga eseguita ogni giorno della settimana, la compattazione finale non viene eseguita affatto.
Inoltre, considera che:
- La compattazione della coda è meno efficace e ha un impatto minore sulle normali operazioni di sistema. Esso è pertanto destinato a essere utilizzato nelle giornate lavorative.
- La compattazione completa è più efficace, ma ha anche un impatto maggiore sulle normali operazioni di sistema. Esso deve pertanto essere utilizzato al di fuori dei giorni lavorativi.
- La compattazione della coda e la compattazione completa devono essere programmate per l'esecuzione nelle ore di minore utilizzo.
Risoluzione dei problemi
Quando utilizzate le nuove modalità di compattazione, tenete presente quanto segue:
- È possibile monitorare l'attività di input/output (I/O), ad esempio: operazioni di I/O, CPU in attesa di I/O, dimensione coda commit. Questo aiuta a determinare se il sistema sta diventando legato all'I/O e richiede un upsize.
RevisionCleanupTaskHealthCheckindica lo stato di integrità complessivo di Pulizia revisioni in linea. Funziona allo stesso modo di AEM 6.3 e non distingue tra compattazione completa e di coda.- I messaggi di registro contengono informazioni rilevanti sulle modalità di compattazione. Ad esempio, all'avvio di Pulizia revisioni in linea, i messaggi di registro corrispondenti indicano la modalità di compattazione. Inoltre, in alcuni casi d'angolo, il sistema ripristina la compattazione completa quando era pianificata l'esecuzione di una compattazione finale e i messaggi di registro indicano questa modifica. I campioni di log riportati di seguito indicano la modalità di compattazione e il passaggio dalla coda alla compattazione completa:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead
Limitazioni note
A volte, l'alternanza tra la modalità di coda e la modalità di compattazione completa ritarda il processo di pulizia. Più precisamente, l’archivio crescerà dopo una compattazione completa (raddoppia in dimensioni). Lo spazio aggiuntivo viene recuperato nella successiva compattazione finale, quando l’archivio scende al di sotto della dimensione di compattazione pre-completa. È inoltre necessario evitare l’esecuzione di attività di manutenzione parallele.
Si consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione del repository inizialmente stimata.
Domande frequenti sulla pulizia delle revisioni online
Considerazioni sull’aggiornamento a AEM 6.5
Il formato di persistenza di TarMK cambia con AEM 6.5. Queste modifiche non richiedono un passaggio di migrazione proattivo. Gli archivi esistenti vengono sottoposti a una migrazione continua, trasparente per l’utente. Il processo di migrazione viene avviato la prima volta che l’AEM 6.5 (o strumenti correlati) accede 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
Nell’AEM 6.3 erano necessarie modifiche al formato di archiviazione, in particolare per migliorare le prestazioni e l’efficacia di Online Revision Cleanup. Queste modifiche non sono compatibili con le versioni precedenti e gli archivi creati con il vecchio segmento di Oak (AEM 6.2 e precedenti) devono essere migrati.
Ulteriori vantaggi derivanti dalla modifica del formato di storage:
- Maggiore scalabilità (dimensioni ottimizzate dei segmenti).
- Raccolta oggetti inattivi dell'archivio dati.
più veloce - Lavoro di base per i miglioramenti futuri.
Esecuzione della pulizia delle revisioni in linea
Offline Revision Cleanup recupera tutto tranne l'ultima generazione rispetto alle ultime due generazioni per Online Revision Cleanup. Se è presente un nuovo archivio, la funzione di pulizia delle revisioni online non recupererà spazio quando viene eseguita per la prima volta dopo la pulizia delle revisioni offline, perché non esiste una generazione abbastanza vecchia da poter essere recuperata.
Inoltre, leggere la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo.
I fattori sono:
- Dimensione archivio
- Caricare 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 la pulizia delle revisioni in linea. Se lo spazio su disco disponibile scende al di sotto di un valore critico, il processo viene annullato. Il valore critico è pari al 25% dell'attuale spazio su disco dell'archivio e non è configurabile.
L'Adobe consiglia di ridimensionare il disco almeno due o tre volte più grande della dimensione dell'archivio inizialmente stimata.
Lo spazio heap libero 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 viene configurato tramite org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. Il valore predefinito è 15%.
Recommendations per il dimensionamento heap di compattazione minimo non è separato dai consigli per il dimensionamento della memoria AEM. Generalmente: Se un'istanza AEM è sufficientemente grande da gestire i casi d'uso e il relativo payload previsto, il processo di pulizia ottiene memoria sufficiente.
- Assicurati che venga eseguito ogni giorno.
- Assicurati che venga eseguito durante le attività minime dell’archivio configurando di conseguenza le finestre di manutenzione nel dashboard operazioni.
- Aumento delle risorse di sistema (CPU, memoria, I/O).
Pulizia revisioni si basa su una fase di stima per decidere se c'è abbastanza immondizia da pulire. Lo stimatore confronta la dimensione corrente con la dimensione dell’archivio dopo l’ultima compattazione. Se la dimensione supera il delta configurato, viene eseguita la pulizia. Il delta di dimensione è impostato su 1 GB. Ciò significa che se la dimensione dell’archivio non è aumentata di 1 GB dall’ultima esecuzione di pulizia, la nuova iterazione di pulizia della revisione viene ignorata.
Di seguito sono riportate le voci di registro pertinenti per la fase di stima:
- Esecuzioni di GC revisioni: Il delta delle dimensioni è N% o N/N (N/N byte), pertanto è in esecuzione la compattazione
- Il catalogo globale delle revisioni non viene eseguito: Il valore delta delle dimensioni è N% o N/N (N/N byte). La compattazione verrà ignorata per il momento
Se nel sistema è presente concorrenza in scrittura, la pulizia delle revisioni online potrebbe richiedere l'accesso esclusivo in scrittura per eseguire il commit delle modifiche al termine di un ciclo di compattazione. Il sistema entra in modalità forceCompact, come spiegato più dettagliatamente nella documentazione di Oak. Durante la forza di compattazione, viene acquisito un blocco di scrittura esclusivo per eseguire il commit delle modifiche senza interferire con le scritture simultanee. Per limitare l’impatto sui tempi di risposta, è possibile definire un valore di timeout. Questo valore è impostato su un minuto per impostazione predefinita, il che significa che se la compattazione forzata non viene completata entro un minuto, il processo di compattazione viene interrotto a favore di commit simultanei.
La durata della forza compatta dipende dai seguenti fattori:
- hardware: in particolare IOPS. La durata diminuisce con più IOPS.
- segment store size: la durata aumenta con le dimensioni dell’archivio segmenti.
In una configurazione di standby a freddo, è necessario configurare solo l'istanza principale per eseguire la pulizia delle revisioni in linea. Nell’istanza in standby, non è necessario pianificare in modo specifico la pulizia delle revisioni online.
L'operazione corrispondente in un'istanza in standby è la pulizia automatica, che corrisponde alla fase di pulizia della pulizia delle revisioni in linea. La pulizia automatica viene eseguita nell'istanza in standby dopo l'esecuzione della pulizia delle revisioni in linea nell'istanza principale.
Le fasi di stima e compattazione non verranno eseguite su un'istanza in standby.
La funzione di pulizia delle revisioni offline può rimuovere immediatamente le precedenti revisioni, mentre la funzione di pulizia delle revisioni online deve tenere conto delle precedenti revisioni a cui fa ancora riferimento lo stack dell'applicazione. Il primo può quindi rimuovere la spazzatura in modo più aggressivo rispetto al secondo, dove l’effetto viene ammortizzato nel corso di alcuni cicli di raccolta della spazzatura.
Inoltre, leggere la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo.
- Negli ambienti Windows, l'accesso regolare ai file è sempre imposto, pertanto l'accesso mappato alla memoria non viene utilizzato. Come consiglio generale, tutta la RAM disponibile deve essere allocata all’heap e la dimensione segmentCache deve essere aumentata. Aumenta segmentCache aggiungendo l’opzione segmentCache.size a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (ad esempio, segmentCache.size=20480). Ricordarsi di lasciare fuori un po' di RAM per il sistema operativo e altri processi.
- In ambienti non Windows, aumentare le dimensioni della memoria fisica per migliorare il mapping della memoria dell'archivio.
Monitoraggio della pulizia delle revisioni online
- Lo spazio su disco deve essere monitorato quando è abilitata la pulizia delle revisioni in linea. La pulizia non viene eseguita o termina in modo preventivo quando lo spazio su disco è insufficiente.
- Controllare i registri per l'ora di completamento della pulizia delle revisioni in linea. 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, si consiglia di pulirli.
Per verificare se la pulizia delle revisioni in linea è stata completata correttamente, controllare i registri.
Ad esempio, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" indica che il passaggio di compattazione è stato completato correttamente a meno che non sia preceduto dal messaggio "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", il che significa che è stato eseguito un carico concorrente eccessivo.
È presente un messaggio "TarMK GC #{}: cleanup completed in {} ({} ms" per il completamento corretto del passaggio di pulizia.
Statistiche relative a stato, avanzamento e stato sono esposte tramite JMX (SegmentRevisionGarbageCollection MBean). Per ulteriori dettagli su SegmentRevisionGarbageCollection MBean, leggere il seguente paragrafo.
È possibile tenere traccia dell'avanzamento tramite l'attributo EstimatedRevisionGCCompletion del SegmentRevisionGarbageCollection MBean.
È possibile ottenere un riferimento di 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 utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività dell'AEM.
- Pulizia revisioni online avviata/interrotta
- La pulizia delle revisioni in linea è composta da tre fasi: stima, compattazione e pulizia. La stima può forzare la compattazione e la pulizia a saltare se l’archivio non contiene abbastanza oggetti inattivi. Nella versione più recente di AEM, il messaggio "
TarMK GC #{}: estimation started" indica 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.
- La pulizia delle revisioni in linea è composta da tre fasi: stima, compattazione e pulizia. La stima può forzare la compattazione e la pulizia a saltare se l’archivio non contiene abbastanza oggetti inattivi. Nella versione più recente di AEM, il messaggio "
- Spazio su disco ottenuto dalla pulizia della revisione
- Lo spazio viene recuperato solo al termine della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di registro "T
arMK GC #{}: cleanup completed in {} ({} ms". Le dimensioni di pulizia di Post sono {} ({} byte) e lo spazio recuperato {} ({} byte). Il peso/profondità della mappa di compattazione è {}/{} ({} byte/{})."
- Lo spazio viene recuperato solo al termine della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di registro "T
- Si è verificato un problema durante la pulizia della revisione
- Esistono molte condizioni di errore, tutte sono contrassegnate da messaggi di registro WARN o ERROR che iniziano 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 la pulizia delle revisioni in linea non è necessario eseguire un controllo dell'integrità dell'archivio.
Tuttavia, è possibile eseguire le azioni seguenti per controllare lo stato dell’archivio dopo la pulizia:
- Un archivio controllo trasversale
- Utilizza lo strumento oak-run al termine del processo di pulizia per verificare la presenza di incoerenze. Per ulteriori informazioni su come eseguire questa operazione, consulta la documentazione di Apache. Per eseguire lo strumento non è necessario arrestare AEM.
Il controllo stato di pulizia revisioni fa parte del dashboard operazioni.
Lo stato è VERDE se l'ultima esecuzione dell'attività di manutenzione di Online Revision Cleanup è stata completata correttamente.
È GIALLO se l'attività di manutenzione di Online Revision Cleanup è stata annullata una volta.
È ROSSO se l'attività di manutenzione di Pulizia revisioni in linea è stata annullata tre volte di seguito. In questo caso è necessaria l'interazione manuale oppure è probabile che la pulizia delle revisioni in linea non riesca più. Per ulteriori informazioni, leggere la sezione Risoluzione dei problemi di seguito.
Inoltre, lo stato di Verifica stato viene reimpostato dopo il riavvio del sistema. Pertanto, un'istanza appena riavviata viene visualizzata in verde sul controllo di integrità della pulizia delle revisioni. È possibile utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività dell'AEM.
Stato, avanzamento e statistiche vengono esposti tramite JMX utilizzando SegmentRevisionGarbageCollection MBean. Consulta anche la documentazione di Oak.
È possibile ottenere un riferimento di 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 utilizzare strumenti di monitoraggio esterni per mantenere i dati oltre il tempo di attività dell'AEM.
I file di registro possono essere utilizzati anche per controllare lo stato, l'avanzamento e le statistiche della pulizia automatica.
- Lo spazio su disco deve essere monitorato durante l'esecuzione della pulizia automatica.
- Tempo di completamento (tramite i registri) per garantire che non vengano superate 2 ore.
- Dimensione dell’archivio segmenti dopo l’esecuzione della pulizia automatica. La dimensione dell’archivio segmenti nell’istanza in standby deve essere approssimativamente uguale a quella nell’istanza primaria.
Risoluzione dei problemi di pulizia delle revisioni online
Puoi eseguire diversi passaggi per trovare e risolvere il problema:
-
Controllare innanzitutto le voci del registro
-
A seconda delle informazioni contenute nei registri, adotta le misure appropriate:
- Se i registri mostrano cinque cicli di compattazione saltati e un timeout sul ciclo
forceCompact, pianificare la finestra di manutenzione in modo che non intervenga quando la quantità di scritture dell'archivio è bassa. È possibile controllare le scritture del repository nello strumento di monitoraggio delle metriche del repository all'indirizzo https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html - Se la pulizia viene interrotta alla fine della finestra di manutenzione, assicurarsi che la configurazione della finestra di manutenzione nell'interfaccia utente Attività di manutenzione sia sufficientemente grande
- Se la memoria heap disponibile non è sufficiente, verificare che l'istanza disponga di memoria sufficiente.
- In caso di reazione tardiva, l’archivio segmenti potrebbe crescere troppo per consentire il completamento della pulizia delle revisioni online anche all’interno di una finestra di manutenzione più lunga. Ad esempio, se nell’ultima settimana non è stata completata correttamente la pulizia delle revisioni online, si consiglia di pianificare una manutenzione offline e di eseguire la pulizia delle revisioni offline per riportare segmenstore a una dimensione gestibile.
- Se i registri mostrano cinque cicli di compattazione saltati e un timeout sul ciclo
SegmentNotFoundException istanze in error.log e come posso eseguire il ripristino?SegmentNotFoundException viene registrato da TarMK quando tenta di accedere a un'unità di archiviazione (un segmento) che non è in grado di trovare. Esistono tre scenari che potrebbero causare il problema:
- Applicazione che aggira i meccanismi di accesso consigliati (come Sling e 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à oltre il tempo di conservazione consentito dalla funzione di pulizia delle revisioni online (24 ore per impostazione predefinita). Questo caso è transitorio e non causa il danneggiamento dei dati. Per il ripristino, è necessario utilizzare lo strumento oak-run per confermare la natura transitoria dell’eccezione (il controllo oak-run non deve segnalare errori). A questo scopo, l’istanza deve essere messa offline e riavviata in seguito.
- Un evento esterno ha causato il danneggiamento dei dati sul disco. Può trattarsi di un errore del disco, di spazio insufficiente o di una modifica accidentale dei file di dati richiesti. In questo caso, l’istanza deve essere messa offline e ripristinata utilizzando il controllo oak-run. Per ulteriori dettagli su come eseguire il controllo oak-run, leggi la seguente documentazione di Apache.
- Risolvi tutte le altre occorrenze tramite l'Assistenza clienti Adobe.
Risoluzione Dei Problemi In Base Ai Messaggi Di Errore
Il file error.log è dettagliato se si verificano problemi durante il processo di pulizia delle revisioni online. La seguente matrice mira a spiegare i messaggi più comuni e a fornire possibili soluzioni:
Eseguire la pulizia delle revisioni offline
CAUTIONL'Adobe fornisce uno strumento denominato Oak-run per eseguire la pulizia delle revisioni. Può essere scaricato nella seguente posizione:
https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/
Lo strumento è un file jar eseguibile che può essere eseguito manualmente per compattare l’archivio. Il processo viene chiamato pulizia revisione offline perché è necessario chiudere l'archivio per eseguire correttamente lo strumento. Assicurati di pianificare la pulizia in base alla finestra di manutenzione.
Per suggerimenti su come migliorare le prestazioni del processo di pulizia, vedere Aumento delle prestazioni di pulizia revisioni non in linea.
NOTE-
Assicurati sempre di avere un backup recente dell’istanza AEM.
Chiudi AEM.
-
(Facoltativo) Usate lo strumento per trovare i punti di controllo precedenti:
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 -
Eseguire la compattazione e attenderne il completamento:
java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
Aumento delle prestazioni della pulizia delle revisioni offline
Lo strumento oak-run introduce diverse funzioni che mirano ad aumentare le prestazioni del processo di pulizia delle revisioni e a ridurre il più possibile la finestra di manutenzione.
L’elenco include diversi parametri della riga di comando, come descritto di seguito:
-
-mmap. È possibile impostarlo 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.
-
-Dcompress-interval. Numero di voci di 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 una velocità effettiva più rapida. Questo parametro è stato rimosso in Oak versione 1.6 e non ha alcun effetto.
-
-Dcompaction-progress-log. Numero di nodi compattati registrati. Il valore predefinito è 150000, il che significa che durante l'operazione vengono registrati i primi nodi compattati 150000. Utilizzalo con il parametro successivo documentato di seguito.
-
-Dtar.PersistCompactionMap. Impostare questo parametro su true per utilizzare spazio su disco anziché memoria heap per la persistenza della mappa di compattazione. Richiede lo strumento oak-run versioni 1.4 e successive. Per ulteriori dettagli, vedi la domanda 3 nella sezione Domande frequenti sulla pulizia delle revisioni offline. Questo parametro è stato rimosso in Oak versione 1.6 e non ha alcun effetto.
-
—forza. Forza la compattazione e ignora una versione dell'archivio segmenti non corrispondente.
CAUTION--force, l'archivio segmenti viene aggiornato alla versione più recente, incompatibile con le versioni precedenti di Oak. Inoltre, considera che non è possibile effettuare alcun downgrade. In genere, questi parametri devono essere utilizzati con cautela e solo se si è esperti di come utilizzarli.Un esempio dei parametri in uso:
java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>
Metodi aggiuntivi per attivare la pulizia delle revisioni
Oltre ai metodi descritti in precedenza, puoi anche attivare il meccanismo di pulizia delle revisioni utilizzando la console JMX come segue:
- Apri la console JMX da http://localhost:4502/system/console/jmx
- Fai clic sull'RevisionGarbageCollection MBean.
- Nella finestra successiva, fai clic su startRevisionGC() e quindi su Invoke per avviare il processo Revision Garbage Collection.
Domande frequenti sulla pulizia delle revisioni offline
- Revisione Oak: Oak organizza tutto il contenuto in una grande gerarchia ad albero costituita da nodi e proprietà. Ogni snapshot o revisione di questa struttura di contenuto non è modificabile e le modifiche alla struttura vengono 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 viene attivata una pagina, viene creata una nuova versione. Per ulteriori informazioni, vedere Utilizzo delle versioni delle pagine.
InMemoryCompactionMap.findEntry, utilizzare il parametro seguente con lo strumento oak-run versioni 1.4 o successive: -Dtar.PersistCompactionMap=true. Il parametro -Dtar.PersistCompactionMap è stato rimosso in Oak versione 1.6.