Archivio dati raccolta oggetti inattivi data-store-garbage-collection
Quando una risorsa WCM convenzionale viene rimossa, il riferimento al record dell'archivio dati sottostante può essere rimosso dalla gerarchia dei nodi, ma il record dell'archivio dati stesso rimane. Questo record dell'archivio dati senza riferimento diventa quindi "spazzatura" che non deve essere conservata. Nei casi in cui esistono diverse risorse di rifiuti, è utile sbarazzarsene per preservare lo spazio e ottimizzare le prestazioni di backup e manutenzione del file system.
Nella maggior parte dei casi, un'applicazione WCM tende a raccogliere informazioni ma non a eliminarle con la stessa frequenza. Anche se vengono aggiunte nuove immagini, anche in sostituzione delle versioni precedenti, il sistema di controllo delle versioni mantiene quello vecchio e supporta il ripristino, se necessario. Pertanto, la maggior parte dei contenuti che consideriamo come aggiunta al sistema viene effettivamente conservata in modo permanente. Quindi qual è la fonte tipica di "spazzatura" nel deposito in cui potremmo voler ripulire?
AEM utilizza l’archivio come archivio per una serie di attività interne e di gestione delle risorse:
- Pacchetti generati e scaricati
- File temporanei creati per la replica di pubblicazione
- Payload del flusso di lavoro
- Risorse create temporaneamente durante il rendering DAM
Quando uno qualsiasi di questi oggetti temporanei è sufficientemente grande da richiedere l'archiviazione nell'archivio dati e quando l'oggetto alla fine smette di essere utilizzato, il record dell'archivio dati stesso rimane come "spazzatura". In una tipica applicazione di authoring/pubblicazione WCM, la più grande fonte di rifiuti di questo tipo è comunemente il processo di attivazione di pubblicazione. Quando i dati vengono replicati in Pubblica, vengono raccolti per la prima volta nelle raccolte in un formato di dati efficiente chiamato "Durbo" e memorizzati nell'archivio sotto /var/replication/data
. I bundle di dati sono spesso più grandi della soglia di dimensione critica per l'archivio dati e quindi vengono archiviati come record dell'archivio dati. Al termine della replica, il nodo in /var/replication/data
viene eliminato, ma il record dell'archivio dati rimane come "spazzatura".
Un'altra fonte di rifiuti recuperabili sono i pacchetti. I dati del pacchetto, come tutto il resto, vengono memorizzati nell’archivio e quindi per i pacchetti di dimensioni superiori a 4 KB, nell’archivio dati. Nel corso di un progetto di sviluppo o nel tempo durante la manutenzione di un sistema, i pacchetti possono essere generati e ricostruiti più volte, ogni build determina un nuovo record dell'archivio dati, orfando il record della build precedente.
Come funziona la raccolta degli oggetti inattivi nell’archivio dati? how-does-data-store-garbage-collection-work
Se il repository è stato configurato con un archivio dati esterno, la raccolta degli oggetti inattivi dell'archivio dati viene eseguita automaticamente come parte della finestra Manutenzione settimanale. L'amministratore di sistema può anche eseguire manualmente la raccolta degli oggetti dell'archivio dati se necessario. In generale, si consiglia di eseguire periodicamente la raccolta degli oggetti inattivi nell’archivio dati, ma di tenere conto dei seguenti fattori nella pianificazione delle raccolte di oggetti inattivi nell’archivio dati:
- Le raccolte di oggetti inattivi dell’archivio dati richiedono tempo e possono influire sulle prestazioni, pertanto dovrebbero essere pianificate di conseguenza.
- La rimozione dei record di oggetti inattivi dell’archivio dati non influisce sulle prestazioni normali, pertanto questa non è un’ottimizzazione delle prestazioni.
- Se l'utilizzo dello storage e i fattori correlati, come i tempi di backup, non rappresentano un problema, allora la raccolta degli oggetti inattivi dell'archivio dati potrebbe essere rinviata in modo sicuro.
Il Garbage Collector dell'archivio dati nota prima la marca temporale corrente all'inizio del processo. La raccolta viene quindi eseguita utilizzando un algoritmo di pattern a punti/sweep multipli.
Nella prima fase, il Garbage Collector dell’archivio dati esegue un attraversamento completo di tutto il contenuto dell’archivio. Per ogni oggetto di contenuto che ha un riferimento a un record dell'archivio dati, ha individuato il file nel file system, eseguendo un aggiornamento dei metadati — modificando l'attributo "last modified" o MTIME. A questo punto i file a cui si accede da questa fase diventano più recenti della marca temporale iniziale della linea di base.
Nella seconda fase, il Garbage Collector dell'archivio dati attraversa la struttura di directory fisica dei dati archiviati nello stesso modo di un "find". Ha esaminato l'attributo "last modified" o MTIME del file ed effettua la seguente determinazione:
- Se il MTIME è più recente della marca temporale della linea di base iniziale, il file è stato trovato nella prima fase oppure è un file completamente nuovo che è stato aggiunto all'archivio mentre il processo di raccolta era in corso. In uno di questi casi il record è considerato attivo e il file non deve essere cancellato.
- Se il valore MTIME è precedente alla marca temporale della linea di base iniziale, il file non è un file a cui viene fatto riferimento attivamente e viene considerato come un file di eliminazione rimovibile.
Questo approccio funziona bene per un singolo nodo con un archivio dati privato. Tuttavia l'archivio dati può essere condiviso e, se ciò significa che i riferimenti live potenzialmente attivi ai record dell'archivio dati di altri archivi non sono controllati e i file di riferimento attivi possono essere rimossi erroneamente. È fondamentale che l’amministratore di sistema comprenda la natura condivisa dell’archivio dati prima di pianificare qualsiasi raccolta di oggetti inattivi e utilizzi solo il semplice processo integrato di raccolta degli oggetti inattivi dell’archivio dati quando è noto che l’archivio dati non è condiviso.
Esecuzione della raccolta degli oggetti inattivi dell'archivio dati running-data-store-garbage-collection
Esistono tre modi per eseguire la raccolta degli oggetti inattivi dell’archivio dati, a seconda della configurazione dell’archivio dati in cui AEM in esecuzione:
-
Via Pulizia revisioni - un meccanismo di raccolta degli oggetti inattivi solitamente utilizzato per la pulizia dell'archivio nodi.
-
Via Raccolta rifiuti dell'archivio dati - un meccanismo di raccolta degli oggetti inattivi specifico per gli archivi di dati esterni, disponibile nel dashboard delle operazioni.
-
Tramite il Console JMX.
Se TarMK viene utilizzato sia come archivio nodi che come archivio dati, allora Revision Cleanup può essere utilizzato per la raccolta degli oggetti inattivi sia dell'archivio nodi che dell'archivio dati. Tuttavia, se un archivio dati esterno è configurato, ad esempio Archivio dati del file system, la raccolta degli oggetti inattivi dell'archivio dati deve essere attivata in modo esplicito separatamente dal cleanup delle revisioni. La raccolta degli oggetti inattivi dell’archivio dati può essere attivata tramite il dashboard delle operazioni o la console JMX.
La tabella seguente mostra il tipo di raccolta degli oggetti inattivi dell’archivio dati che deve essere utilizzato per tutte le distribuzioni di archiviazione dati supportate nel AEM 6:
Esecuzione della raccolta degli oggetti inattivi dell’archivio dati tramite il dashboard delle operazioni running-data-store-garbage-collection-via-the-operations-dashboard
Finestra di manutenzione settimanale integrata, disponibile tramite Dashboard delle operazioni, contiene un'attività incorporata per attivare la Raccolta rifiuti dell'archivio dati all'1 del mattino della domenica.
Se devi eseguire la raccolta degli oggetti inattivi dell’archivio dati al di fuori di questo periodo di tempo, puoi attivarla manualmente tramite il dashboard delle operazioni.
Prima di eseguire la raccolta degli oggetti inattivi dell'archivio dati è necessario verificare che non siano in esecuzione backup in quel momento.
-
Apri il dashboard delle operazioni tramite Navigazione -> Strumenti -> Operazioni -> Manutenzione.
-
Tocca o fai clic su Finestra Manutenzione settimanale.
-
Seleziona la Raccolta rifiuti dell'archivio dati quindi tocca o fai clic su Esegui icona.
-
La raccolta degli oggetti inattivi dell'archivio dati viene eseguita e il relativo stato viene visualizzato nel dashboard.
Esecuzione della raccolta degli oggetti inattivi dell’archivio dati tramite la console JMX running-data-store-garbage-collection-via-the-jmx-console
Questa sezione descrive come eseguire manualmente la raccolta degli oggetti inattivi dell’archivio dati tramite la console JMX. Se l'installazione è configurata senza un archivio dati esterno, questo non si applica all'installazione. Vedi invece le istruzioni su come eseguire la pulizia delle revisioni in Manutenzione dell’archivio.
Per eseguire la raccolta degli oggetti inattivi:
-
Nella console di gestione Apache Felix OSGi, evidenzia la Principale e seleziona JMX dal menu seguente.
-
Quindi, cerca e fai clic su Gestione archivi MBean (o vai a
https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement
). -
Fai clic su startDataStoreGC(booleano markOnly).
-
immetti "
true
" permarkOnly
se richiesto:table 0-row-2 1-row-2 Opzione Descrizione markOnly booleano Impostare su true per contrassegnare solo i riferimenti e non eseguire la sweep nell'operazione di marcatura e sweep. Questa modalità deve essere utilizzata quando il BlobStore sottostante è condiviso tra più archivi diversi. Per tutti gli altri casi impostalo su false per eseguire la raccolta completa degli oggetti inattivi. -
Fai clic su Richiama. CRX esegue la raccolta degli oggetti inattivi e indica quando è stata completata.
Cannot perform operation: no service of type BlobGCMBean found
dopo la chiamata. Vedi Configurazione degli archivi di nodi e degli archivi di dati nel AEM 6 per informazioni su come impostare un archivio dati file.Automazione della raccolta degli oggetti inattivi nell’archivio dati automating-data-store-garbage-collection
Se possibile, è necessario eseguire la raccolta degli oggetti inattivi dell'archivio dati quando il sistema non è caricato, ad esempio la mattina.
Finestra di manutenzione settimanale integrata, disponibile tramite Dashboard delle operazioni, contiene un'attività incorporata per attivare la Raccolta rifiuti dell'archivio dati all'1 del mattino della domenica. È inoltre necessario verificare che al momento non siano in esecuzione backup. L'inizio della finestra di manutenzione può essere personalizzato tramite il dashboard, a seconda delle necessità.
Se non desideri eseguire la raccolta oggetti inattivi dell'archivio dati con la finestra Manutenzione settimanale nel Dashboard delle operazioni, puoi anche automatizzarla utilizzando i client HTTP wget o curl. Di seguito è riportato un esempio di come automatizzare il backup utilizzando curl:
curl
potrebbero essere necessari la configurazione di diversi parametri per l'istanza; ad esempio, il nome host ( localhost
), porta ( 4502
), password amministratore ( xyz
) e vari parametri per l'archivio dati effettivo della raccolta degli oggetti inattivi.Ecco un esempio di comando curl per richiamare l'archivio dati garbage collection tramite la riga di comando:
curl -u admin:admin -X POST --data markOnly=true http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean
Il comando curl ritorna immediatamente.
Verifica della coerenza dell’archivio dati checking-data-store-consistency
Il controllo di coerenza dell'archivio dati segnalerà tutti i file binari dell'archivio dati mancanti ma a cui si fa ancora riferimento. Per avviare un controllo di coerenza, effettua le seguenti operazioni:
-
Vai alla console JMX. Per informazioni su come utilizzare la console JMX, vedi articolo.
-
Cerca il GC Blob Mbean e cliccatela.
-
Fai clic sul pulsante
checkConsistency()
link.
Al termine del controllo di coerenza, un messaggio mostra il numero di binari segnalati come mancanti. Se il numero è maggiore di 0, controlla il error.log
per maggiori dettagli sui binari mancanti.
Di seguito trovi un esempio di come vengono segnalati i file binari mancanti nei registri:
11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs
11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243