Archivio dati raccolta oggetti inattivi

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

Se l'archivio è stato configurato con un archivio dati esterno, la raccolta degli oggetti inattivi dell'archivio dati verrà eseguita automaticamente come parte della finestra di manutenzione settimanale. L'amministratore di sistema può anche eseguire manualmente la raccolta degli oggetti inattivi dell'archivio dati in base alle esigenze. 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.

NOTA

Quando si esegue la raccolta oggetti inattivi in una configurazione dell’archivio dati in cluster o condiviso (con Mongo o Segment Tar), il registro potrebbe visualizzare avvisi sull’impossibilità di eliminare determinati ID BLOB. Questo accade perché gli ID BLOB eliminati in una precedente raccolta oggetti inattivi vengono erroneamente referenziati da altri nodi cluster o condivisi che non hanno informazioni sulle eliminazioni degli ID. Di conseguenza, quando si esegue la raccolta 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à.

Esecuzione della raccolta degli oggetti inattivi dell'archivio dati

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:

  1. Tramite Revision Cleanup - un meccanismo di raccolta degli oggetti inattivi solitamente utilizzato per la pulizia dell'archivio dei nodi.

  2. Tramite Data Store Garbage Collection - un meccanismo di raccolta degli oggetti inattivi 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, 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:

Archivio nodi
Archiviazione dati Meccanismo di raccolta dei rifiuti
TarMK TarMK Pulizia revisioni (i binari sono allineati con l'archivio segmenti)
TarMK File system esterno

Attività di raccolta degli oggetti inattivi nell’archivio dati tramite il dashboard delle operazioni

Console JMX

MongoDB MongoDB

Attività di raccolta degli oggetti inattivi nell’archivio dati tramite il dashboard delle operazioni

Console JMX

MongoDB File system esterno

Attività di raccolta degli oggetti inattivi nell’archivio dati tramite il dashboard delle operazioni

Console JMX

Esecuzione della raccolta degli oggetti inattivi dell'archivio dati tramite il dashboard delle operazioni

La finestra di manutenzione settimanale integrata, disponibile tramite il 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.

  1. Apri il dashboard delle operazioni in Navigazione -> Strumenti -> Operazioni -> Manutenzione.

  2. Tocca o fai clic su Finestra di manutenzione settimanale.

    chlimage_1-64

  3. Seleziona l'attività Archivio dati raccolta oggetti inattivi, quindi tocca o fai clic sull'icona Esegui.

    chlimage_1-65

  4. La raccolta degli oggetti inattivi dell'archivio dati viene eseguita e il relativo stato viene visualizzato nel dashboard.

    chlimage_1-66

NOTA

L'attività Archivio dati raccolta oggetti inattivi sarà visibile solo se hai configurato un archivio dati file esterno. Per informazioni su come impostare un archivio dati file, vedere Configurazione archivi nodi e archivi dati in AEM 6.

Esecuzione della raccolta degli oggetti inattivi dell'archivio dati tramite la console JMX

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. Al contrario, vedi le istruzioni su come eseguire la pulizia delle revisioni in Mantenimento del repository.

NOTA

Se si esegue TarMK con un archivio dati esterno, è necessario eseguire prima Revision Cleanup per rendere efficace la raccolta degli oggetti inattivi.

Per eseguire la raccolta degli oggetti inattivi:

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

  2. Quindi, cerca e fai clic su Repository Manager MBean (o vai a https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement).

  3. Fai clic su startDataStoreGC(boolean markOnly).

  4. Inserisci "true" per il parametro markOnly se necessario:

    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.
  5. Fare clic su Richiama. CRX esegue la raccolta degli oggetti inattivi e indica quando è stata completata.

NOTA

La raccolta degli oggetti inattivi dell'archivio dati non raccoglie i file che sono stati eliminati nelle ultime 24 ore.

NOTA

L'attività di raccolta oggetti inattivi dell'archivio dati verrà avviata solo se hai configurato un archivio dati file esterno. Se non è stato configurato un archivio dati del file esterno, 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 archivi nodi e archivi dati in AEM 6.

Automazione della raccolta degli oggetti inattivi dell'archivio dati

Se possibile, è necessario eseguire la raccolta degli oggetti inattivi dell'archivio dati quando il sistema non è caricato, ad esempio la mattina.

La finestra di manutenzione settimanale integrata, disponibile tramite il 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à.

NOTA

Il motivo per non eseguirlo contemporaneamente è in modo che anche i file dell'archivio dati vecchi (e inutilizzati) vengano sottoposti a backup, in modo che se è necessario eseguire il rollback a una vecchia revisione, i binari siano ancora presenti nel backup.

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:

ATTENZIONE

Nell'esempio seguente curl potrebbero essere necessari diversi parametri per configurare l'istanza; ad esempio, il nome host ( localhost), la porta ( 4502), la password dell'amministratore ( xyz) e vari parametri per l'effettivo archivio dati garbage collection.

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  https://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

Il comando curl ritorna immediatamente.

Controllo della coerenza dell'archivio dati

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:

  1. Vai alla console JMX. Per informazioni su come utilizzare la console JMX, consulta questo articolo.
  2. Cerca il mbean BlobGarbageCollection e fai clic su di esso.
  3. Fai clic sul collegamento checkConsistency() .

Al termine del controllo di coerenza, un messaggio mostra il numero di binari segnalati come mancanti. Se il numero è maggiore di 0, controlla error.log per ulteriori 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 intheblob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243

In questa pagina