Limpieza de revisión

Introducción

Cada actualización del repositorio crea una nueva revisión de contenido. Como resultado, con cada actualización, el tamaño del repositorio crece. Para evitar el crecimiento incontrolado del repositorio, es necesario limpiar las viejas revisiones para liberar recursos de disco. Esta funcionalidad de mantenimiento se denomina Limpieza de revisión. Ha estado disponible como rutina sin conexión desde AEM 6.0.

Con AEM 6.3 se ha introducido una versión en línea de esta funcionalidad denominada Limpieza de revisión en línea. En comparación con la Limpieza de revisión sin conexión, donde la instancia de AEM debe cerrarse, la Limpieza de revisión en línea se puede ejecutar mientras la instancia de AEM está en línea. La limpieza de revisión en línea está activada de forma predeterminada y es la forma recomendada de realizar una limpieza de revisión.

Nota: Consulte el vídeo para obtener una introducción y cómo utilizar la limpieza de revisión en línea.

El proceso de limpieza de revisión consta de tres fases: estimación, compactación y limpiar. La estimación determina si se ejecutará la siguiente fase (compactación) o no en función de la cantidad de basura que se recopilará. Durante la fase de compactación, los segmentos y los archivos tar se reescriben dejando fuera el contenido no utilizado. La fase de limpieza elimina posteriormente los segmentos antiguos, incluida la basura que puedan contener. El modo sin conexión generalmente puede recuperar más espacio porque el modo en línea necesita tener en cuenta AEM conjunto de trabajo que evita que se recopilen segmentos adicionales.

Para obtener más información sobre la limpieza de revisión, consulte los siguientes vínculos:

Además, también puede leer la documentación oficial de Oak.

¿Cuándo se utiliza la limpieza de revisión en línea en lugar de la limpieza de revisión sin conexión?

Limpieza de revisión en línea es la forma recomendada de realizar la limpieza de revisión. La limpieza de revisiones sin conexión solo debe utilizarse de forma excepcional, por ejemplo, antes de migrar al nuevo formato de almacenamiento o si el Servicio de atención al cliente de Adobe le solicita que lo haga.

Cómo ejecutar la limpieza de revisión en línea

La limpieza de revisión en línea está configurada de forma predeterminada para ejecutarse automáticamente una vez al día en las instancias de AEM Author y Publish. Todo lo que debe hacer es definir la ventana de mantenimiento durante un periodo con la menor actividad del usuario. Puede configurar la tarea Limpieza de revisión en línea de la siguiente manera:

  1. En la ventana de AEM principal, vaya a Herramientas - Operaciones - Tablero - Mantenimiento o dirija el navegador a: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Pase el ratón sobre Daily Maintenance Window y haga clic en el icono Settings.

    imagen_1-91

  3. Introduzca los valores deseados (periodicidad, hora de inicio y hora de finalización) y haga clic en Guardar.

    chlimage_1-92

Alternativamente, si desea ejecutar la tarea de limpieza de revisión manualmente, puede:

  1. Vaya a Herramientas - Operaciones - Tablero - Mantenimiento o vaya directamente a https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. Haga clic en Daily Maintenance Window.

  3. Pase el ratón sobre el icono Limpieza de revisión.

  4. Haga clic en Ejecutar.

    imagen_1-93

Ejecución de la limpieza de revisión en línea después de la limpieza de revisión sin conexión

El proceso de limpieza de revisiones reclama viejas revisiones por generaciones. Esto significa que cada vez que ejecuta la limpieza de revisión, se crea una nueva generación y se mantiene en el disco. Sin embargo, hay una diferencia entre los dos tipos de limpieza de revisión: la limpieza de revisiones sin conexión mantiene una generación mientras que la limpieza de revisiones en línea mantiene dos generaciones. Por lo tanto, cuando ejecuta la limpieza de revisión en línea después de la limpieza de revisión sin conexión, sucede lo siguiente:

  1. Después de ejecutar la primera limpieza de revisión en línea, el repositorio tendrá un tamaño doble. Esto sucede porque ahora hay dos generaciones que se mantienen en disco.
  2. Durante las ejecuciones posteriores, el repositorio crecerá temporalmente mientras se crea la nueva generación y, a continuación, se estabilizará de nuevo con el tamaño que tenía después de la primera ejecución, ya que el proceso de limpieza de revisiones en línea reclama la generación anterior.

Además, tenga en cuenta que, según el tipo y el número de confirmaciones, cada generación puede variar en tamaño en comparación con la anterior, por lo que el tamaño final puede variar de una ejecución a otra.

Debido a este hecho, se recomienda dimensionar el disco al menos dos o tres veces más grande que el tamaño del repositorio estimado inicialmente.

Modos de compactación completos y finales

AEM 6.4 presenta dos nuevos modelos para la ​fase de compactación del proceso de limpieza de revisión en línea:

  • El modo compactación completa reescribe todos los segmentos y archivos tar en todo el repositorio. La siguiente fase de limpieza puede eliminar la cantidad máxima de basura en el repositorio. Dado que la compactación completa afecta a todo el repositorio, requiere una cantidad considerable de recursos del sistema y tiempo para completarse. La compactación completa corresponde a la fase de compactación de la AEM 6.3.
  • El modo tail compaction reescribe solo los segmentos y archivos tar más recientes del repositorio. Los segmentos y archivos tar más recientes son los que se han añadido desde la última vez que se ejecutó la compactación completa o de cola. La siguiente fase de limpieza solo puede eliminar la basura contenida en la parte reciente del repositorio. Dado que la compactación de cola solo afecta a una parte del repositorio, requiere considerablemente menos recursos y tiempo para completar que la compactación completa.

Estos modos de compactación constituyen un equilibrio entre la eficiencia y el consumo de recursos: aunque la compactación de cola es menos eficaz, también tiene menos impacto en el funcionamiento normal del sistema. Por el contrario, la compactación completa es más eficaz, pero tiene un mayor impacto en el funcionamiento normal del sistema.

AEM 6.4 también introduce un mecanismo de deduplicación de contenido más eficiente durante la compactación, lo que reduce aún más la huella en disco del repositorio.

Los dos gráficos siguientes presentan resultados de pruebas internas de laboratorio que ilustran la reducción de los tiempos de ejecución promedio y de la huella media en disco en el AEM 6.4 en comparación con el AEM 6.3:

onrc-duration-6_4vs63 segmentstore-6_4vs63

Configuración de la compactación completa y de cola

La configuración predeterminada ejecuta una compactación de cola en días de semana y una compactación completa los domingos. La configuración predeterminada se puede cambiar utilizando el nuevo valor de configuración full.gc.days de la RevisionCleanupTask tarea de mantenimiento.

Al configurar el valor full.gc.days tenga en cuenta que la compactación completa se ejecutará durante los días definidos en el valor y la compactación de cola se ejecutará durante los días que no estén definidos en el valor. Por ejemplo, si configura la compactación completa para que se ejecute el domingo, la compactación de cola se ejecutará de lunes a sábado. Si, por ejemplo, configura la compactación completa para que se ejecute todos los días de la semana, la compactación de cola no se ejecutará en absoluto.

Además, tenga en cuenta que:

  • La compactación de cola es menos eficaz y tiene menos impacto en las operaciones normales del sistema. Por lo tanto, está previsto que se ejecute durante los días hábiles.
  • La compactación completa es más eficaz, pero también tiene un mayor impacto en las operaciones normales del sistema. Por lo tanto, está previsto que se utilice fuera de los días hábiles.
  • La compactación de cola y la compactación completa deben programarse para que se ejecuten durante las horas de menor actividad.

Solución de problemas

Cuando utilice los nuevos modos de compactación, tenga en cuenta lo siguiente:

  • Puede monitorizar la actividad de entrada/salida (E/S), por ejemplo: Operaciones de E/S, CPU esperando IO, confirmar tamaño de cola. Esto ayuda a determinar si el sistema se está volviendo enlazado a E/S y requiere un cambio de tamaño.
  • El RevisionCleanupTaskHealthCheck indica el estado general de la limpieza de revisión en línea. Funciona del mismo modo que en el AEM 6.3 y no distingue entre compactación completa y de cola.
  • Los mensajes de registro contienen información relevante sobre los modos de compactación. Por ejemplo, cuando se inicia la limpieza de revisión en línea, los mensajes de registro correspondientes indicarán el modo de compactación. Además, en algunos casos de esquina, el sistema volverá a la compactación completa cuando se programó para ejecutar una compactación de cola y los mensajes de registro indicarán este cambio. Las muestras de registro siguientes indican el modo de compactación y el cambio de cola a compactación completa:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Limitaciones conocidas

En algunos casos, la alternancia entre los modos de cola y compactación completa retrasa el proceso de limpieza. Más precisamente, el repositorio crecerá después de una compactación completa (su tamaño se duplicará). El espacio adicional se regenerará en la siguiente compactación de cola, cuando el repositorio caerá por debajo del tamaño de compactación pre-completo. También deben evitarse las ejecuciones de tareas de mantenimiento paralelas.

Se recomienda dimensionar el disco al menos dos o tres veces más grande que el tamaño del repositorio estimado inicialmente.

Preguntas más frecuentes sobre la limpieza de revisiones en línea

Consideraciones de actualización de AEM 6.4

Preguntas Respuestas
¿Qué debo tener en cuenta al actualizar a AEM 6.4?

El formato de persistencia de TarMK cambiará con AEM 6.4. Estos cambios no requieren un paso de migración proactiva. Los repositorios existentes se migrarán progresivamente, lo que es transparente para el usuario. El proceso de migración se inicia la primera vez AEM 6.4 (o herramientas relacionadas) acceder al repositorio.

Una vez iniciada la migración al formato de persistencia AEM 6.4, el repositorio no se puede volver al formato de persistencia AEM 6.3 anterior.

Migración a Oak Segment Tar

Preguntas Respuestas
¿Por qué necesito migrar el repositorio?

En AEM 6.3 se necesitaron cambios en el formato de almacenamiento, especialmente para mejorar el rendimiento y la eficacia de la limpieza de revisión en línea. Estos cambios no son compatibles con versiones anteriores, y los repositorios creados con el segmento Oak antiguo (AEM 6.2 y anteriores) deben migrarse.

Ventajas adicionales de cambiar el formato de almacenamiento:

  • Mejor escalabilidad (tamaño de segmento optimizado).
  • Colección de residuos del almacén de datos más rápida.
  • Masa de trabajo para futuras mejoras.
¿Sigue siendo compatible el formato Tar anterior? Solo se admite el nuevo Oak Segment Tar con AEM 6.3.
¿La migración de contenido siempre es obligatoria? Sí. A menos que comience con una instancia nueva, siempre tendrá que migrar el contenido.
¿Puedo actualizar a la versión 6.3 y realizar la migración más tarde (por ejemplo, utilizando otra ventana de mantenimiento)? No, como se ha explicado anteriormente, la migración de contenido es obligatoria.
¿Se puede evitar el tiempo de inactividad al migrar? No. Este es un esfuerzo único que no se puede realizar en una instancia en ejecución.
¿Qué sucede si se ejecuta accidentalmente con el formato de repositorio incorrecto? Si intenta ejecutar el módulo oak-segment en un repositorio oak-segment-tar (o viceversa), el inicio fallará con un IllegalStateException con el mensaje "Formato de segmento no válido". No se dañará ningún dato.
¿Será necesario un reíndice de los índices de búsqueda? No. La migración de oak-segment a oak-segment-tar introduce cambios en el formato del contenedor. Los datos contenidos no se ven afectados y no se modificarán.
¿Cómo calcular mejor el espacio en disco esperado durante y después de la migración? La migración equivale a recrear el almacén de segmentos en el nuevo formato. Se puede usar para calcular el espacio de disco adicional necesario durante la migración. Después de la migración, se puede eliminar el antiguo almacén de segmentos para recuperar espacio.
¿Cómo se puede estimar mejor la duración de la migración? El rendimiento de la migración puede mejorarse considerablemente si se ejecuta offline revision cleanup antes de la migración. Se recomienda a todos los clientes que lo ejecuten como requisito previo del proceso de actualización. En general, la duración de la migración debe ser similar a la duración de la tarea de limpieza de revisión sin conexión, suponiendo que la tarea de limpieza de revisión sin conexión se haya ejecutado antes de la migración.

Ejecución de la limpieza de revisión en línea

Preguntas Respuestas
¿Con qué frecuencia se debe ejecutar la limpieza de revisión en línea? Una vez al día. Esta es la configuración predeterminada en el Tablero de operaciones.
¿Cómo puedo configurar la hora de inicio de la tarea de mantenimiento Limpieza de revisión en línea ? Consulte la sección Cómo ejecutar la limpieza de revisión en línea.
¿Existe una frecuencia máxima que no debe superarse para la limpieza de revisión en línea? Se recomienda ejecutar la limpieza de revisión en línea una vez al día, según la configuración predeterminada.
¿Cuáles son los indicadores clave que determinan la frecuencia con la que se debe ejecutar la limpieza de revisión en línea? No es necesario determinar la frecuencia, ya que la limpieza de revisión en línea está configurada como tarea de mantenimiento y se ejecuta automáticamente cada día.
¿Por qué la limpieza de revisión en línea no recupera ningún espacio cuando se ejecuta por primera vez? Limpieza de revisión en línea reclama viejas revisiones por generaciones. Se genera una nueva generación cada vez que se ejecuta la limpieza de revisión. Solo se recuperará el contenido que tenga al menos dos generaciones, lo que significa que en una primera ejecución no hay nada que reclamar.
¿Por qué la primera limpieza de revisión en línea no recupera ningún espacio cuando se ejecuta después de la limpieza de revisión sin conexión?

La limpieza de revisión sin conexión está reclamando todo menos la última generación comparada con las últimas dos generaciones para limpieza de revisión en línea. En el caso de un repositorio nuevo, la limpieza de revisión en línea no recuperará ningún espacio cuando se ejecute por primera vez después de la limpieza de revisión sin conexión porque no hay una generación lo suficientemente antigua como para ser reclamada.

Además, lea la sección "Ejecución de la limpieza de revisión en línea después de la limpieza de revisión sin conexión" de este capítulo.

¿Generalmente Autor y Publicación tendrían diferentes ventanas de Limpieza de revisión en línea? Esto depende del horario de oficina y de los patrones de tráfico de la presencia en línea del cliente. Las ventanas de mantenimiento deben configurarse fuera de los principales tiempos de producción para permitir la mejor eficacia de limpieza. Para varias instancias de AEM Publish (granja TarMK), las ventanas de mantenimiento para la limpieza de revisión en línea deben escalonar.
¿Existen requisitos previos para ejecutar la limpieza de revisión en línea?

Limpieza de revisión en línea solo está disponible con AEM versión 6.3 y posteriores. Además, si utiliza una versión anterior de AEM, debe migrar al nuevo Tar de segmento Oak.

¿Cuáles son los factores que determinan la duración de la limpieza de revisión en línea? Los factores son:
  • Tamaño del repositorio
  • Carga en el sistema (solicitudes por minuto, específicamente operaciones de escritura)
  • Patrón de actividad (lecturas frente a escrituras)
  • Especificaciones de hardware (rendimiento de CPU, memoria, IOPS)
¿Pueden los autores seguir trabajando mientras se ejecuta la limpieza de revisión en línea? Sí, la Limpieza de revisiones en línea puede lidiar con escrituras simultáneas. Sin embargo, la limpieza de revisiones en línea funciona de forma más rápida y eficaz sin transacciones de escritura concurrentes. Se recomienda programar la tarea de mantenimiento Limpieza de revisión en línea para un tiempo relativamente tranquilo sin mucho tráfico.
¿Cuáles son los requisitos mínimos de espacio en disco y memoria acumulada al ejecutar la limpieza de revisión en línea?

El espacio en disco se monitorea continuamente durante la limpieza de revisión en línea. Si el espacio en disco disponible cae por debajo de un valor crítico, el proceso se cancelará. El valor crítico es el 25% de la huella de disco actual del repositorio y no es configurable.

Se recomienda dimensionar el disco al menos dos o tres veces más grande que el tamaño del repositorio estimado inicialmente.

Durante el proceso de limpieza, se monitoriza continuamente el espacio libre en pilas. Si el espacio libre en montículos cae por debajo de un valor crítico, el proceso se cancela. El valor crítico se configura mediante org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. El valor predeterminado es 15%.

Recommendations para el tamaño mínimo de la pila de compactación no está separado de las recomendaciones de tamaño de la memoria AEM. Como regla general: Si una instancia de AEM tiene el tamaño suficiente para hacer frente a los casos de uso y a la carga útil esperada en ellos, el proceso de limpieza obtendrá suficiente memoria.

¿Cuál es el impacto esperado en el rendimiento al ejecutar la limpieza de revisión en línea? La limpieza de revisión en línea es un proceso en segundo plano que lee desde el repositorio y escribe en él simultáneamente a las operaciones normales del sistema. En particular, es posible que necesite adquirir acceso exclusivo al repositorio durante un corto periodo de tiempo, evitando que otros subprocesos escriban en el repositorio.
¿Durante cuánto tiempo se espera que se ejecute la limpieza de revisión en línea? No debería tardar más de 2 horas en ejecutarse de acuerdo con las últimas pruebas de rendimiento que realizamos internamente.
¿Qué debe hacerse si la limpieza de revisión en línea tarda más?
  • Asegúrese de que se ejecuta a diario.
  • Asegúrese de que se ejecute durante las actividades mínimas del repositorio configurando las ventanas de mantenimiento en el panel de operaciones en consecuencia.
  • Aumente los recursos del sistema (CPU, memoria, E/S).
¿Qué sucede si la limpieza de revisión en línea supera las ventanas de mantenimiento configuradas? Asegúrese de que otras tareas de mantenimiento no retrasen su ejecución. Este podría ser el caso si se ejecutan más tareas de mantenimiento que Limpieza de revisión en línea dentro de la misma ventana de mantenimiento. Tenga en cuenta que las tareas de mantenimiento se ejecutan secuencialmente sin un orden configurable.
¿Por qué se omite la colección de residuos de revisión?

Limpieza de revisión se basa en una fase de estimación para decidir si hay suficiente basura para limpiar. El estimador compara el tamaño actual con el tamaño del repositorio después de la última compactación. Si el tamaño supera el delta configurado, se ejecutará la limpieza. El tamaño delta se establece en 1 GB. Esto significa que si el tamaño del repositorio no aumentó en 1 GB desde la última ejecución de limpieza, se omitirá la nueva iteración de limpieza de revisión.

A continuación se muestran las entradas de registro relevantes para la fase de estimación:

  • Revision GC se ejecutará: El delta de tamaño es N% o N/N (N/N bytes), por lo que se ejecuta compactación
  • La revisión de GC no se ejecutará: El delta del tamaño es N% o N/N (N/N bytes), por lo que se omite la compactación por ahora
¿Es posible anular de forma segura la compactación automática si el impacto en el rendimiento es demasiado alto? Sí. Desde AEM 6.3 se puede detener de forma segura a través de la ventana de tareas de mantenimiento dentro del panel de operaciones o a través de JMX.
Si la instancia de AEM se apaga durante una tarea de limpieza programada, ¿el proceso se interrumpe de forma segura o el apagado se bloquea hasta que la compactación haya finalizado? La limpieza de revisión se interrumpirá y el repositorio se cerrará de forma segura.
¿Qué sucede cuando el sistema se bloquea durante la limpieza de revisión en línea? No existe riesgo de corrupción de datos en estos casos. Las sobras de basura se limpiarán con una ejecución posterior.
¿Cuál es el impacto de no ejecutar la limpieza de revisión en línea? Degradación del rendimiento a lo largo del tiempo.
¿Qué revisiones se están recopilando? De forma predeterminada, la limpieza de revisión en línea solo recopila revisiones que tengan al menos 24 horas de antigüedad.
¿Qué sucede en caso de demasiada interferencia de escrituras simultáneas en el repositorio?

Si hay concurrencia de escritura en el sistema, la limpieza de revisión en línea puede requerir acceso de escritura exclusivo para poder confirmar los cambios al final de un ciclo de compactación. El sistema entrará en forceCompact mode, como se explica con más detalle en la documentación de oak. Durante la fuerza compacta, se adquiere un bloqueo de escritura exclusivo para confirmar finalmente los cambios sin que interfiera ninguna escritura concurrente. Para limitar el impacto en los tiempos de respuesta, se puede definir un valor de tiempo de espera. Este valor se establece en 1 minuto de forma predeterminada, lo que significa que si force Compact no se completa en 1 minuto, el proceso de compactación se anulará en favor de confirmaciones simultáneas.

La duración del pacto de fuerza depende de los siguientes factores:

  • hardware: específicamente IOPS. La duración disminuye con más IOPS.
  • tamaño del almacén de segmentos: la duración aumenta con el tamaño del almacén de segmentos.

¿Cómo se ejecuta la limpieza de revisión en línea en una instancia de espera?

En una configuración de espera en frío, solo la instancia principal debe configurarse para ejecutar la limpieza de revisión en línea. En la instancia de espera, la limpieza de revisión en línea no necesita programarse específicamente.

La operación correspondiente en una instancia de espera es la limpieza automática, que corresponde a la fase de limpieza de la limpieza de revisión en línea. La limpieza automática se ejecuta en la instancia de espera después de la ejecución de la limpieza de revisión en línea en la instancia principal.

Las fases de estimación y compactación no se ejecutarán en una instancia de espera.

¿La limpieza de revisión sin conexión es capaz de liberar más espacio en disco que la limpieza de revisión en línea?

La limpieza de revisión sin conexión puede eliminar inmediatamente las revisiones antiguas, mientras que la limpieza de revisión en línea debe tener en cuenta las revisiones antiguas a las que sigue haciendo referencia la pila de aplicaciones. Por lo tanto, el primero puede eliminar la basura de manera más agresiva que el segundo, donde el efecto se amortiza durante algunos ciclos de recolección de basura.

Además, lea la sección "Ejecución de la limpieza de revisión en línea después de la limpieza de revisión sin conexión" de este capítulo.

¿Alguna consideración sobre las operaciones de archivos asignados a memoria?
  • En entornos Windows, el acceso a archivos regular siempre se aplica, por lo que no se utiliza el acceso asignado a memoria. Como consejo general, toda la RAM disponible debe asignarse a la pila y el tamaño de segmentCache debe aumentarse. Aumente segmentCache agregando la opción segmentCache.size a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (por ejemplo, segmentCache.size=20480). Recuerde dejar fuera parte de la RAM para el sistema operativo y otros procesos.
  • En entornos que no son de Windows, aumente el tamaño de la memoria física para mejorar la asignación de memoria del repositorio.

Monitorización de la limpieza de revisión en línea

¿Qué debe monitorizarse durante la limpieza de revisión en línea?
  • El espacio en disco debe monitorizarse cuando la limpieza de revisión en línea está habilitada. La limpieza no se ejecutará o terminará de forma preventiva cuando no haya suficiente espacio en disco.
  • Compruebe los registros para la hora de finalización de la limpieza de revisión en línea. No debe tardar más de 2 horas.
  • Número de puntos de comprobación. Si hay más de 3 puntos de comprobación cuando se ejecuta la compactación, se recomienda limpiar los puntos de comprobación.
¿Cómo comprobar si la limpieza de revisión en línea se ha completado correctamente?

Puede comprobar si la limpieza de revisión en línea se ha completado correctamente comprobando los registros.

Por ejemplo, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" significa que el paso de compactación se completó correctamente a menos que esté precedido del mensaje "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", lo que significa que hubo demasiada carga simultánea.

Por lo tanto, hay un mensaje "TarMK GC #{}: cleanup completed in {} ({} ms" para completar correctamente el paso de limpieza.

¿Dónde podemos encontrar las estadísticas de las últimas ejecuciones de limpieza de revisión en línea ?

El estado, el progreso y las estadísticas se exponen a través de JMX (SegmentRevisionGarbageCollection MBean). Para obtener más información sobre el SegmentRevisionGarbageCollection MBean, lea el párrafo siguiente.

El progreso se puede rastrear mediante el atributo EstimatedRevisionGCCompletion del SegmentRevisionGarbageCollection MBean.

Puede obtener una referencia del MBean mediante el ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Tenga en cuenta que las estadísticas solo están disponibles desde el último inicio del sistema. Se podrían aprovechar las herramientas de monitorización externa para mantener los datos más allá AEM tiempo de actividad. Consulte la documentación AEM para adjuntar comprobaciones de estado a Nagios como ejemplo para una herramienta de monitorización externa.

¿Qué son las entradas de registro relevantes?
  • Se ha iniciado o detenido la limpieza de revisión en línea
    • La limpieza de revisión en línea consta de tres fases: estimación, compactación y limpieza. La estimación puede obligar a que se omita la compactación y la limpieza si el repositorio no contiene suficiente basura. En la última versión de AEM, el mensaje "TarMK GC #{}: estimation started" marca el inicio de la estimación, "TarMK GC #{}: compaction started, strategy={}" marca el inicio de la compactación y "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" marca el inicio de la limpieza.
  • Espacio en disco obtenido por la limpieza de revisión
    • El espacio solo se recupera cuando termina la fase de limpieza. La finalización de la fase de limpieza se marca con el mensaje de registro "TarMK GC #{}: cleanup completed in {} ({} ms". El tamaño de la limpieza posterior es de {} ({} bytes) y el espacio recuperado es de {} ({} bytes). El peso/profundidad del mapa de compactación es {}/{} ({} bytes/{})."
  • Se ha producido un problema durante la limpieza de revisión
    • Existen muchas condiciones de error, todas ellas están marcadas por los mensajes de registro WARN o ERROR que empiezan con "TarMK GC".

Además, consulte la sección Resolución de problemas basada en mensajes de error a continuación.

¿Cómo comprobar cuánto espacio se ha reclamado después de que se haya completado la limpieza de revisión en línea? Hay un mensaje en el registro al final del ciclo de limpieza: "TarMK GC #3: cleanup completed" que incluye el tamaño del repositorio y la cantidad de basura reclamada.
¿Cómo comprobar la integridad del repositorio después de que se haya completado la limpieza de revisión en línea?

No se necesita una comprobación de integridad del repositorio después de la limpieza de revisión en línea.

Sin embargo, puede realizar las siguientes acciones para comprobar el estado del repositorio después de la limpieza:

  • Un repositorio traversal check
  • Utilice la herramienta Oak-run después de completar el proceso de limpieza para comprobar si hay incoherencias. Para obtener más información sobre cómo hacerlo, consulte la Documentación de Apache. No es necesario apagar AEM para ejecutar la herramienta.
¿Cómo se detecta si la limpieza de revisión en línea ha fallado y cuáles son los pasos a seguir para recuperarse? Las condiciones de error se marcan con los mensajes WARN o ERROR log que comienzan con "TarMK GC". Además, consulte la sección Resolución de problemas basada en mensajes de error a continuación.
¿Qué información se expone en la Revisión del estado de limpieza de revisión? ¿Cómo y cuándo contribuyen a los niveles de estado codificados por color?

La revisión de la comprobación de estado de limpieza forma parte del Tablero de operaciones.

El estado será GREEN si la última ejecución de la tarea de mantenimiento Limpieza de revisión en línea se ha completado correctamente.

Será AMARILLO si la tarea de mantenimiento de limpieza de revisión en línea se canceló una vez.

Será RED si la tarea de mantenimiento de limpieza de revisión en línea se canceló tres veces seguidas. En este caso, la interacción manual es necesaria; es probable que la limpieza de revisión en línea vuelva a fallar. Para obtener más información, lea la sección Resolución de problemas a continuación.

Tenga en cuenta también que el estado de la comprobación de estado se restablecerá después de reiniciar el sistema. Por lo tanto, una instancia que se haya reiniciado recientemente mostrará un estado verde en la Revisión de estado de limpieza de revisión. Se podrían aprovechar las herramientas de monitorización externa para mantener los datos más allá AEM tiempo de actividad. Consulte la documentación AEM para adjuntar comprobaciones de estado a Nagios como ejemplo para una herramienta de monitorización externa.

¿Cómo monitorizar la limpieza automática en una instancia de espera?

El estado, el progreso y las estadísticas se exponen a través de JMX usando el SegmentRevisionGarbageCollection MBean. Consulte también la siguiente documentación de Oak.

Puede obtener una referencia del MBean utilizando el ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Tenga en cuenta que las estadísticas solo están disponibles desde el último inicio del sistema. Se podrían aprovechar las herramientas de monitorización externa para mantener los datos más allá del tiempo AEM activo. Consulte también la documentación de AEM para adjuntar comprobaciones de estado a Nagios como ejemplo de una herramienta de monitorización externa.

Los archivos de registro también pueden utilizarse para comprobar el estado, el progreso y las estadísticas de la limpieza automática.

¿Qué debe monitorizarse durante la limpieza automática en una instancia de espera?

  • El espacio en disco debe monitorizarse cuando se ejecuta la limpieza automática.
  • Tiempo de finalización (mediante los registros) para garantizar que no se superen las 2 horas.
  • Tamaño del almacén de segmentos después de ejecutar la limpieza automática. El tamaño del almacén de segmentos en la instancia de espera debe ser aproximadamente el mismo que el de la instancia principal.

Solución de problemas de limpieza de revisión en línea

¿Qué es lo peor que puede suceder si no ejecuta la limpieza de revisión en línea? La instancia de AEM se quedará sin espacio en disco, lo que provocará interrupciones en la producción.
¿Es problemático el alto tráfico de usuarios para ejecutar la limpieza de revisión en línea en una instancia de publicación? El alto tráfico de usuarios afecta si la fase de compactación puede terminar o no correctamente.
Según la Comprobación de estado y las entradas de registro, la Limpieza de revisión en línea no se ha completado correctamente tres veces seguidas. ¿Qué se necesita para que la limpieza de revisión en línea se complete correctamente? Puede realizar varios pasos para encontrar y solucionar el problema:
  • Primero, compruebe las entradas de registro
  • Según la información de los registros, tome las medidas adecuadas:
    • Si los registros muestran cinco ciclos compactos faltantes y un tiempo de espera en el ciclo forceCompact, programe la ventana de mantenimiento en un momento silencioso cuando la cantidad de escrituras del repositorio sea baja. Puede comprobar las escrituras del repositorio en la herramienta de monitorización de métricas del repositorio ubicada en https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
    • Si la limpieza se detuvo al final de la ventana de mantenimiento, asegúrese de que la configuración de la ventana de mantenimiento en la interfaz de usuario Tareas de mantenimiento sea lo suficientemente grande
    • Si la memoria de pila disponible no es suficiente, asegúrese de que la instancia tiene suficiente memoria.
    • En caso de una reacción tardía, el almacén de segmentos podría crecer demasiado para que la Limpieza de revisiones en línea se complete incluso dentro de un período de mantenimiento más largo. Por ejemplo, si no se completó correctamente la limpieza de revisión en línea en la última semana, se recomienda planificar un mantenimiento sin conexión y ejecutar la limpieza de revisión sin conexión para que el almacén de segmentos vuelva a tener un tamaño manejable.
¿Qué se debe hacer una vez que la alerta de control de salud esté activada? Véase el punto anterior.
¿Qué sucede si la limpieza de revisión en línea se queda sin tiempo durante el período de mantenimiento programado? La limpieza de revisión en línea se cancelará y se eliminarán los restos. Se iniciará de nuevo la próxima vez que se programe la ventana de mantenimiento.
¿Qué está causando que SegmentNotFoundException instancias se registren en el error.log y cómo puedo recuperarme?

TarMK registra un SegmentNotFoundException cuando intenta acceder a una unidad de almacenamiento (un segmento) que no puede encontrar. Hay tres escenarios que podrían causar este problema:

  1. Una aplicación que elude los mecanismos de acceso recomendados (como Sling y la API de JCR) y utiliza una API/SPI de nivel inferior para acceder al repositorio y luego supera el tiempo de retención de un segmento. Es decir, mantiene una referencia a una entidad más allá del tiempo de retención permitido por la limpieza de revisión en línea (de forma predeterminada, 24 horas). Este caso es transitorio y no provoca daños en los datos. Para recuperarse, la herramienta oak-run debe utilizarse para confirmar la naturaleza transitoria de la excepción (la comprobación oak-run no debe notificar ningún error). Para ello, la instancia debe desconectarse y reiniciarse posteriormente.
  2. Un evento externo provocó la corrupción de los datos en el disco. Esto puede ser una falla en el disco, una falta de espacio en disco o una modificación accidental de los archivos de datos necesarios. En este caso, la instancia debe desconectarse y repararse con la comprobación oak-run. Para obtener más información sobre cómo realizar la comprobación de oak-run, lea la siguiente documentación de Apache.
  3. Todas las demás ocurrencias deben solucionarse a través del Adobe Customer Care.

Resolución de problemas basados en mensajes de error

El archivo error.log será detallado si hay incidentes durante el proceso de limpieza de revisión en línea. La siguiente matriz pretende explicar los mensajes más comunes y proporcionar posibles soluciones:

Fase Mensajes de registro Explicación Pasos siguientes
Estimación TarMK GC #2: estimación omitida porque la compactación está en pausa La fase de estimación se omite cuando la compactación está deshabilitada en el sistema por configuración. Habilite la limpieza de revisión en línea.
TarMK GC #2: estimación interrumpida: ${REASON}. Omitiendo la compactación. La fase de estimación finalizó prematuramente. Algunos ejemplos de eventos que podrían interrumpir la fase de estimación: no hay suficiente memoria o espacio en disco en el sistema host. Depende del motivo dado.
Compactación TarMK GC #2: compactación pausada Mientras la fase de compactación esté pausada por la configuración, no se ejecutará ni la fase de estimación ni la fase de compactación. Habilite la limpieza de revisiones en línea.
TarMK GC #2: compactación cancelada: ${REASON}. La fase de compactación finalizó prematuramente. Algunos ejemplos de eventos que podrían interrumpir la fase de compactación: no hay suficiente memoria o espacio en disco en el sistema host. Además, la compactación también puede cancelarse apagando el sistema o cancelándolo explícitamente a través de interfaces administrativas como la ventana de mantenimiento dentro del panel Operaciones. Depende del motivo dado.
TarMK GC #2: la compactación falló en 32,902 min (1974140 ms), después de 5 ciclos Este mensaje no significa que haya un error irrecuperable, pero solo que esa compactación se terminó después de una cierta cantidad de intentos. Lea también el siguiente párrafo. Lea la siguiente documentación de Oak y la última pregunta de la sección Ejecución de la limpieza de revisión en línea.
Limpiar TarMK GC #2: limpieza interrumpida La limpieza se ha cancelado cerrando el repositorio. No se espera ningún impacto en la coherencia. Además, es muy probable que el espacio en disco no se vuelva a reclamar en su totalidad. Se recuperará durante el próximo ciclo de limpieza de revisión. Investigue por qué se ha cerrado el repositorio y, en adelante, intente evitar que se cierre el repositorio durante las ventanas de mantenimiento.

Cómo ejecutar la limpieza de revisión sin conexión

PRECAUCIÓN

Es necesario utilizar diferentes versiones de la herramienta Oak-run dependiendo de la versión Oak que utilice con la instalación de AEM. Compruebe la lista de requisitos de la versión que aparece a continuación antes de utilizar la herramienta:

  • Para las versiones Oak 1.0.0 a 1.0.11 o 1.1.0 a 1.1.6, utilice la versión Oak-run 1.0.11

  • Para las versiones de Oak más recientes que la anterior, utilice la versión de Oak-run que coincida con el núcleo de Oak de su instalación de AEM.

Adobe proporciona una herramienta llamada Oak-run para realizar la limpieza de revisión. Se puede descargar desde la siguiente ubicación:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

La herramienta es un jar ejecutable que se puede ejecutar manualmente para compactar el repositorio. El proceso se denomina limpieza de revisión sin conexión porque el repositorio debe cerrarse para ejecutar correctamente la herramienta. Asegúrese de planificar la limpieza de acuerdo con su ventana de mantenimiento.

Para obtener sugerencias sobre cómo aumentar el rendimiento del proceso de limpieza, consulte Aumento del rendimiento de la limpieza de revisión sin conexión.

NOTA

También puede borrar los puntos de comprobación antiguos antes de que tenga lugar el mantenimiento (pasos 2 y 3 del procedimiento siguiente). Esto solo se recomienda para las instancias que tienen más de 100 puntos de comprobación.

  1. Asegúrese siempre de tener una copia de seguridad reciente de la instancia de AEM.

    Apague AEM.

  2. (Opcional) Utilice la herramienta para encontrar puntos de comprobación antiguos:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (Opcional) A continuación, elimine los puntos de comprobación no referenciados:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. Ejecute la compactación y espere a que se complete:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

Aumento del rendimiento de la limpieza de revisión sin conexión

La herramienta Oak-run introduce varias funciones que pretenden aumentar el rendimiento del proceso de limpieza de revisiones y minimizar la ventana de mantenimiento en la medida de lo posible.

La lista incluye varios parámetros de línea de comandos, como se describe a continuación:

  • -mmap. Puede establecerlo como verdadero o falso. Si se establece en true, se utiliza el acceso asignado a memoria. Si se establece en false, se utiliza el acceso a los archivos. Si no se especifica, el acceso asignado a memoria se utiliza en sistemas de 64 bits y el acceso a archivos se utiliza en sistemas de 32 bits. En Windows, el acceso a archivos regular siempre se aplica y esta opción se ignora. Este parámetro ha reemplazado el parámetro -Dtar.memoryMapped.

  • -Dupdate.limit. Define el umbral para el vaciado de una transacción temporal en disco. El valor predeterminado es 10000.

  • -Descomprimir-intervalo. Número de entradas del mapa de compactación que se van a mantener hasta que se comprime el mapa actual. El valor predeterminado es 1000000. Debería aumentar este valor a un número aún mayor para un rendimiento más rápido, si hay suficiente memoria acumulada disponible. Este parámetro se ha eliminado en la versión 1.6 de Oak y no tiene ningún efecto.

  • -Dcompaction-progress-log. Número de nodos compuestos que se registrarán. El valor predeterminado es 150000, lo que significa que los primeros 150000 nodos compactados se registrarán durante la operación. Utilícelo junto con el siguiente parámetro documentado a continuación.

  • -Dtar.PersistCompactionMap. Establezca este parámetro en true para usar espacio en disco en lugar de memoria en pilas para la persistencia del mapa de compactación. Requiere la herramienta Oak-run versiones 1.4 y superiores. Para obtener más información, consulte la pregunta 3 en la sección Preguntas más frecuentes sobre la limpieza de revisiones sin conexión. Este parámetro se ha eliminado en la versión 1.6 de Oak y no tiene ningún efecto.

  • —force. Forzar la compactación e ignorar una versión del almacén de segmentos que no coincida.

PRECAUCIÓN

El uso del parámetro --force actualizará el almacén de segmentos a la versión más reciente, lo que es incompatible con versiones anteriores de Oak. Además, tenga en cuenta que no es posible reducir la categoría. Como regla general, debe usar estos parámetros con precaución y solo si conoce cómo utilizarlos.

Ejemplo de los parámetros en uso:

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Métodos adicionales para activar la limpieza de revisión

Además de los métodos presentados anteriormente, también puede almacenar en déclencheur el mecanismo de limpieza de revisiones utilizando la consola JMX de la siguiente manera:

  1. Abra la consola JMX en http://localhost:4502/system/console/jmx
  2. Haga clic en RevisionGarbageCollection MBean.
  3. En la siguiente ventana, haga clic en startRevisionGC() y luego en Invocar para iniciar el trabajo de colección de residuos de revisión.

Preguntas más frecuentes sobre la limpieza de revisiones sin conexión

¿Cuáles son los factores que determinan la duración de la limpieza de revisión sin conexión?

El tamaño del repositorio y la cantidad de revisiones que deben limpiarse determinan la duración de la limpieza.

¿Cuál es la diferencia entre una revisión y una versión de página?
  • Revisión de Oak: Oak organiza todo el contenido en una jerarquía de árbol grande que consta de nodos y propiedades. Cada instantánea o revisión de este árbol de contenido es inmutable, y los cambios en el árbol se expresan como una secuencia de nuevas revisiones. Normalmente, cada modificación de contenido déclencheur una nueva revisión. Consulte también Seguir enlace.
  • Versión de página: al generar versiones se crea una "instantánea" de una página en un momento específico. Normalmente, se crea una nueva versión cuando se activa una página. Para obtener más información, consulte Trabajo con versiones de página.
¿Cómo acelerar la tarea de limpieza de revisión sin conexión si no se completa en un plazo de 8 horas? Si la tarea de revisión no se completa en un plazo de 8 horas y los volcados de subprocesos revelan que el punto interactivo principal es InMemoryCompactionMap.findEntry, utilice el siguiente parámetro con la herramienta Oak-run versiones 1.4 o superiores: -Dtar.PersistCompactionMap=true. Tenga en cuenta que el parámetro -Dtar.PersistCompactionMap se ha eliminado en la versión 1.6 de Oak.

En esta página