L'operazione Revision Clean Up è troppo lenta su AEM + Oak/Mongo Cluster

Vai su http://aem-host:port/system/console/slinglog e accedi come amministratore.

Aggiungi un logger.

• File di log: revisiongc.log
• Livello di log: Debug
• Loggers: org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector

Attendi che si verifichi la prossima Revision Clean Up lenta.

Esegui questo script bash contro il file di log per ottenere il conteggio degli aggiornamenti che sono stati ripuliti:cut -d ':' -

-f2,3 revisiongc.log | grep '/' | cut -f1-7 -d '/' | sed 's|\(/etc/workflow/.*/2015-09-[0-9]*\)[_0-9]*\(/.*\)_[0-9]*|\1\2|' | sed 's|\(/var/replication/data/[a-z0-9\-]*\).*|\1|' | sort | uniq -c | sort -nr | less

Esempio di output (mostra quanti elementi sono stati cancellati nei vari percorsi):

1574323 /oak:index/slingeventEventId/
140203 /oak:index/slingResourceType/
130687 /oak:index/nodetype/
130557 /oak:index/event.job.topic/
37277 /oak:index/reference/
35870 /var/replication/data/4e8f3d96-c010-4d2c-bf7b-431b902880d2
...

Con questi dati puoi vedere se ci sono indici che vengono aggiornati troppo spesso e che forse possono essere rimossi. Questo dà un'idea di dove avviene il maggior numero di aggiornamenti transitori nell'archivio.  Con queste informazioni è possibile lavorare per ridurre il numero di scritture eccessive su Oak.

Se Revision GC è lenta e non si scopre che c'è un'eccessiva attività di scrittura contro gli indici Oak o altre posizioni nel sistema, allora si possono studiare le prestazioni del MongoDB.  Revision GC viene sempre eseguita contro la replica primaria di MongoDB in modo da poter studiare i tempi di interrogazione e gli indici utilizzati nel mongod.log.