La tarea de limpieza de revisión se está ejecutando demasiado lenta en el clúster AEM + Oak/Mongo

Vaya a http://aem-host:port/system/console/slinglog e inicie sesión como admin.

Agregar un registrador.

• Archivo de registro:revisiongc.log
• Nivel de registro: Depuración
• Registradores:org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector

Espere hasta que ocurra el siguiente evento de limpieza de revisión lenta.

Ejecute este script bash contra el archivo de registro para obtener conteos de las actualizaciones que fueron limpiadas: 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

Ejemplo de salida (muestra cuántos elementos se eliminaron en varias rutas):

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 estos datos, puede ver si hay índices que se actualizan con demasiada frecuencia y que tal vez puedan ser eliminados. Esto le da una idea de dónde ocurren las actualizaciones más transitorias en el repositorio.  Con esta información, puede trabajar para reducir el número de excesos de escritura en Oak.

Si Revision GC es lento y no encuentra que haya una excesiva actividad de escritura contra los índices de Oak u otras ubicaciones en el sistema, entonces puede investigar el rendimiento de MongoDB.  Revision GC siempre se ejecuta contra la réplica primaria de MongoDB para que pueda investigar los tiempos de consulta y los índices utilizados en el mongod.log.