Raccolta oggetti inattivi in archivio dati data-store-garbage-collection
Quando viene rimossa una risorsa WCM convenzionale, 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 di archivio dati senza riferimenti diventa quindi un "immondizia" che non deve essere conservata. Nei casi in cui sono presenti diverse risorse inutilizzate, è utile eliminarle per preservare lo spazio e ottimizzare le prestazioni di backup e manutenzione dei file system.
Nella maggior parte dei casi, un'applicazione WCM tende a raccogliere informazioni, ma non a eliminarle quasi con la stessa frequenza. Sebbene vengano aggiunte nuove immagini, anche sostituendo le versioni precedenti, il sistema di controllo delle versioni mantiene quella precedente e, se necessario, supporta il ripristino. In questo modo, la maggior parte dei contenuti che consideriamo come aggiunte al sistema vengono effettivamente archiviati in modo permanente. Qual è quindi la fonte tipica di "immondizia" nell'archivio che potremmo voler ripulire?
L’AEM utilizza l’archivio come archivio per diverse attività interne e di manutenzione:
- Pacchetti generati e scaricati
- File temporanei creati per la replica di pubblicazione
- Payload del flusso di lavoro
- Assets creato temporaneamente durante il rendering DAM
Quando uno qualsiasi di questi oggetti temporanei è abbastanza grande da richiedere l'archiviazione nell'archivio dati e quando l'oggetto alla fine non viene più utilizzato, il record dell'archivio dati stesso rimane come "spazzatura". In una tipica applicazione di authoring/pubblicazione WCM, la principale fonte di rifiuti di questo tipo è solitamente il processo di attivazione della pubblicazione. Quando i dati vengono replicati in Publish, vengono prima raccolti in raccolte in un formato 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 quindi vengono memorizzati 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 "Garbage".
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, mantenendo un sistema, i pacchetti possono essere generati e ricostruiti molte volte, ciascuna build determinando un nuovo record dell’archivio dati, che orfana il record della build precedente.
Come funziona la raccolta di oggetti inattivi dell’archivio dati? how-does-data-store-garbage-collection-work
Se l'archivio è stato configurato con un archivio dati esterno, la raccolta di 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 di oggetti inattivi dell'archivio dati in base alle esigenze. In generale, si consiglia di eseguire periodicamente la raccolta di oggetti inattivi dell’archivio dati, ma di tenere conto dei seguenti fattori nella pianificazione della raccolta di oggetti inattivi dell’archivio dati:
- Le raccolte di oggetti inattivi dell’archivio dati richiedono tempo e possono influire sulle prestazioni, pertanto devono essere pianificate di conseguenza.
- La rimozione dei record di Garbage dell’archivio dati non influisce sulle normali prestazioni, 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 di rifiuti dell'archivio dati potrebbe essere rinviata in modo sicuro.
Il Garbage Collector dell’archivio dati prende nota della marca temporale corrente all’inizio del processo. La raccolta viene quindi eseguita utilizzando un algoritmo di pattern a più passate di marcatura/sweep.
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, il file viene individuato nel file system, eseguendo un aggiornamento dei metadati, modificando l'attributo "last modified" (ultima modifica) o MTIME. A questo punto, i file a cui si accede in questa fase diventano più recenti della marca temporale della linea di base iniziale.
Nella seconda fase, il garbage collector dell’archivio dati attraversa la struttura della directory fisica dell’archivio dati in modo molto simile a un "find" (trova). Ha esaminato l’attributo "last modified" o MTIME del file e ha determinato quanto segue:
- 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 entrambi i casi il record è considerato attivo e il file non è cancellato.
- Se l’MTIME è precedente alla marca temporale della linea di base iniziale, il file non è un file a cui si fa riferimento attivamente ed è considerato un’area di cestino rimovibile.
Questo approccio funziona bene per un singolo nodo con un archivio dati privato. Tuttavia, l’archivio dati potrebbe essere condiviso e, in tal caso, i riferimenti live potenzialmente attivi ai record dell’archivio dati provenienti da altri archivi non verranno controllati e i file di riferimento attivi potrebbero essere rimossi per errore. È fondamentale che l’amministratore di sistema comprenda la natura condivisa dell’archivio dati prima di pianificare eventuali raccolte di rifiuti e utilizzi il semplice processo integrato di raccolta dei rifiuti dell’archivio dati solo quando è noto che l’archivio dati non è condiviso.
Esecuzione della raccolta oggetti inattivi dell’archivio dati running-data-store-garbage-collection
Esistono tre modi per eseguire la raccolta di oggetti inattivi dell’archivio dati, a seconda della configurazione dell’archivio dati su cui è in esecuzione AEM:
-
Tramite Pulizia revisioni: un meccanismo di raccolta dei rifiuti utilizzato in genere per la pulizia dell'archivio nodi.
-
Tramite Raccolta oggetti inattivi dell'archivio dati: un meccanismo di raccolta oggetti inattivi specifico per gli archivi dati esterni, disponibile nel dashboard operazioni.
-
Tramite la console JMX.
Se si utilizza TarMK sia come archivio nodi che come archivio dati, è possibile utilizzare Pulizia revisioni per la raccolta di oggetti inattivi sia dell’archivio nodi che dell’archivio dati. Tuttavia, se è configurato un archivio dati esterno, ad esempio Archivio dati del file system, la raccolta di oggetti inattivi dell’archivio dati deve essere attivata in modo esplicito e separata da Pulizia revisioni. La raccolta di oggetti inattivi dell’archivio dati può essere attivata tramite il dashboard operazioni o la console JMX.
La tabella seguente mostra il tipo di raccolta di oggetti inattivi dell’archivio dati che deve essere utilizzato per tutte le distribuzioni dell’archivio dati supportate nell’AEM 6:
Esecuzione della raccolta di oggetti inattivi dell’archivio dati tramite il dashboard operazioni running-data-store-garbage-collection-via-the-operations-dashboard
La finestra di manutenzione settimanale integrata, disponibile tramite Dashboard operazioni, contiene un'attività incorporata per attivare Data Store Garbage Collection all'1 di domenica.
Se devi eseguire la raccolta di oggetti inattivi dell’archivio dati al di fuori di questo periodo di tempo, può essere attivata manualmente tramite il dashboard operazioni.
Prima di eseguire la raccolta di oggetti inattivi dell’archivio dati, verifica che non siano in esecuzione backup in quel momento.
-
Apri il dashboard operazioni con Navigazione > Strumenti > Operazioni > Manutenzione.
-
Fare clic sulla finestra Manutenzione settimanale.
-
Seleziona l'attività Raccolta oggetti inattivi dell'archivio dati, quindi fai clic sull'icona Esegui.
-
La raccolta di oggetti inattivi dell’archivio dati viene eseguita e il relativo stato viene visualizzato nel dashboard.
Esecuzione della raccolta di oggetti inattivi dell’archivio dati tramite la console JMX running-data-store-garbage-collection-via-the-jmx-console
Questa sezione riguarda l’esecuzione manuale della raccolta di oggetti inattivi dell’archivio dati tramite la console JMX. Se l’installazione è configurata senza un archivio dati esterno, ciò non si applica all’installazione. Vedi invece le istruzioni su come eseguire la pulizia revisioni in Gestione dell'archivio.
Per eseguire la raccolta di oggetti inattivi:
-
Nella console di gestione Apache Felix OSGi, evidenzia la scheda Principale e seleziona JMX dal menu seguente.
-
Quindi, cercare e fare clic su Gestione archivio 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 parametromarkOnly, se necessario: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 contrassegno e di 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 dei rifiuti. -
Fare clic su Richiama. CRX esegue la raccolta di oggetti inattivi e indica quando è stata completata.
Cannot perform operation: no service of type BlobGCMBean found dopo la chiamata. Per informazioni sulla configurazione di un archivio dati di file, vedere Configurazione degli archivi di dati e nodi in AEM 6.Automazione della raccolta di oggetti inattivi dell’archivio dati automating-data-store-garbage-collection
Se possibile, la raccolta di oggetti inattivi dell’archivio dati deve essere eseguita quando il carico sul sistema è ridotto, ad esempio al mattino.
La finestra di manutenzione settimanale integrata, disponibile tramite Dashboard operazioni, contiene un'attività incorporata per attivare Data Store Garbage Collection all'1 di domenica. È inoltre consigliabile verificare che al momento non sia in esecuzione alcun backup. L’inizio della finestra di manutenzione può essere personalizzato tramite la dashboard, a seconda delle necessità.
Se non desideri eseguire la raccolta di oggetti inattivi dell’archivio dati con la finestra Manutenzione settimanale nel dashboard Operazioni, puoi anche automatizzarla utilizzando i client HTTP wget o curl. Di seguito è riportato un esempio di come automatizzare la raccolta di oggetti inattivi utilizzando curl:
curl comandi potrebbe essere necessario configurare vari parametri per l'istanza, ad esempio il nome host ( localhost), la porta ( 4502), la password amministratore ( xyz) e vari parametri per l'effettiva raccolta di oggetti inattivi dell'archivio dati.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 https://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean
Il comando curl restituisce immediatamente.
Verifica della coerenza dell’archivio dati checking-data-store-consistency
La verifica di coerenza dell’archivio dati segnala eventuali dati binari mancanti ma a cui si fa ancora riferimento. Per avviare una verifica di coerenza, effettua le seguenti operazioni:
- Passa alla console JMX. Per informazioni sull'utilizzo della console JMX, vedere Risorse di Monitoring Server mediante la console JMX.
- Cercare l'oggetto Mbean BlobGarbageCollection e fare clic su di esso.
- Fare clic sul collegamento
checkConsistency().
Al termine della verifica di coerenza, un messaggio mostra il numero di dati binari segnalati come mancanti. Se il numero è maggiore di 0, controllare error.log per ulteriori dettagli sui 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