Limpieza de revisión
- Se aplica a:
- Experience Manager 6.5
- Temas:
- Administración
Creado para:
- Administrador
Introducción
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?
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
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:
-
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
-
Pase el ratón sobre Ventana de mantenimiento diario y haga clic en el icono Configuración.
-
Introduzca los valores deseados (periodicidad, hora de inicio, hora de finalización) y haga clic en Guardar.
Alternativamente, si desea ejecutar la tarea de limpieza de revisión manualmente, puede:
-
Vaya a Herramientas - Operaciones - Panel de control - Mantenimiento o busque directamente
https://serveraddress:serverport/libs/granite/operations/content/maintenance.html -
Haga clic en Ventana de mantenimiento diario.
-
Pase el ratón sobre el icono Limpieza de revisión.
-
Haga clic en Ejecutar.
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 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:
- 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.
- 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
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.
Cómo configurar la compactación completa y de cola
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
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.
RevisionCleanupTaskHealthCheckindica 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
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
AEM Consideraciones de actualización de 6.5
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
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:
- Mejor escalabilidad (tamaño de segmento optimizado).
- Recopilación de residuos del almacén de datos más rápida.
- Trabajo en tierra para futuras mejoras.
Ejecución de Limpieza de revisión en línea
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.
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)
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.
- 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).
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
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.
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.
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.
- 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
- 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.
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.
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.
- 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.
- 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 "
- 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 "T
arMK 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/{}).".
- 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 "T
- 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.
TarMK GC #3: cleanup completed" que incluye el tamaño del repositorio y la cantidad de basura reclamada.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.
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.
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.
- 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
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.
- Si los registros muestran cinco ciclos compactos perdidos y un tiempo de espera en el ciclo
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:
- 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.
- 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.
- 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
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:
Cómo ejecutar la limpieza de revisión sin conexión
CAUTIONAdobe 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-
AEM Asegúrese siempre de tener una copia de seguridad reciente de la instancia de la.
AEM Cierra la puerta
-
(Opcional) Utilice la herramienta para buscar puntos de comprobación antiguos:
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore -
(Opcional) A continuación, elimine los puntos de comprobación sin referencia:
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced -
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 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--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
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:
- Abra la consola JMX yendo a http://localhost:4502/system/console/jmx
- Haga clic en el MBean RevisionGarbageCollection.
- 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
- 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.
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.