Esta página tiene por objeto proporcionar detalles consolidados y relevantes para las diferentes operaciones de mantenimiento en el repositorio AEM 6.x.

Objetivo

Este artículo proporciona información sobre varias actividades de mantenimiento para AEM 6.x. El mantenimiento del repositorio Oak de AEM es crítico para mantener un sistema eficiente.  La falta de mantenimiento causa inestabilidad, problemas de rendimiento y cortes de espacio en disco.

Mantenimiento de Oak Tar SegmentNodeStore

Mantenimiento del almacén Oak Mongo

Mantenimiento de archivos binarios (BLOB Store o DataStore)

Mantenimiento de purga de flujo de trabajo

Mantenimiento y purga de la versión

Mantenimiento de purga de registros de auditoría

Actividades de mantenimiento para instancias AEM 6.x

Mantenimiento de SegmentNodeStore de Oak Tar

 El SegmentNodeStore es el mecanismo de almacenamiento predeterminado de Oak que se envía con AEM. Esta capa de persistencia escribe datos en archivos tar en crx-quickstart/repository/segmentstore. El almacenamiento es un formato solo para accesorios, por lo que cuando el contenido se crea, actualiza o elimina, los archivos de la carpeta segmentstore solo se agrandan. Con el tiempo, esto puede afectar el rendimiento y la estabilidad de AEM. Para recuperar espacio en disco y mejorar el rendimiento, es necesario ejecutar la compactación de tar, también conocida como Limpieza de revisión, mantenimiento.  La limpieza de revisión puede ejecutarse tanto fuera de línea (con AEM detenido) como en línea (con AEM en marcha). Sin embargo, la limpieza en línea solo es segura para su uso en AEM 6.3 y versiones posteriores. Consulte la documentación relacionada para su versión AEM:

Comparación de la compactación sin conexión y la compactación en línea

La siguiente tabla proporciona una referencia rápida sobre las diferencias entre la limpieza de revisiones en línea y sin conexión:

Compactación sin conexión Compactación en línea
AEM 6.0 - 6.3 6.3 y futuras versiones
Tiempo de inactividad Sin tiempos de inactividad
Limpia todas las revisiones antiguas Limpia las revisiones anteriores a
la última vez que se ejecutó la compactación en línea
Debe ejecutarse hasta su finalización Funciona durante la ventana de mantenimiento
Se ejecuta más rápido Rendimiento restringido por las actividades del sistema
Recomendado para ejecutarse quincenalmente Funciona diariamente (de forma predeterminada, de 02:00 a 05:00)

Para las versiones 6.0 a 6.2 de AEM, la Limpieza de revisión en línea debe ser desactivada, vea este artículo para conocer los pasos a seguir para desactivarla. Además, existen escenarios conocidos en los que puede fallar la limpieza sin conexión. Vea este artículo para evitar estos problemas y mejorar el rendimiento de la compactación sin conexión.

Calendario recomendado

Desde AEM 6.0 a AEM 6.2, se recomienda realizar la compactación sin conexión cada dos semanas.  En AEM 6.3, no se requiere compactación fuera de línea.  En su lugar, se recomienda monitorizar la compactación en línea que está programada (de forma predeterminada) para que se ejecute diariamente de 02:00 a 05:00.

Resultado de registro de muestra

A continuación, se muestran ejemplos de mensajes de registro que muestran las ejecuciones correctas de la limpieza de revisión.

 

Limpieza de revisiones sin conexión para AEM 6.2 / Oak:

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).​

 

Limpieza de revisiones en línea de AEM 6.3:

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: …….​

Mantenimiento del almacén Oak Mongo

Algunos clientes han elegido utilizar MongoDB (DocumentNodeStore) como plataforma de almacenamiento para Oak en lugar de utilizar el Tar SegmentNodeStore predeterminado.  Esta plataforma de almacenamiento proporciona una alta disponibilidad a través de la agrupación de instancias de AEM.  Al igual que el almacenamiento de Tar, todas las escrituras, incluyendo las de borrado, hacen que se escriban más datos.  Para limpiar viejas correcciones de datos innecesarias, ejecute la colección de residuos de revisión DocumentNodeStore (también conocido como Limpieza de revisiones).  Este mantenimiento se configura en todas las versiones de AEM para que se ejecute automáticamente a partir de las 2 de la madrugada todos los días.  La tarea de mantenimiento para configurar esto es la misma que la Limpieza de revisiones en línea de Tar.

La tarea de mantenimiento solo se ejecuta en el nodo líder del cluster AEM contra la réplica primaria del cluster MongoDB.  Funciona así:

  1. Compruebe si existe algún punto de comprobación que tenga más de 24 horas de antigüedad
  2. Consultar MongoDB para documentos borrados que son más antiguos que la corrección
  3. Borrar documentos en lotes
  4. Consultar MongoDB para documentos de revisión "divididos" más antiguos que la corrección
  5. Borrar documentos en lotes

Calendario recomendado

Este mantenimiento debe realizarse al menos una vez al día.  De forma predeterminada, se ejecuta a partir de las 02:00 hasta su finalización.  Sin embargo, cuanto más frecuentemente se ejecuta, más rápido corre.  Además, cuanto más frecuentemente se ejecute, mejor será el rendimiento de escritura en Oak en general.  Tenga en cuenta que mientras se ejecute, afectará al rendimiento de MongoDB.  Solo debería funcionar cuando hay un mínimo de usuarios en el sistema.

Resultado de registro de muestra

La salida de registro de muestra a continuación indica los mensajes de registro inicial y final para una ejecución exitosa de la Colección de residuos de revisión:

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}

Mantenimiento de archivos binarios de Oak (BLOB)

A partir de AEM 6.3, la configuración predeterminada de almacenamiento del repositorio Oak es Tar SegmentStore con un FileDataStore configurado para almacenar archivos binarios.  De forma predeterminada, un almacén de datos guarda archivos binarios de 4 KB o más.  En una instalación predeterminada, el almacén de datos se encuentra en crx-quickstart/repository/datastore en el sistema de archivos del servidor.  Estos archivos incluyen archivos jar, imágenes, javascript, css, paquetes, archivos de índice de lucene y cualquier otro archivo binario subido a AEM.  Estos archivos son referenciados dentro de las revisiones de las propiedades de los nodos binarios en el almacén de nodos.

El almacén de datos está diseñado para almacenar archivos de forma única; es decir, si el mismo archivo se carga en dos ubicaciones diferentes en Oak, solo se almacena un archivo.  Debido a esto, los archivos nunca se eliminan del almacén de datos hasta que se ejecute la colección de residuos del almacén de datos.

El mantenimiento de BLOB GC (también conocido como Colección de residuos del almacén de datos) se aplica al almacenamiento binario File, S3 y Mongo BLOB en Oak.  Consulte la documentación oficial para obtener más detalles sobre este tema:

Calendario recomendado

De forma predeterminada, se trata de una tarea de mantenimiento semanal que se realiza los sábados por la mañana a partir de las 2 de la madrugada y que se ejecuta hasta su finalización.  Se recomienda ejecutar esta tarea de mantenimiento semanalmente para evitar quedarse sin espacio en disco.  Sin embargo, si los volúmenes de almacenamiento tienen mucho espacio, se puede utilizar con menos frecuencia.  La falta de este mantenimiento solo supondrá un riesgo de pérdida de espacio en disco.

Resultado de registro de muestra

El resultado del registro de muestra a continuación muestra los mensajes de registro inicial y final para una ejecución correcta de la colección de residuos del almacén de datos:

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]









Mantenimiento de purga de flujo de trabajo

Cada vez que se inicia un flujo de trabajo en AEM, se crea un historial de flujo de trabajo bajo /etc/workflow/instances en el repositorio Oak.  Con el tiempo, los nodos del historial del flujo de trabajo pueden apilarse y afectar el rendimiento del sistema.  Para evitar esta situación, es necesario ejecutar el mantenimiento de purga de flujo de trabajo.

Vea esta documentación para obtener información detallada sobre cómo configurar y ejecutar esta tarea de mantenimiento.

Calendario recomendado

Esta tarea de mantenimiento debe ejecutarse semanalmente.

Resultado de registro de muestra

Los mensajes de registro que aparecen a continuación muestran una ejecución correcta del mantenimiento de purga de flujo de trabajo:

*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​

Mantenimiento de purga de versión

En una instalación de AEM predeterminada, las versiones se crean al publicar o despublicar páginas o activos, cargar o reemplazar activos.  Las versiones se almacenan como nodos bajo /jcr:system/jcr:versionStorage en el repositorio Oak.  Estos nodos guardan referencias a archivos binarios en el almacén de datos.  Con el tiempo, las versiones se acumulan y esto afecta al rendimiento del sistema y a la utilización del disco.  Los índices de búsqueda, el almacenamiento Tar o Mongo y el almacén de datos aumentan con datos adicionales de las versiones antiguas. Para recuperar el espacio en disco y recuperar el rendimiento del sistema, debe ejecutar la purga de la versión.

  • Consulte esta documentación sobre cómo configurar y ejecutar la purga de la versión.
  • Vea este artículo sobre cómo evitar problemas conocidos con Purga de la versión.

Calendario recomendado

Esta tarea de mantenimiento debe ejecutarse mensualmente.

Resultado de registro de muestra

La purga de versiones solo enviará mensajes a los registros si se realiza con éxito.  Si no logra purgar algunas versiones, lanzará un error y continuará purgando otras versiones.

El siguiente mensaje de registro es un ejemplo de una purga exitosa de una versión:

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

El siguiente error es un ejemplo de una purga de versión fallida:

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

Lucene Binaries Cleanup

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.

Mantenimiento de purga de registros de auditoría

En una instalación de AEM predeterminada, siempre que se crean, cargan, modifican, eliminan o se publican páginas o activos, se crean registros de auditoría.  Los registros de auditoría se almacenan como nodos bajo /var/audit en el repositorio Oak.  Con el tiempo, estos nodos se amontonan y afectan el rendimiento del sistema.  Para evitar esta situación, es necesario ejecutar el mantenimiento del registro de auditoría.

Consulte esta documentación para obtener detalles sobre cómo configurar y ejecutar el Mantenimiento de purga de registro de auditoría.

Calendario recomendado

Esta tarea de mantenimiento debe ejecutarse mensualmente.

Resultado de registro de muestra

Los siguientes mensajes de registro muestran una ejecución correcta de Mantenimiento AuditLog:

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

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea