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.

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 Oak (AEM 6.2 e precedenti) devono essere migrati.

Ulteriori vantaggi derivanti dalla modifica del formato di storage:

• Maggiore scalabilità (dimensioni ottimizzate dei segmenti).
• Più veloce Raccolta oggetti inattivi dell’archivio dati.
  
• Lavoro di base per i miglioramenti futuri.

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, leggi la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo.

La funzione di pulizia delle revisioni online è disponibile solo con le versioni AEM 6.3 e successive. Inoltre, se utilizzi una versione precedente di AEM, devi migrare al nuovo Tar segmento Oak.

• 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 dell’AEM è sufficientemente grande da far fronte ai casi d’uso e al relativo payload previsto, il processo di pulizia ottiene una quantità di 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 Revision GC: Il delta di dimensione è N% o N/N (N/N byte), quindi viene eseguita la compattazione
• Revisione eseguita da GC non eseguire: Il delta della dimensione è N% o N/N (N/N byte), quindi per il momento la compattazione viene ignorata

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

Come viene eseguita la pulizia delle revisioni online in un'istanza in standby?

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, leggi la sezione "Esecuzione della pulizia delle revisioni online dopo la pulizia delle revisioni offline" di questo capitolo.

• In ambienti Windows, l'accesso regolare ai file viene sempre applicato in modo da non utilizzare l'accesso mappato alla memoria. 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 la mappatura della memoria dell'archivio.

• 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 c’era troppo carico simultaneo.

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

Le statistiche relative a stato, avanzamento e stato sono esposte tramite JMX (SegmentRevisionGarbageCollection MBean). Per ulteriori dettagli su SegmentRevisionGarbageCollection MBean, leggi paragrafo successivo.

L'avanzamento può essere tracciato tramite EstimatedRevisionGCCompletion attributo del SegmentRevisionGarbageCollection MBean.

È possibile ottenere un riferimento della voce 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. Gli strumenti di monitoraggio esterno potrebbero essere utilizzati per mantenere i dati oltre il tempo di attività dell’AEM. Consulta la documentazione AEM per allegare i controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.

• 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. Nell’ultima versione dell’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" segna l’inizio della pulizia.
• Spazio su disco ottenuto dalla pulizia della revisione
  • Lo spazio viene recuperato solo al termine della fase di pulizia. Il completamento della fase di pulizia è contrassegnato dal messaggio di registro "TarMK GC #{}: cleanup completed in {} ({} ms". La dimensione di post-pulizia è {} ({} byte) e spazio recuperato {} ({} byte). Peso/profondità mappa compattazione è {}/{} ({} byte/{}).".
• 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 Risoluzione dei problemi in base ai messaggi di errore sezione successiva.

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 Documentazione Di Apache. Non è necessario arrestare l’AEM per eseguire lo strumento.

Il controllo dello stato di pulizia della revisione fa parte del Dashboard operazioni.

Lo stato è VERDE se l'ultima esecuzione dell'attività di manutenzione Pulizia revisioni in linea è stata completata correttamente.

È GIALLO se l'attività di manutenzione Pulizia revisioni in linea è stata annullata una volta.

È ROSSO se l'attività di manutenzione Pulizia revisioni in linea è stata annullata tre volte di seguito. In questo caso è necessaria l’interazione manuale o la pulizia delle revisioni online potrebbe non riuscire più. Per ulteriori informazioni, leggere Risoluzione dei problemi sezione successiva.

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. Gli strumenti di monitoraggio esterno potrebbero essere utilizzati per mantenere i dati oltre il tempo di attività dell’AEM. Consulta la documentazione AEM per allegare i controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.

Come monitorare la pulizia automatica in un'istanza in standby?

Lo stato, l’avanzamento e le statistiche vengono esposti tramite JMX utilizzando SegmentRevisionGarbageCollection MBean. Vedi anche quanto segue Documentazione Oak.

È possibile ottenere un riferimento della voce 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. Gli strumenti di monitoraggio esterno potrebbero essere utilizzati per mantenere i dati oltre il tempo di attività dell’AEM. Vedi anche la documentazione AEM per allegare i controlli sanitari a Nagios come esempio per uno strumento di monitoraggio esterno.

I file di registro possono essere utilizzati anche per controllare lo stato, l'avanzamento e le statistiche della pulizia automatica.

Cosa deve essere monitorato durante la pulizia automatica in un’istanza in standby?

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

• Innanzitutto, controlla le voci di 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 forceCompact pianificare la finestra di manutenzione in modo che non interrompa l'attività quando la quantità di scritture dell'archivio è bassa. Puoi controllare le scritture dell’archivio nello strumento di monitoraggio delle metriche dell’archivio 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.

A SegmentNotFoundException viene registrato da TarMK quando tenta di accedere a un’unità di archiviazione (un segmento) che non riesce a trovare. Esistono tre scenari che potrebbero causare il problema:

1. 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.
2. 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 quanto segue Documentazione di Apache.
3. Risolvi tutte le altre occorrenze tramite Assistenza clienti Adobe.

La dimensione dell’archivio e il numero di revisioni da pulire determinano la durata della pulizia.

• 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 un'istantanea di una pagina in un determinato momento. In genere, quando viene attivata una pagina, viene creata una nuova versione. Per ulteriori informazioni, consulta Utilizzo delle versioni di una pagina.