Limpieza de revisión revision-cleanup

Introducción introduction

Cada actualización del repositorio crea una revisión de contenido. Como resultado, con cada actualización, el tamaño del repositorio aumenta. Las revisiones antiguas deben limpiarse para liberar recursos de disco. Esto es importante para evitar un crecimiento incontrolado del repositorio. Esta funcionalidad de mantenimiento se denomina Limpieza de revisión. Ha estado disponible como una rutina sin conexión desde Adobe Experience Manager AEM () 6.0.

AEM Con la versión 6.3 y superior de la, se ha introducido una versión en línea de esta funcionalidad denominada Limpieza de revisión en línea. AEM AEM En comparación con la Limpieza de revisión sin conexión, en la que la instancia de debe cerrarse, la Limpieza de revisión en línea puede ejecutarse mientras la instancia está en línea. 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: Vea el Vídeo para ver una introducción y cómo usar la Limpieza de revisión en línea.

El proceso de limpieza de revisión consta de tres fases: estimación, compactación y limpieza. La estimación determina si se debe ejecutar la siguiente fase (compactación) o no en función de la cantidad de basura que se pueda recolectar. Durante la fase de compactación, los segmentos y los archivos tar se vuelven a escribir sin tener en cuenta el contenido no utilizado. A continuación, la fase de limpieza elimina los segmentos antiguos, incluida la basura que puedan contener. AEM El modo sin conexión generalmente puede reclamar más espacio porque el modo en línea debe tener en cuenta el conjunto de trabajo de que se dispone para evitar que se recopilen segmentos adicionales.

Para obtener más información sobre Revision Cleanup, consulte los siguientes vínculos:

También puede leer la documentación oficial de Oak.

¿Cuándo utilizar la Limpieza de revisión en línea y cuándo la Limpieza de revisión sin conexión? when-to-use-online-revision-cleanup-as-opposed-to-offline-revision-cleanup

Limpieza de revisión en línea es la forma recomendada de realizar la limpieza de revisión. Limpieza de revisión sin conexión solo debe usarse 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 how-to-run-online-revision-cleanup

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

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

    chlimage_1-90

  2. Pase el ratón sobre Ventana de mantenimiento diario y haga clic en el icono Configuración.

    chlimage_1-91

  3. Introduzca los valores deseados (periodicidad, hora de inicio, 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 - Panel de control - Mantenimiento o busque directamente https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. Haga clic en Ventana de mantenimiento diario.

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

  4. Haga clic en Ejecutar.

    chlimage_1-93

Ejecución De La Limpieza De Revisión En Línea Después De La Limpieza De Revisión Sin Conexión running-online-revision-cleanup-after-offline-revision-cleanup

El proceso de limpieza de revisión reclama las revisiones antiguas 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 revisión sin conexión mantiene una generación, mientras que la limpieza de revisión 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, ocurre lo siguiente:

  1. Después de la primera ejecución de limpieza de revisión en línea, el tamaño del repositorio se duplica. Esto sucede porque ahora hay dos generaciones que se mantienen en el disco.
  2. Durante las ejecuciones posteriores, el repositorio crecerá temporalmente mientras se crea la nueva generación y luego se estabilizará de nuevo al tamaño que tenía después de la primera ejecución, a medida que el proceso de limpieza de revisión en línea reclama a 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 Completa Y De Cola full-and-tail-compaction-modes

AEM 6.5 presenta dos nuevos modos para la fase de compactación del proceso de Limpieza de revisiones en línea:

  • El modo compactación completa reescribe todos los segmentos y archivos tar de todo el repositorio. La fase de limpieza posterior puede, por lo tanto, eliminar la cantidad máxima de residuos en el repositorio. Debido a que la compactación completa afecta a todo el repositorio, requiere una cantidad considerable de recursos del sistema y tiempo para completarse. AEM La compactación total corresponde a la fase de compactación de la versión 6.3 de la.
  • El modo tail compaction solo reescribe 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. Por lo tanto, la fase de limpieza posterior solo puede eliminar la basura contenida en la parte reciente del repositorio. Debido a que la compactación de cola solo afecta a una parte del repositorio, requiere considerablemente menos recursos del sistema y tiempo para completarla 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 total es más eficaz, pero tiene un mayor impacto en el funcionamiento normal del sistema.

AEM La versión 6.5 también introduce un mecanismo de deduplicación de contenido más eficaz durante la compactación, lo que reduce aún más el espacio en disco del repositorio.

AEM AEM En los dos gráficos que figuran a continuación, se presentan los resultados de las pruebas de laboratorio internas que ilustran la reducción de los tiempos de ejecución promedio y la huella media en disco en 6,5 comparado con la de los discos en 6,3, en comparación con la de los discos en 6,3, en comparación con la de los discos en 6,5, respectivamente.

onrc-duration-6_4vs63 segmentstore-6_4vs63

Cómo configurar la compactación completa y de cola how-to-configure-full-and-tail-compaction

La configuración predeterminada ejecuta la compactación de cola entre semana y la compactación completa los domingos. La configuración predeterminada se puede cambiar usando el nuevo valor de configuración full.gc.days de RevisionCleanupTask tarea de mantenimiento.

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

Además, tenga en cuenta que:

  • La compactación de cola es menos efectiva y tiene menos impacto en las operaciones normales del sistema. Por lo tanto, está previsto que se ejecute durante los días laborables.
  • La compactación completa es más efectiva, 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.
  • Tanto la compactación de cola como la compactación completa deben programarse para ejecutarse durante las horas de menor actividad.

Resolución de problemas troubleshooting

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 E/S, tamaño de cola de confirmación. Esto ayuda a determinar si el sistema está enlazado a E/S y si es necesario convertir.
  • RevisionCleanupTaskHealthCheck indica el estado general de la Limpieza de revisión en línea. AEM Funciona de la misma manera que en la versión 6.3 de la y no distingue entre compactación total y de cola.
  • Los mensajes de registro llevan 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 indican el modo de compactación. Además, en algunos casos extremos, el sistema vuelve a la compactación completa cuando estaba programado para ejecutar una compactación de cola y los mensajes de registro indican este cambio. Las siguientes muestras de registro 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 known-limitations

A veces, la alternancia entre los modos de cola y compactación completa retrasa el proceso de limpieza. Más concretamente, el repositorio crecerá después de una compactación completa (se duplica en tamaño). El espacio adicional se recupera en la siguiente compactación de cola, cuando el repositorio cae por debajo del tamaño de compactación precompleta. También deben evitarse las ejecuciones de tareas de mantenimiento paralelas.

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

Preguntas más frecuentes sobre Limpieza de revisiones en línea online-revision-cleanup-frequently-asked-questions

AEM Consideraciones de actualización de 6.5 aem-upgrade-considerations

Preguntas
Respuestas
AEM ¿Qué debo tener en cuenta al actualizar a la versión 6.5 de?

AEM El formato de persistencia de TarMK cambia con la versión 6.5 de la. Estos cambios no requieren un paso de migración proactiva. Los repositorios existentes pasan por una migración móvil, que es transparente para el usuario. AEM El proceso de migración se inicia la primera vez que 6.5 (o las herramientas relacionadas) acceden al repositorio.

AEM AEM Una vez iniciada la migración al formato de persistencia de la versión 6.5 de la, el repositorio no se puede revertir al formato de persistencia 6.3 de la versión anterior de la misma.

Migración al Segmento de destino de Oak migrating-to-oak-segment-tar

Preguntas
Respuestas
¿Por qué necesito migrar el repositorio?

AEM En la versión 6.3 se necesitaban cambios en el formato de almacenamiento, especialmente para mejorar el rendimiento y la eficacia de Online Revision Cleanup. Estos cambios no son compatibles con versiones anteriores y los repositorios creados con el antiguo segmento de Oak AEM (la versión 6.2 y la anterior de la versión de) deben migrarse.

Ventajas adicionales de cambiar el formato de almacenamiento:

¿Sigue siendo compatible el formato Tar anterior?
Solo se admite el nuevo Segmento de tar de Oak AEM con la versión 6.3 o superior de la aplicación de la versión de la aplicación de la manera de.
¿Es siempre obligatoria la migración de contenido?
Sí. A menos que comience con una instancia nueva, siempre tendrá que migrar el contenido.
¿Puedo actualizar a la versión 6.3 o superior y realizar la migración más adelante (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 ejecuto accidentalmente con el formato de repositorio incorrecto?
Si intenta ejecutar el módulo oak-segment en un repositorio oak-segment-tar (o a la inversa), el inicio falla con una IllegalStateException con el mensaje "Formato de segmento no válido". No se dañan los datos.
¿Será necesario reindexar 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 necesario durante y después de la migración?
La migración equivale a volver a crear el almacén de segmentos con el nuevo formato. Esto puede utilizarse para calcular el espacio en disco adicional necesario durante la migración. Después de la migración, se puede eliminar el almacén de segmentos antiguo para recuperar espacio.
¿Cómo calcular mejor la duración de la migración?
El rendimiento de la migración se puede mejorar en gran medida si offline revision cleanup se ejecuta antes de la migración. Se aconseja a todos los clientes que lo ejecuten como un 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 Limpieza de revisión en línea running-online-revision-cleanup

Preguntas
Respuestas
¿Con qué frecuencia se debe ejecutar 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 revisiones 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 excederse para la Limpieza de revisiones 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 Limpieza de revisión en línea?
No es necesario determinar la frecuencia, ya que Limpieza de revisiones en línea está configurada como tarea de mantenimiento y se ejecuta automáticamente todos los días.
¿Por qué Online Revision Cleanup no recupera ningún espacio cuando se ejecuta por primera vez?
Limpieza de revisiones en línea recupera las revisiones antiguas realizadas por las generaciones. Se genera una nueva generación cada vez que se ejecuta la limpieza de revisión. Solo se recupera el contenido que tenga al menos dos generaciones, lo que significa que en una primera ejecución no hay nada que recuperar.
¿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?

Offline Revision Cleanup está reclamando todo menos la última generación en comparación con las dos últimas generaciones para Online Revision Cleanup. Si hay un repositorio nuevo, la Limpieza de revisión en línea no reclamará ningún espacio cuando se ejecute por primera vez después de la Limpieza de revisión sin conexión porque no hay ninguna generación lo suficientemente antigua como para reclamarse.

Lea también 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.

¿Author y Publish suelen tener diferentes ventanas de Limpieza de revisiones 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 tiempos de producción principales para permitir la mejor eficacia de limpieza. AEM Para varias instancias de Publish (granja de TarMK) de, las ventanas de mantenimiento para Limpieza de revisiones en línea deben escalonarse.
¿Hay algún requisito previo antes de ejecutar la limpieza de revisión en línea?
AEM La Limpieza de revisiones en línea solo está disponible con las versiones 6.3 y posteriores de la versión de. AEM Además, si usa una versión anterior de la, debe migrar al nuevo Segmento de destino de 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 o 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í, Limpieza de revisiones en línea puede hacer frente a escrituras simultáneas. Sin embargo, Limpieza de revisión en línea funciona de forma más rápida y eficaz sin transacciones de escritura simultáneas. El Adobe recomienda programar la tarea de mantenimiento Limpieza de revisiones en línea para un tiempo relativamente silencioso sin mucho tráfico.
¿Cuáles son los requisitos mínimos para el espacio en disco y la memoria de la pila al ejecutar Online Revision Cleanup?

El espacio en disco se supervisa continuamente durante la Limpieza de revisiones en línea. Si el espacio disponible en disco cae por debajo de un valor crítico, el proceso se cancela. El valor crítico es el 25 % del espacio en disco actual del repositorio y no se puede configurar.

El Adobe recomienda que el tamaño del disco sea al menos dos o tres veces mayor que el tamaño de repositorio inicialmente estimado.

El espacio libre en la pila se monitoriza continuamente durante el proceso de limpieza. Si el espacio libre en la pila 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 AEM para un tamaño mínimo de la pila de compactación no está separado de las recomendaciones de tamaño de memoria de la. AEM Generalmente: Si una instancia de tiene el tamaño suficiente para hacer frente a los casos de uso y a la carga útil esperada, el proceso de limpieza obtiene suficiente memoria.

¿Cuál es el impacto esperado en el rendimiento al ejecutar Online Revision Cleanup?
La limpieza de revisión en línea es un proceso en segundo plano que lee y escribe en el repositorio de forma simultánea en operaciones normales del sistema. En particular, es posible que necesite adquirir acceso exclusivo al repositorio durante un corto periodo de tiempo, lo que evita 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 debe tardar más de dos horas en ejecutarse según el Adobe de pruebas de rendimiento más reciente realizado internamente.
¿Qué se debe hacer si la limpieza de revisión en línea tarda más?
  • Asegúrese de que se ejecute a diario.
  • Asegúrese de que se ejecuta durante las actividades mínimas del repositorio configurando las ventanas de mantenimiento en el tablero de operaciones en consecuencia.
  • Escalar los recursos del sistema (CPU, memoria, E/S).
¿Qué sucede si 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 la Limpieza de revisión en línea dentro de la misma ventana de mantenimiento. Las tareas de mantenimiento se ejecutan secuencialmente sin un orden configurable.
¿Por qué se omite la recolección de basura de revisiones?

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 vez que se compactó. Si el tamaño supera el delta configurado, se ejecuta la limpieza. El delta de tamaño se establece en 1 GB. Esto significa que si el tamaño del repositorio no ha aumentado 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:

  • Se ejecuta la revisión GC: El delta de tamaño es N% o N/N (N/N bytes), por lo que se ejecuta la compactación
  • El GC de revisión no se ejecuta : El tamaño delta es N% o N/N (N/N bytes), por lo que se omitirá la compactación por ahora
¿Es posible abortar de forma segura la compactación automática si el impacto en el rendimiento es demasiado alto?
Sí. AEM Desde la versión 6.3, se puede detener de forma segura a través de la Ventana Tarea de mantenimiento dentro del Tablero de operaciones o a través de JMX.
AEM Si la instancia de se apaga durante una tarea de limpieza programada, ¿el proceso se interrumpe de forma segura o se bloquea el apagado hasta que la compactación haya finalizado?
Revision Cleanup se interrumpe y el repositorio se apaga correctamente.
¿Qué sucede cuando el sistema se bloquea durante la Limpieza de revisión en línea?
En estos casos no existe riesgo de que los datos se dañen. Las sobras de basura se limpian 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 con el tiempo.
¿Qué revisiones se recopilan?
De forma predeterminada, Limpieza de revisión en línea solo recopila revisiones que tengan al menos 24 horas de antigüedad.
¿Qué sucede si hay 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 entra en modo forceCompact, como se explica con más detalle en la documentación de Oak. Durante la compactación forzada, se adquiere un bloqueo de escritura exclusivo para confirmar finalmente los cambios sin que ninguna escritura simultánea interfiera. Para limitar el impacto en los tiempos de respuesta, se puede definir un valor de tiempo de espera. Este valor se define en un minuto de forma predeterminada, lo que significa que si force compact no se completa en un minuto, el proceso de compactación se interrumpe en favor de confirmaciones simultáneas.

La duración de la fuerza de compactación 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 Limpieza de revisión en línea en una instancia de espera?

En una configuración de espera pasiva, solo la instancia principal debe configurarse para ejecutar Online Revision Cleanup. En la instancia de espera, 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.

¿Puede Offline Revision Cleanup liberar más espacio en disco que Online Revision Cleanup?

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 hace referencia la pila de aplicaciones. De este modo, el primero puede eliminar la basura de forma más agresiva que el segundo si el efecto se amortiza en el transcurso de unos pocos ciclos de recogida de basura.

Lea también 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.

¿Tiene en cuenta las operaciones de archivos asignados en memoria?
  • En entornos de Windows, siempre se exige el acceso regular a los archivos para que no se utilice el acceso asignado a la memoria. Como consejo general, toda la RAM disponible debe asignarse al montón y el tamaño de segmentCache debe aumentarse. Para aumentar segmentCache, agregue la opción segmentCache.size a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (por ejemplo, segmentCache.size=20480). Recuerde dejar fuera un poco de RAM para el sistema operativo y otros procesos.
  • En entornos que no son Windows, aumente el tamaño de la memoria física para mejorar la asignación de memoria del repositorio.

Supervisar limpieza de revisión en línea monitoring-online-revision-cleanup

¿Qué se debe supervisar durante la limpieza de revisión en línea?
  • El espacio en disco debe supervisarse cuando Limpieza de revisión en línea está habilitada. La limpieza no se ejecuta o finaliza de forma preventiva cuando no hay suficiente espacio en disco.
  • Consulte los registros para ver la hora de finalización de 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 se comprueba 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 por el mensaje "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", lo que significa que hubo demasiada carga simultánea.

En consecuencia, hay un mensaje "TarMK GC #{}: cleanup completed in {} ({} ms" para la finalización correcta del 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 mediante JMX (SegmentRevisionGarbageCollection MBean). Para obtener más información sobre el MBean SegmentRevisionGarbageCollection, lea el párrafo siguiente.

El progreso se puede rastrear a través del atributo EstimatedRevisionGCCompletion del SegmentRevisionGarbageCollection MBean.

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

Las estadísticas solo están disponibles desde el último inicio del sistema. AEM Se podría usar la herramienta de supervisión externa para mantener los datos más allá del tiempo de actividad de la.

¿Qué son las entradas de registro relevantes?
  • La limpieza de revisión en línea se ha iniciado o detenido
    • Limpieza de revisión en línea se compone de tres fases: estimación, compactación y limpieza. La estimación puede forzar que se omitan la compactación y la limpieza si el repositorio no contiene suficiente basura. AEM En la última versión de la versión de la aplicación, 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 finaliza 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 limpieza de Post es de {} ({} bytes) y el espacio reclamado es de {} ({} bytes). La profundidad/peso del mapa de compactación es de {}/{} ({} bytes/{}).".
  • Se ha producido un problema durante la limpieza de revisión
    • Hay muchas condiciones de error, todas ellas están marcadas por mensajes de registro WARN o ERROR que comienzan con "TarMK GC".

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

¿Cómo se puede 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 es necesaria 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:

  • Una comprobación de recorrido del repositorio
  • Utilice la herramienta oak-run después de que se haya completado el proceso de limpieza para comprobar las incoherencias. Para obtener más información sobre cómo hacerlo, consulte la Documentación de Apache.AEMNo es necesario cerrar la aplicación para ejecutar la herramienta.
¿Cómo detectar si la Limpieza de revisión en línea ha fallado y cuáles son los pasos para recuperarse?
Las condiciones de error se marcan con mensajes de registro WARN o ERROR que comienzan con "TarMK GC". Además, consulte la sección Solución de problemas basada en mensajes de error a continuación.
¿Qué información se expone en la comprobación de estado de Revision Cleanup? ¿Cómo y cuándo contribuyen a los niveles de estado codificados por colores?

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

El estado es VERDE si la última ejecución de la tarea de mantenimiento Limpieza de revisiones en línea se completó correctamente.

Es AMARILLO si la tarea de mantenimiento Limpieza de revisión en línea se canceló una vez.

Es RED si la tarea de mantenimiento Limpieza de revisiones en línea se canceló tres veces seguidas. En este caso se requiere interacción manual o es probable que Limpieza de revisión en línea vuelva a fallar. Para obtener más información, lea la sección Solución de problemas a continuación.

Además, el estado de la comprobación de estado se restablece después de reiniciar el sistema. Por lo tanto, una instancia recién reiniciada muestra un estado verde en la comprobación de estado de limpieza de revisión. AEM Se podría usar la herramienta de supervisión externa para mantener los datos más allá del tiempo de actividad de la.

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

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

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

Las estadísticas solo están disponibles desde el último inicio del sistema. AEM Se podría usar la herramienta de supervisión externa para mantener los datos más allá del tiempo de actividad de la.

Los archivos de registro también se pueden utilizar para comprobar el estado, el progreso y las estadísticas de Limpieza automática.

¿Qué se debe monitorizar durante la limpieza automática en una instancia de espera?
  • El espacio en disco debe supervisarse cuando se ejecute el Liberador de espacio automático.
  • Tiempo de finalización (a través de 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 revisión en línea troubleshooting-online-revision-cleanup

¿Qué es lo peor que puede pasar si no ejecuta Limpieza de revisión en línea?
AEM La instancia se queda sin espacio en disco, lo que provoca 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 finalizar correctamente o no.
Según la comprobación de estado y las entradas de registro, Limpieza de revisiones en línea no se ha completado correctamente tres veces seguidas. ¿Qué se necesita para completar correctamente la limpieza de revisión en línea?

Puede realizar varios pasos para encontrar y solucionar el problema:

  • Primero, compruebe las entradas de registro

  • Según la información de los registros, realice las acciones adecuadas:

    • Si los registros muestran cinco ciclos compactos perdidos y un tiempo de espera en el ciclo forceCompact, programe la ventana de mantenimiento a un tiempo de inactividad cuando la cantidad de escrituras en el repositorio sea baja. Puede comprobar las escrituras del repositorio en la herramienta de monitorización de métricas del repositorio 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 es lo suficientemente grande
    • Si la memoria de pila disponible no es suficiente, asegúrese de que la instancia tenga suficiente memoria.
    • Si se produce una reacción tardía, el almacén de segmentos puede crecer demasiado para que Limpieza de revisión 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 devolver el almacén de segmentos a un tamaño manejable.
¿Qué debe hacerse cuando la alerta Comprobación de estado está activada?
Véase el punto anterior.
¿Qué sucede si Limpieza de revisión en línea se queda sin tiempo durante la ventana de mantenimiento programado?
La Limpieza de revisión en línea se cancela y se quitan las sobras. Se inicia de nuevo la próxima vez que se programa la ventana de mantenimiento.
¿Qué está causando que se registren SegmentNotFoundException instancias en error.log y cómo puedo recuperarme?

El TarMK registra un SegmentNotFoundException cuando intenta obtener acceso a una unidad de almacenamiento (un segmento) que no encuentra. 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 JCR) y utiliza una API/SPI de nivel inferior para acceder al repositorio y, a continuación, supera el tiempo de retención de un segmento. Es decir, mantiene una referencia a una entidad más larga que el tiempo de retención permitido por 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 después.
  2. Un evento externo dañó los datos del disco. Esto puede ser un error de disco, espacio insuficiente en disco o una modificación accidental de los archivos de datos necesarios. En este caso, la instancia debe desconectarse y repararse mediante la comprobación de 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. Aborde todos los demás sucesos a través del Servicio de atención al cliente de Adobe.

Solución De Problemas Según Mensajes De Error troubleshooting-based-on-error-messages

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

Fase
Mensajes de registro
Explicación
Siguientes pasos
Estimación
TarMK GC #2: estimación omitida porque la compactación está en pausa.
La fase de estimación se omite cuando la configuración desactiva la compactación en el sistema.
Activar Limpieza de revisión en línea.
N/D
#2 de GC TarMK: estimación interrumpida: ${REASON}. Omitiendo la compactación.
La fase de estimación terminó 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 de la razón dada.
Compactación
TarMK GC #2: compactación en pausa.
Mientras la fase de compactación esté en pausa por la configuración, no se ejecuta ni la fase de estimación ni la fase de compactación.
Activar limpieza de revisión en línea.
N/D
#2 de TarMK GC: compactación cancelada: ${REASON}.
La fase de compactación terminó 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 se puede cancelar apagando el sistema o cancelándolo explícitamente a través de interfaces administrativas como la ventana de mantenimiento dentro del tablero de operaciones.
Depende de la razón dada.
N/D
TarMK GC #2: error de compactación en 32.902 min (1974140 ms), después de 5 ciclos.
Este mensaje no significa que haya un error irrecuperable, sino que solo esa compactación se ha terminado después de algunos intentos. Lea también el párrafo siguiente.
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
#2 de TarMK GC: limpieza interrumpida.
La limpieza se ha cancelado cerrando el repositorio. No se espera que esto afecte a la coherencia. Además, es muy probable que el espacio en disco no se recupere en su totalidad. Se reclamará durante el siguiente ciclo de limpieza de revisión.
Investigue por qué se ha cerrado el repositorio y continúe intentando evitar cerrarlo durante las ventanas de mantenimiento.

Cómo ejecutar la limpieza de revisión sin conexión how-to-run-offline-revision-cleanup

CAUTION
Utilice una versión de la herramienta ejecutada por Oak con un número de versión (principal y secundaria) que coincida con la versión principal de Oak AEM de la instalación de la. AEM Por ejemplo, si la instancia de la tiene Oak Core versión 1.22.x, debe utilizar la versión más reciente de la herramienta 1.22.x ejecutada por Oak.

Adobe proporciona una herramienta llamada Oak-run para realizar la limpieza de revisión. Se puede descargar en 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 la ventana de mantenimiento.

Para obtener sugerencias sobre cómo aumentar el rendimiento del proceso de limpieza, vea Aumentar el rendimiento de la limpieza de revisiones sin conexión.

NOTE
También puede borrar los puntos de comprobación antiguos antes de que se realice el mantenimiento (pasos 2 y 3 del procedimiento que se describe a continuación). Esto solo se recomienda para instancias que tienen más de 100 puntos de comprobación.
  1. AEM Asegúrese siempre de tener una copia de seguridad reciente de la instancia de la.

    AEM Cierra la puerta

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

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

    code language-xml
    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:

    code language-xml
    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 increasing-the-performance-of-offline-revision-cleanup

La herramienta oak-run introduce varias funciones que pretenden aumentar el rendimiento del proceso de limpieza de revisión 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 establecer esto como verdadero o falso. Si se establece en true, se utiliza el acceso asignado a la memoria. Si se establece en false, se utiliza el acceso a 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 regular a archivos 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.

  • -Dcompress-interval. Número de entradas de mapa de compactación que se deben mantener hasta comprimir el mapa actual. El valor predeterminado es 1000000. Debe aumentar este valor a un número aún mayor para obtener un rendimiento más rápido, si hay suficiente memoria disponible. Este parámetro se ha quitado en la versión 1.6 de Oak y no tiene ningún efecto.

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

  • -Dtar.PersistCompactionMap. Establezca este parámetro en true para utilizar espacio en disco en lugar de memoria de montón para la persistencia de 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 quitado en la versión 1.6 de Oak y no tiene ningún efecto.

  • : forzar. Forzar la compactación e ignorar una versión de almacén de segmentos no coincidente.

CAUTION
Al usar el parámetro --force, se actualiza el almacén de segmentos a la versión más reciente, lo cual es incompatible con versiones de Oak anteriores. Además, considere que no es posible bajar de categoría. Por lo general, estos parámetros deben utilizarse con precaución y solo si tiene conocimientos sobre cómo utilizarlos.

Un 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 additional-methods-of-triggering-revision-cleanup

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

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

Preguntas más frecuentes sobre la limpieza de revisiones sin conexión offline-revision-cleanup-frequently-asked-questions

¿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 el número de revisiones que se deben limpiar 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 vínculo.
  • Versión de la página: El control de versiones crea una "captura de pantalla" 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, vea Trabajar 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, use el siguiente parámetro con la herramienta oak-run versiones 1.4 o superior: -Dtar.PersistCompactionMap=true. El parámetro -Dtar.PersistCompactionMap se ha quitado en la versión 1.6 de Oak.
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2