Archivio dati raccolta oggetti inattivi

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:

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

Come funziona la raccolta dei rifiuti nell'archivio dati?

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:

• Le raccolte di rifiuti dell'archivio dati richiedono tempo e possono avere un impatto sulle prestazioni, pertanto dovrebbero essere pianificate di conseguenza.
• La rimozione dei record inattivi dell'archivio dati non influisce sulle prestazioni normali, pertanto non si tratta di un'ottimizzazione delle prestazioni.
• Se l'utilizzo dello storage e fattori correlati come i tempi di backup non rappresentano un problema, la raccolta dei rifiuti nell'archivio dati potrebbe essere posticipata in modo sicuro.

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:

• Se il MTIME è più recente della marca temporale iniziale della linea di base, il file è stato trovato nella prima fase, oppure è un file completamente nuovo che è stato aggiunto al repository mentre il processo di raccolta era in corso. In uno di questi casi il record è considerato attivo e il file non deve essere eliminato.
• 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 spazzatura 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 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.

Esecuzione della raccolta di oggetti inattivi nell'archivio dati

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:

1. Tramite Revision Cleanup - un meccanismo di raccolta dei rifiuti generalmente utilizzato per la pulizia dell'archivio nodi.

2. Tramite Data Store Garbage Collection - un meccanismo di raccolta dei rifiuti specifico per gli archivi di dati esterni, disponibile nel dashboard delle operazioni.

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

Esecuzione della raccolta di oggetti inattivi nell'archivio dati tramite il dashboard delle operazioni

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.

1. Aprite il Pannello operazioni Navigazione -> Strumenti -> Operazioni -> Manutenzione.

2. Tocca o fai clic su Finestra manutenzione settimanale.

   

3. Selezionare l'attività Data Store Garbage Collection, quindi fare clic o toccare l'icona Esegui.

   

4. Viene eseguito il processo di garbage collection dell'archivio dati e il relativo stato viene visualizzato nel dashboard.

   

Esecuzione della raccolta di oggetti indesiderati dall'archivio dati tramite la console JMX

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.

Per eseguire la raccolta di oggetti inattivi:

1. Nella console di gestione Apache Felix OSGi, evidenziare la scheda Principale e selezionare JMX dal menu seguente.

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

3. Fare clic su startDataStoreGC(boolean markOnly).

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

5. Fare clic su Richiama. CRX esegue il processo di garbage collection e indica quando è stato completato.

Automazione della raccolta di oggetti inattivi nell'archivio dati

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

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:

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.

Verifica della coerenza dell'archivio dati

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:

1. Passate alla console JMX. Per informazioni sull'utilizzo della console JMX, consultate questo articolo.

2. Cercare il fagiolo Blob GC e fare clic su di esso.

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