Limpieza de revisión revision-cleanup

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.

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).
• Más rápido Colección de residuos del almacén de datos.
• Masa de trabajo para futuras mejoras.

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.

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)

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.

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

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 la compactación
• Revisión GC not ejecutar: El delta de tamaño es N% o N/N (N/N bytes), por lo que omitirá la compactación por ahora

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, tal y como se explica más detalladamente en la sección 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.

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

• En entornos Windows, el acceso regular a archivos 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.

• 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.

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 por el mensaje "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", lo que significa que había demasiada carga simultánea.

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

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

Se puede realizar un seguimiento del progreso mediante la variable EstimatedRevisionGCCompletion del SegmentRevisionGarbageCollection MBean.

Puede obtener una referencia de MBean mediante la variable 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 los controles sanitarios a Nagios como ejemplo de herramienta de monitorización externa.

• 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".

Consulte también la Resolución de problemas basados en mensajes de error a continuación.

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 comprobación transversal
• 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.

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

El estado será VERDE 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 Limpieza de revisión en línea se canceló una vez.

Será RED si la tarea de mantenimiento Limpieza de revisión en línea se canceló tres veces seguidas. En este caso se requiere interacción manual o es probable que la limpieza de revisión en línea vuelva a fallar. Para obtener más información, lea la 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 los controles sanitarios a Nagios como ejemplo de herramienta de monitorización externa.

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

Puede obtener una referencia de MBean utilizando la variable 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 AEM para adjuntar los controles sanitarios a Nagios como ejemplo de 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.

• 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.

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 la variable 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.

A SegmentNotFoundException es registrado por TarMK 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 Oak-run, lea lo siguiente Documentación de Apache.
3. Todas las demás ocurrencias deben solucionarse a través del Servicio de atención al cliente de Adobe.

• 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 vínculo.
• Versión de la página: Al generar una versión se crea una "instantánea" de una página en un punto específico en el tiempo. Normalmente, se crea una nueva versión cuando se activa una página. Para obtener más información, consulte Uso de versiones de página.