Quando una risorsa WCM convenzionale viene rimossa, il riferimento al record dell'archivio dati sottostante potrebbe essere rimosso dalla gerarchia dei nodi, ma il record dell'archivio dati rimane inalterato. Questo record dell'archivio dati senza riferimenti diventa quindi "spazzatura" che non deve essere conservata. Nei casi in cui esistono numerose risorse per la gestione dei rifiuti, è utile eliminarle per conservare 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 conserva il vecchio e supporta il ripristino, se necessario. Pertanto, la maggior parte dei contenuti che consideriamo aggiunti al sistema è effettivamente memorizzata in modo permanente. Quindi qual è la fonte tipica di "spazzatura" nel repository che potremmo voler ripulire?
AEM utilizza il repository come archivio per una serie di attività interne e di gestione:
Quando uno 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 "spazzatura". In una tipica applicazione di creazione e pubblicazione WCM, l’origine principale di rifiuti di questo tipo è in genere il processo di attivazione della pubblicazione. Quando i dati vengono replicati in Pubblica, vengono raccolti per la prima volta nelle raccolte in un formato di dati efficiente denominato "Durbo" e memorizzati nell'archivio in /var/replication/data
. I bundle di dati sono spesso più grandi della soglia di dimensione critica per l'archivio dati e vengono quindi archiviati come record dell'archivio dati. Una volta completata la 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 nella directory archivio e quindi per i pacchetti di dimensioni maggiori di 4 KB, nell'archivio dati. Nel corso di un progetto di sviluppo o nel corso del tempo, durante la manutenzione di un sistema, i pacchetti possono essere costruiti e rigenerati più volte, ciascuna build risulta in un nuovo record dell'archivio dati, orfando il record della build precedente.
Se l'archivio è stato configurato con un archivio dati esterno, la raccolta dei rifiuti nell'archivio dati verrà eseguita automaticamente come parte della finestra di manutenzione settimanale. L'amministratore di sistema può anche eseguire manualmente la raccolta dei rifiuti nell'archivio dati in base alle esigenze. In generale, si consiglia di eseguire periodicamente la raccolta dei rifiuti nell'archivio dati, ma di tenere conto dei seguenti fattori nella pianificazione delle raccolte di rifiuti nell'archivio dati:
Il Garbage Collector dell'archivio dati nota innanzitutto la marca temporale corrente all'inizio del processo. La raccolta viene quindi eseguita utilizzando un algoritmo con pattern di contrassegno/sweep con più passate.
Nella prima fase, il Garbage Collector dell'archivio dati esegue una lettura completa di tutto il contenuto del repository. Per ogni oggetto di contenuto che ha un riferimento a un record dell'archivio dati, il file si trova nel file system, eseguendo un aggiornamento dei metadati, modificando l'attributo "last modified" o MTIME. A questo punto, i file a cui si accede in questa fase diventano più recenti rispetto alla marca temporale iniziale della linea di base.
Nella seconda fase, il Garbage Collector dell'archivio dati attraversa la struttura di directory fisica dell'archivio dati nello stesso modo di un "find". Ha esaminato l'attributo "last modified" o MTIME del file ed effettua le seguenti verifiche:
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 repository non sono controllati, e i file di riferimento attivi potrebbero essere eliminati per errore. È fondamentale che l'amministratore di sistema comprenda la natura condivisa dell'archivio dati prima di pianificare le raccolte di rifiuti e che utilizzi solo il semplice processo di raccolta di oggetti inattivi dell'archivio dati incorporato quando è noto che l'archivio dati non è condiviso.
Durante l'esecuzione della raccolta dei dati in un'impostazione dell'archivio dati cluster o condiviso (con Mongo o Segment Tar), il registro potrebbe visualizzare avvisi sull'impossibilità di eliminare alcuni ID BLOB. Ciò accade perché gli ID BLOB eliminati in una precedente raccolta di oggetti inattivi sono erroneamente citati da altri nodi cluster o condivisi che non dispongono di informazioni sulle eliminazioni ID. Di conseguenza, quando viene eseguita la raccolta di oggetti inattivi, viene registrato un avviso quando si tenta di eliminare un ID già eliminato nell'ultima esecuzione. Questo comportamento non influisce sulle prestazioni o sulle funzionalità.
Sono disponibili tre modi per eseguire la raccolta dei rifiuti dell'archivio dati, a seconda dell'impostazione dell'archivio dati in cui AEM in esecuzione:
Tramite Revision Cleanup - un meccanismo di raccolta dei rifiuti generalmente utilizzato per la pulizia dell'archivio nodi.
Tramite Data Store Garbage Collection - un meccanismo di raccolta dei rifiuti specifico per gli archivi di dati esterni, disponibile nel dashboard delle operazioni.
Tramite la console JMX.
Se TarMK viene utilizzato sia come archivio nodi che come archivio dati, Revision Cleanup può essere utilizzato per la raccolta dei rifiuti sia dell'archivio nodi che dell'archivio dati. Tuttavia, se è configurato un archivio dati esterno, ad esempio Archivio dati del file system, la raccolta dei rifiuti dell'archivio dati deve essere attivata in modo esplicito e separato dalla funzione Revision Cleanup. È possibile attivare la raccolta dei rifiuti dell'archivio dati tramite il dashboard delle operazioni o la console JMX.
Nella tabella seguente è illustrato il tipo di raccolta di oggetti inattivi dell'archivio dati che è necessario utilizzare per tutte le distribuzioni dell'archivio dati supportate in AEM 6:
Archivio nodi |
Archivio dati | Meccanismo di raccolta rifiuti |
TarMK | TarMK | Pulizia delle revisioni (i file binari sono allineati con Segment Store) |
TarMK | File system esterno | Attività di raccolta dei dati dall'archivio dati tramite il dashboard operativo Console JMX |
MongoDB | MongoDB | Attività di raccolta dei dati dall'archivio dati tramite il dashboard operativo Console JMX |
MongoDB | File system esterno | Attività di raccolta dei dati dall'archivio dati tramite il dashboard operativo Console JMX |
La finestra di manutenzione settimanale integrata, disponibile tramite il Pannello operazioni, contiene un'attività incorporata per attivare la raccolta dei dati da parte dell'archivio dati alle 1 del mattino della domenica.
Se è necessario eseguire la raccolta dei rifiuti dell'archivio dati al di fuori di questo intervallo di tempo, può essere attivata manualmente tramite il Pannello operazioni.
Prima di eseguire la raccolta dei rifiuti dell'archivio dati è necessario verificare che al momento non siano in esecuzione backup.
Aprite il Pannello operazioni Navigazione -> Strumenti -> Operazioni -> Manutenzione.
Tocca o fai clic su Finestra manutenzione settimanale.
Selezionare l'attività Data Store Garbage Collection, quindi fare clic o toccare l'icona Esegui.
Viene eseguito il processo di garbage collection dell'archivio dati e il relativo stato viene visualizzato nel dashboard.
L'attività di raccolta dei dati nell'archivio dati sarà visibile solo se hai configurato un archivio dati file esterno. Per informazioni su come impostare un archivio dati file, vedere Configurazione di archivi di nodi e di archivi dati in AEM 6.
In questa sezione viene illustrato come eseguire manualmente la raccolta dei rifiuti dell'archivio dati tramite la console JMX. Se l'installazione è impostata senza un archivio dati esterno, questo non si applica all'installazione. Al contrario, vedere le istruzioni su come eseguire la pulizia delle revisioni in Gestione dell'archivio.
Se si esegue TarMK con un archivio dati esterno, è necessario eseguire prima Revision Cleanup per rendere efficace la raccolta dei rifiuti.
Per eseguire la raccolta di oggetti inattivi:
Nella console di gestione Apache Felix OSGi, evidenziare la scheda Principale e selezionare JMX dal menu seguente.
Quindi, cercare e fare clic su Repository Manager MBean (o passare a https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement
).
Fare clic su startDataStoreGC(boolean markOnly).
immettere "true
" per il parametro markOnly
, se necessario:
Opzione | Descrizione |
---|---|
boolean markOnly | Impostate su true solo per contrassegnare i riferimenti e non per eseguire lo sweep nell'operazione di mark e sweep. Questa modalità deve essere utilizzata quando il BlobStore sottostante è condiviso tra più repository diversi. Per tutti gli altri casi, impostatelo su false per eseguire la raccolta completa dei rifiuti. |
Fare clic su Richiama. CRX esegue il processo di garbage collection e indica quando è stato completato.
La raccolta dei rifiuti dell'archivio dati non raccoglierà i file che sono stati eliminati nelle ultime 24 ore.
L'attività di raccolta dei rifiuti dell'archivio dati verrà avviata solo se è stato configurato un archivio dati file esterno. Se l'archivio dati del file esterno non è stato configurato, l'attività restituirà il messaggio Cannot perform operation: no service of type BlobGCMBean found
dopo la chiamata. Per informazioni su come impostare un archivio dati file, vedere Configurazione di archivi di nodi e di archivi dati in AEM 6.
Se possibile, la raccolta dei rifiuti nell'archivio dati deve essere eseguita quando il carico sul sistema è limitato, ad esempio la mattina.
La finestra di manutenzione settimanale integrata, disponibile tramite il Pannello operazioni, contiene un'attività incorporata per attivare la raccolta dei dati da parte dell'archivio dati alle 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à.
Il motivo per non eseguire contemporaneamente è che anche i file dell'archivio dati vecchi (e inutilizzati) vengono sottoposti a backup, in modo che se è necessario ripristinare una vecchia revisione, i file binari sono ancora presenti nel backup.
Se non si desidera eseguire la raccolta dei rifiuti dell'archivio dati con la finestra Manutenzione settimanale nel Pannello operazioni, è possibile automatizzarla anche tramite client HTTP wget o curl. Di seguito è riportato un esempio di come automatizzare il backup utilizzando curl:
Nell'esempio seguente curl
potrebbero essere necessari diversi parametri per la vostra istanza; ad esempio, il nome host ( localhost
), la porta ( 4502
), la password amministratore ( xyz
) e vari parametri per la raccolta di oggetti inattivi dell'archivio dati effettiva.
Di seguito è riportato un comando curl di esempio per richiamare la raccolta di oggetti inattivi dell'archivio dati 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.
La verifica della coerenza dell'archivio dati segnalerà eventuali file binari dell'archivio dati mancanti ma a cui viene fatto ancora riferimento. Per avviare un controllo di coerenza, procedere come segue:
Passate alla console JMX. Per informazioni sull'utilizzo della console JMX, consultate questo articolo.
Cercare il fagiolo Blob GC e fare clic su di esso.
Fare clic sul collegamento checkConsistency()
.
Al termine della verifica di coerenza, verrà visualizzato un messaggio che indica il numero di file binari segnalati come mancanti. Se il numero è maggiore di 0, controllare la error.log
per ulteriori dettagli sui file binari mancanti.
Di seguito è riportato un esempio di come i file binari mancanti vengono segnalati nei file di registro:
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