某些 Creative Cloud 应用程序、服务和功能在中国不可用。
Questo articolo fornisce dettagli sulle varie attività di manutenzione per AEM 6.x. La manutenzione del repository AEM Oak è fondamentale per mantenere un sistema performante. La mancanza di manutenzione causa instabilità, problemi di prestazioni e problemi di spazio sul disco
Manutenzione di Oak Tar SegmentNodeStore
Manutenzione di Oak Mongo Storage
Manutenzione dei file binari (BLOB Store o DataStore)
Manutenzione e pulizia di Workflow
Il SegmentNodeStore è il meccanismo di archiviazione di Oak predefinito che viene fornito con AEM. Questo livello di persistenza salva i dati come file tar in crx-quickstart/repository/segmentstore. L'archiviazione è un formato solo per applicazioni, quindi quando il contenuto viene creato, aggiornato o eliminato, i file nella cartella segmentstore diventano solo più grandi. Nel tempo, questo può influenzare le prestazioni e la stabilità di AEM. Per recuperare spazio su disco e migliorare le prestazioni, è necessario eseguire la compattazione del tar, conosciuta anche come manutenzione "Revision Cleanup". Il Revision Cleanup può essere eseguito sia offline (con AEM non in esecuzione) che online (con AEM in esecuzione). Tuttavia, Il Cleanup online è sicuro solo per l'uso in AEM 6.3 e versioni successive. Vedi la documentazione relativa alla versione AEM:
- Revision Cleanup per AEM 6.0 - 6.2
- Revision Cleanup per AEM 6.3
- Tutorial per il revision cleanup online in AEM 6.3
Confronto tra compattazione offline e online
La tabella seguente fornisce un rapido riferimento sulle differenze tra il revision cleaup online e offline:
| Compattazione offline | Compattazione online |
| AEM 6.0 - 6.3 | 6.3 e versioni future |
| Tempo di inattività richiesto | Nessun tempo di inattività |
| Esegue il cleanup di tutte le vecchie revisioni | Esegue il cleanup delle revisioni prima dell 'ultima volta che è stata eseguita la compattazione online |
| Deve essere eseguito fino al suo completamento | Viene eseguito durante il periodo di manutenzione programmata |
| Funziona più velocemente | Prestazioni limitate dalle attività di sistema |
| Consigliato per l'esecuzione bisettimanale | Viene eseguito tutti i giorni (predefinito 02:00 - 05:00) |
Per le versioni AEM da 6.0 a 6.2, Il Revision Cleanup online deve essere disabilitato, vedi questo articolo per scoprire come. Inoltre, esistono scenari noti in cui il cleanup offline può fallire. Vedi questo articolo per evitare questi problemi e migliorare le prestazioni della compattazione offline.
Per AEM6.0 fino adAEM6.2, si raccomanda di eseguire la compattazione offline due volte alla settimana. Su AEM6.3, la compattazione offline non è richiesta. Si raccomanda invece di monitorare la compattazione online che è programmata (per impostazione predefinita) per l'esecuzione giornaliera dalle 2:00-5:00 del mattino.
Apache Jackrabbit Oak 1.4.13
Compacting crx-quickstart/repository/segmentstore
before
Fri Oct 14 12:19:30 EDT 2016, data00000a.tar
Wed May 17 10:37:46 EDT 2017, data00001b.tar
Fri Oct 14 12:20:22 EDT 2016, data00002a.tar
............
Wed May 17 10:37:45 EDT 2017, data00011b.tar
Sun Jul 16 16:12:39 EDT 2017, journal.log
Fri Oct 14 12:19:24 EDT 2016, repo.lock
size 7.7 GB (7712731491 bytes)
-> compacting
-> cleaning up
-> removed old file data00074a.tar
-> removed old file data00073a.tar
-> removed old file data00072a.tar
….…
-> removed old file data00018b.tar
-> writing new journal.log: a838c3e9-613f-4095-abba-939c437882e7:59384 root
..
..
after
Fri Oct 14 12:19:30 EDT 2016, data00000a.tar
Wed May 17 10:37:46 EDT 2017, data00001b.tar
.............
Wed May 17 10:37:46 EDT 2017, data00003b.tar
Wed May 17 10:37:45 EDT 2017, data00004b.tar
Mon Jul 17 11:11:28 EDT 2017, journal.log
Fri Oct 14 12:19:24 EDT 2016, repo.lock
size 6.4 GB (6385295920 bytes)
removed files [data00057a.tar, data00065a.tar, data00020b.tar, data00018b.tar, data00050b.tar, data00073a.tar, data00058a.tar, data00069a.tar, data00060a.tar, data00063a.tar, data00074a.tar, data00066a.tar, data00055a.tar, data00062a.tar, data00036b.tar, data00070a.tar, data00068a.tar, data00072a.tar, data00067a.tar, data00049b.tar, data00061a.tar, data00056a.tar, data00064a.tar, data00059a.tar]
added files [data00050c.tar, data00065b.tar, data00073b.tar, data00056b.tar, data00072b.tar, data00066b.tar, data00069b.tar, data00063b.tar, data00018c.tar, data00058b.tar, data00060b.tar, data00074b.tar, data00020c.tar, data00059b.tar, data00070b.tar, data00062b.tar, data00061b.tar, data00036c.tar, data00075a.tar, data00057b.tar, data00049c.tar]
Compaction succeeded in 21.76 s (21s).
TarMK GC #2: started TarMK GC #2: ….. TarMK GC #2: estimation started TarMK GC #2: estimation completed in 6.373 ms (6 ms). Segmentstore size has increased since the last garbage collection from 417.9 MB (417905664 bytes) to 844.2 MB (844169728 bytes), an increase of 426.3 MB (426264064 bytes) or 102%. This is greater than sizeDeltaEstimation=100.0 MB (100000000 bytes), so running garbage collection TarMK GC #2: compaction started, … TarMK GC #2: estimated number of nodes to compact is 442708, based on 442307 nodes compacted to 417905664 bytes on disk in previous compaction and current size of 418285056 bytes on disk. TarMK GC #2: compaction cycle 0 completed in 52.96 s (52956 ms). Compacted ff940e56-3a69-4721-ab80-74210b7beae9.00000034 to 8ddf7c10-1af6-41f8-aa99-6b750e09e00b.00000533 TarMK GC #2: …… TarMK GC #2: compaction succeeded in 53.07 s (53072 ms), after 1 cycles TarMK GC #2: cleanup started. TarMK GC #2: current repository size is 530.8 MB (530752512 bytes) …. cleanup marking files for deletion: ……. cleanup completed in 1.584 s (1584 ms). Post cleanup size is 223.9 MB (223906816 bytes) and space reclaimed 306.8 MB (306845696 bytes). Removed files: …… TarMK closed: …….
Alcuni clienti hanno scelto di utilizzare MongoDB (DocumentNodeStore) come piattaforma di archiviazione per Oak invece di utilizzare il Tar SegmentNodeStore predefinito. Questa piattaforma di archiviazione fornisce un'elevata disponibilità tramite il clustering delle istanze AEM. Come per lo spazio di archiviazione Tar, tutte le scritture, incluse le eliminazioni, causano la scrittura di più dati. Per pulire vecchie revisioni non necessarie dei dati, eseguire DocumentNodeStore Raccolta rifiuti revisioni (noto anche come "Pulizia revisioni"). Questa manutenzione è configurata per funzionare automaticamente su tutte le versioni di AEM a partire dalle 2 del mattino di ogni giorno. Il lavoro di manutenzione per configurarlo è lo stesso della Pulizia revisioni online di Tar.
Il lavoro di manutenzione viene eseguito solo sul nodo leader del cluster AEM contro la replica primaria del cluster MongoDB. Funziona così:
- Controlla se esiste un checkpoint più vecchio di 24 ore
- Invia una query a MongoDB per i documenti eliminati che superano l'età massima di revisione
- Elimina i documenti in batch
- Invia una query a MongoDB per documenti di revisione "divisi" che superano l'età massima di revisione
- Elimina i documenti in batch
Questa manutenzione deve essere eseguita almeno una volta al giorno. Per impostazione predefinita viene eseguita a partire dalle 2 del mattino fino al completamento. Tuttavia, più spesso si esegue, più veloce è la sua esecuzione. Inoltre, più spesso si esegue, migliore saranno le prestazioni di scrittura complessive di Oak. Nota che durante l'esecuzione, influenzerà le prestazioni di MongoDB. Si dovrebbe eseguire solo quando ci sono pochissimi utenti sul sistema.
L'output del rlog di esempio riportato di seguito mostra i messaggi di log di inizio e fine per una corretta esecuzione della Raccolta rifiuti di revisioni:
16.08.2017 23:38:26.521 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Starting revision garbage collection. Revisions older than [2017-08-15 23:38:26.516] will be removed
16.08.2017 23:38:26.727 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [2620] documents
16.08.2017 23:38:27.265 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [0] previous documents
16.08.2017 23:38:27.279 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Revision garbage collection finished in 766.2 ms. VersionGCStats{ignoredGCDueToCheckPoint=false, deletedDocGCCount=2620, splitDocGCCount=3, intermediateSplitDocGCCount=0, timeToCollectDeletedDocs=170.4 ms, timeTakenToDeleteDeletedDocs=561.3 ms, timeTakenToCollectAndDeleteSplitDocs=10.52 ms}
A partire da AEM 6.3, la configurazione predefinita dello spazio di archiviazione Oak è il SegmentStore Tar con un FileDataStore configurato per l'archiviazione di file binari. Per impostazione predefinita, un DataStore memorizza file binari di dimensioni pari o superiori a 4 KB. In un'installazione predefinita, il datastore si trova sotto crx-quickstart/repository/datastore sul file system del server. Questi file includono file jar, immagini, javascript, css, pacchetti, file dell'indice di Lucene e qualsiasi altro file binario caricato su AEM. A questi file si fa riferimento all'interno delle revisioni delle proprietà dei nodi binari nel NodeStore.
Il DataStore è progettato per archiviare i file in modo univoco, il che significa che se lo stesso file viene caricato in due diverse posizioni in Oak, esso archivia un solo file. Per questo motivo, i file non vengono mai eliminati dal datastore finché la Raccolta rifiuti di DataStore è in esecuzione.
La manutenzione BLOB GC (cioè la "Raccolta rifiuti di DataStore") si applica a archivi binari BLOB di file, S3 e Mongo su Oak. Vedi la documentazione ufficiale per maggiori dettagli su questo argomento:
Per impostazione predefinita, si tratta di un'operazione di manutenzione settimanale che viene eseguita il sabato mattina a partire dalle 2 del mattino fino al completamento. Si raccomanda di eseguire questa operazione di manutenzione settimanalmente per evitare di esaurire lo spazio su disco. Tuttavia, se i volumi di archiviazione hanno uno spazio ampio, può essere eseguita senza problemi meno frequentemente. Senza questa manutenzione si rischia di sprecare spazio su disco.
L'output del log di esempio riportato di seguito mostra i messaggi di log di inizio e fine per un'esecuzione riuscita della Raccolta rifiuti di DataStore:
Starting Blob garbage collection with markOnly [false] Collected (1024) blob references …. Deleted blobs [……….] …. Blob garbage collection completed in 4.569 s (4568 ms). Number of blobs deleted [6341] with max modification time of [2017-07-16 22:03:55.295]
Ogni volta che un workflow viene avviato in AEM, viene creata una cronologia del workflow in /etc/workflow/instances nell'archivio di Oak. Nel corso del tempo, i nodi della cronologia del workflow possono accumularsi e influire sulle prestazioni del sistema. Per evitare questa situazione, è necessario eseguire la Manutenzione di eliminazione del workflow.
Vedi questa documentazione per i dettagli su come configurare ed eseguire questa operazione di manutenzione.
I messaggi di log qui sotto mostrano un'esecuzione riuscita della Manutenzione di eliminazione del workflow:
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Begin workflow purge with the following parameters:
dry run: false
days old: 0
states: {COMPLETED, ABORTED}
models: {/etc/workflow/models/dam/update_asset/jcr:content/model ,/etc/workflow/models/dam-xmp-writeback/jcr:content/model} purge save threshold: {20} purge query count: {1000}
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Cleaned up 1006 instances
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Finished running Workflow Purge. Purged: 1006 items. Elapsed time (seconds): 0
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.PurgeScheduler Finished running Workflow Purge Configuration: DAM Workflows. Purged: 1006 items. Elapsed time (seconds): 0
In un'installazione AEM predefinita, le versioni vengono create quando si pubblicano o si annulla la pubblicazione di pagine o risorse, si caricano o sostituiscono le risorse. Le versioni sono archiviate come nodi in /jcr:system/jcr:versionStorage nell'archivio Oak. Questi nodi mantengono i riferimenti ai file binari nel datastore. Nel tempo le versioni si accumulano e questo influisce sulle prestazioni del sistema e sull'utilizzo del disco. Gli indici di ricerca, l'archiviazione Tar o Mongo e DataStore si gonfiano di dati aggiuntivi dalle cronologie delle vecchie versioni. Per recuperare spazio su disco e le prestazioni del sistema è necessario eseguire l'eliminazione della versione.
- Vedi questa documentazione su come configurare ed eseguire l'eliminazione della versione.
- Vedi questo articolo per sapere come evitare problemi noti con l'eliminazione della versione.
L'eliminazione della versione invierà messaggi ai log solo se riesce a eliminare le versioni con successo. Se non riesce a eliminare alcune versioni, invia un errore e continua a eliminare altre versioni.
Il messaggio di log qui sotto è un esempio di eliminazione riuscita di una versione:
INFO [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Purged version 1.0 of /content/geometrixx/en/jcr:content
ERROR [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Unable to purge version 1.1 for /content/geometrixx/en/jcr:content : OakIntegrity0001: Unable to delete referenced node javax.jcr.ReferentialIntegrityException: OakIntegrity0001: Unable to delete referenced node at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:235) at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) at org.apache.jackrabbit.oak.jcr.version.ReadWriteVersionManager.removeVersion(ReadWriteVersionManager.java
By using the Lucene Binaries Cleanup task, you can purge lucene binaries and reduce the running data store size requirement. This is because the lucene's binary churn will be re-claimed daily instead of the earlier dependency on a successful data store garbage collection run.
Though the maintenance task was developed to reduce Lucene related revision garbage, there are general efficiency gains when running the task:
- The weekly execution of the data store garbage collection task will complete more quickly
- It may also slightly improve the overall AEM performance
You can access the Lucene Binaries Cleanup task from: AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binaries Cleanup.
In un'installazione AEM predefinita, ogni volta che le pagine o le risorse sono create/caricate, modificate, eliminate o la pubblicazione viene eliminata, vengono creati dei registri di controllo. I log di controllo sono memorizzati come nodi sotto /var/audit nell'archivio Oak. Nel tempo, questi nodi si accumulano e influiscono sulle prestazioni del sistema. Per evitare questa situazione è necessario eseguire la Manutenzione dei log di controllo.
Vedi questa documentazione per i dettagli su come configurare ed eseguire la Manutenzione di eliminazione del log di controllo.
16.08.2017 23:19:48.765 *INFO* [pool-81-thread-1] com.day.cq.audit.impl.AuditLogPurgeScheduler {name = test, type = [PageVersion Created, PageRestored, PageValid, PageMoved, PageDeleted, PageModified, PageCreated, PageInvalid, PageRolled Out], contentPath = /content, minimumAge = 5} activated
16.08.2017 23:19:48.799 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge starting execution
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - Node /var/audit/com.day.cq.wcm.core.page/content does not exist in the repository, skipping current rule execution.
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge execution is over