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

AEM utilizza il repository come archivio per una serie di attività interne e di gestione dei contenuti:

  • 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 nella directory archivio /var/replication/data. I bundle di dati sono spesso superiori alla 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 "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 nell'ambito della finestra di manutenzione settimanale. L'amministratore di sistema può anche eseguire manualmente la raccolta dei rifiuti dell'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 questa non è 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.

Nota

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

Running Data Store Garbage Collection

Esistono 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 Pulizia revisione: un meccanismo di raccolta 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 Pannello 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 Pannello operazioni o la console JMX.

Nella tabella seguente è illustrato il tipo di raccolta di oggetti inattivi dell'archivio dati che deve essere utilizzato per tutte le distribuzioni di archivi 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 dei dati dall'archivio tramite il Pannello operazioni

La finestra di manutenzione settimanale integrata, disponibile tramite Operations Dashboard, contiene un'attività incorporata per attivare la raccolta dei dati 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 tramite Navigazione -> Strumenti -> Operazioni -> Manutenzione.

  2. Tocca o fai clic sulla finestra Manutenzione settimanale.

    chlimage_1-64

  3. Seleziona l'attività Archivio dati Raccolta rifiuti, quindi tocca o fai clic sull'icona Esegui .

    chlimage_1-65

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

    chlimage_1-66

Nota

L'attività di raccolta dei dati nell'archivio dati sarà visibile solo se hai configurato un archivio dati file esterno. Consulta Configurazione di archivi di nodi e di archivi di dati in AEM 6 per informazioni su come impostare un archivio dati di file.

Esecuzione della raccolta di oggetti inattivi nell'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 è configurata 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.

Nota

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:

  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 andare a https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement).

  3. Fare clic su startDataStoreGC(boolean markOnly).

  4. se necessario, immettete "true" per il markOnly parametro:

    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. Fate clic su Richiama. CRX esegue il processo di garbage collection e indica quando è stato completato.

Nota

La raccolta dei rifiuti dell'archivio dati non raccoglierà i file che sono stati eliminati nelle ultime 24 ore.

Nota

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. Consulta Configurazione di archivi di nodi e di archivi di dati in AEM 6 per informazioni su come impostare un archivio dati di file.

Automating Data Store Garbage Collection

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 Operations Dashboard, contiene un'attività incorporata per attivare la raccolta dei dati 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à.

Nota

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:

ATTENZIONE

Nell'esempio seguente curl possono essere necessari diversi parametri per la propria 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 indesiderati nell'archivio dati 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.

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 chicco BlobGarbageCollection e fare clic su di esso.
  3. Click the checkConsistency() link.

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 se sono error.log disponibili ulteriori dettagli sui file binari mancanti.

Di seguito è riportato un esempio di come i file binari mancanti vengono segnalati 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