Recolección de papelera del almacén de datos data-store-garbage-collection
Cuando se elimina un recurso de WCM convencional, la referencia al registro de almacén de datos subyacente se puede eliminar de la jerarquía de nodos, pero el registro de almacén de datos en sí permanece. A continuación, este registro de almacén de datos sin referencia se convierte en "basura" que no es necesario conservar. En los casos en que existen varios activos basura, es beneficioso deshacerse de ellos para conservar el espacio y optimizar el performance del backup y mantenimiento del filesystem.
En su mayor parte, una aplicación WCM tiende a recopilar información, pero no a eliminarla casi con la misma frecuencia. Aunque se añaden nuevas imágenes, incluso las versiones antiguas que se reemplazan, el sistema de control de versiones conserva la anterior y admite la reversión si es necesario. Por lo tanto, la mayor parte del contenido que pensamos como añadido al sistema se almacena de forma permanente. Entonces, ¿cuál es la fuente típica de "basura" en el repositorio que tal vez queramos limpiar?
AEM utiliza el repositorio como almacenamiento para una serie de actividades internas y de mantenimiento de la página:
- Paquetes creados y descargados
- Archivos temporales creados para la replicación de publicación
- Cargas del flujo de trabajo
- Recursos creados temporalmente durante la renderización DAM
Cuando alguno de estos objetos temporales es lo suficientemente grande como para requerir almacenamiento en el almacén de datos, y cuando el objeto termina de usarse, el propio registro del almacén de datos permanece como "basura". En una aplicación de autor/publicación WCM típica, la fuente más grande de basura de este tipo suele ser el proceso de activación de la publicación. Cuando los datos se replican en Publicar, se recopilan primero en colecciones con un formato de datos eficiente denominado "Durbo" y se almacenan en el repositorio en /var/replication/data. Los paquetes de datos suelen superar el umbral de tamaño crítico para el almacén de datos y, por lo tanto, terminan almacenados como registros del almacén de datos. Cuando se completa la replicación, el nodo de /var/replication/data se elimina, pero el registro del almacén de datos permanece como "basura".
Otra fuente de basura recuperable son los paquetes. Los datos del paquete, como todo lo demás, se almacenan en el repositorio y, por lo tanto, para paquetes de más de 4 KB, en el almacén de datos. En el curso de un proyecto de desarrollo o con el paso del tiempo mientras se mantiene un sistema, los paquetes se pueden crear y reconstruir muchas veces, cada compilación resulta en un nuevo registro de almacén de datos, lo que orfiere el registro de la compilación anterior.
¿Cómo funciona la colección de residuos del almacén de datos? how-does-data-store-garbage-collection-work
Si el repositorio se ha configurado con un almacén de datos externo, la colección de residuos del almacén de datos se ejecutará automáticamente como parte de la ventana de mantenimiento semanal. El administrador del sistema también puede ejecutar manualmente la colección de residuos del almacén de datos según sea necesario. En general, se recomienda que la colección de basura del almacén de datos se realice periódicamente, pero que se tengan en cuenta los siguientes factores al planificar la recogida de residuos en el almacén de datos:
- Las colecciones de residuos del almacén de datos tardan un tiempo y pueden afectar al rendimiento, por lo que deben planificarse en consecuencia.
- La eliminación de los registros de residuos del almacén de datos no afecta al rendimiento normal, por lo que no se trata de una optimización del rendimiento.
- Si la utilización del almacenamiento de información y factores relacionados como los tiempos de backup no son un problema, entonces la recolección de basura del almacén de datos podría diferirse de forma segura.
El recolector de residuos del almacén de datos realiza primero una nota de la marca de tiempo actual cuando comienza el proceso. A continuación, la colección se lleva a cabo mediante un algoritmo de patrón de marca/barrido de varios pasos.
En la primera fase, el recolector de basura del almacén de datos realiza una travesía completa de todo el contenido del repositorio. Para cada objeto de contenido que tiene una referencia a un registro de almacén de datos, localizó el archivo en el sistema de archivos, realizando una actualización de metadatos — modificando el atributo "última modificación" o MTIME. En este punto, los archivos a los que se accede mediante esta fase pasan a ser más recientes que la marca de tiempo de la línea de base inicial.
En la segunda fase, el recolector de residuos del almacén de datos atraviesa la estructura de directorios físicos del almacén de datos de la misma manera que una "búsqueda". Examinó el atributo "last modified" o MTIME del archivo y realiza la siguiente determinación:
- Si el MTIME es más reciente que la marca de tiempo de la línea de base inicial, entonces el archivo se encontró en la primera fase o es un archivo completamente nuevo que se agregó al repositorio mientras el proceso de recopilación estaba en curso. En cualquiera de estos casos se considerará que el registro está activo y no se eliminará el expediente.
- Si el MTIME es anterior a la marca de tiempo de la línea de base inicial, entonces el archivo no es un archivo al que se hace referencia activamente y se considera un residuo extraíble.
Este método funciona bien para un nodo único con un almacén de datos privado. Sin embargo, el almacén de datos puede compartirse. Si es así, las referencias activas potenciales a los registros del almacén de datos de otros repositorios no se comprueban y los archivos de referencia activos pueden eliminarse por error. Es imperativo que el administrador del sistema comprenda la naturaleza compartida del almacén de datos antes de planificar cualquier colección de residuos y utilice únicamente el proceso de recopilación de residuos del almacén de datos integrado cuando se sepa que el almacén de datos no se comparte.
Ejecución de la colección de residuos del almacén de datos running-data-store-garbage-collection
Existen tres maneras de ejecutar la colección de residuos del almacén de datos, según la configuración del almacén de datos en la que AEM se esté ejecutando:
-
Via Limpieza de revisión - un mecanismo de colección de residuos que normalmente se utiliza para la limpieza del almacén de nodos.
-
Via Colección de residuos del almacén de datos : un mecanismo de colección de residuos específico para almacenes de datos externos, disponible en el Tablero de operaciones.
-
A través de la función Consola JMX.
Si TarMK se está utilizando como almacén de nodos y como almacén de datos, la limpieza de revisión se puede utilizar para la colección de residuos tanto del almacén de nodos como del almacén de datos. Sin embargo, si se configura un almacén de datos externo, como el almacén de datos del sistema de archivos, la colección de residuos del almacén de datos debe activarse de forma explícita y separada de la limpieza de revisión. La colección de residuos del almacén de datos se puede activar mediante el panel Operaciones o la consola JMX.
La tabla siguiente muestra el tipo de colección de residuos del almacén de datos que debe utilizarse para todas las implementaciones de almacén de datos admitidas en el AEM 6:
Ejecución de la colección de residuos del almacén de datos mediante el panel de operaciones running-data-store-garbage-collection-via-the-operations-dashboard
La ventana de mantenimiento semanal incorporada, disponible a través de la Tablero de operaciones, contiene una tarea integrada para almacenar en déclencheur la colección de residuos del almacén de datos a la 1 a. m. los domingos.
Si necesita ejecutar la colección de residuos del almacén de datos fuera de este tiempo, se puede activar manualmente mediante el panel de operaciones.
Antes de ejecutar la colección de residuos del almacén de datos, debe comprobar que no se estén ejecutando copias de seguridad en ese momento.
-
Abra el Tablero de operaciones de Navegación -> Herramientas -> Operaciones -> Mantenimiento.
-
Toque o haga clic en Período de mantenimiento semanal.
-
Seleccione el Colección de residuos del almacén de datos y, a continuación, toque o haga clic en Ejecutar icono.
-
La colección de residuos del almacén de datos se ejecuta y su estado se muestra en el panel.
Ejecución de la colección de residuos del almacén de datos a través de la consola JMX running-data-store-garbage-collection-via-the-jmx-console
Esta sección trata sobre la ejecución manual de la colección de residuos del almacén de datos a través de la consola JMX. Si la instalación está configurada sin un almacén de datos externo, esto no se aplica a la instalación. Consulte las instrucciones sobre cómo ejecutar la limpieza de revisión en Mantenimiento del repositorio.
Para ejecutar la colección de residuos:
-
En la Consola de administración Apache Felix OSGi, resalte la variable Principal y seleccione JMX del siguiente menú.
-
A continuación, busque y haga clic en el botón Administrador de repositorios MBean (o vaya a
https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement). -
Haga clic en startDataStoreGC(boolean markOnly).
-
introduzca "
true" para elmarkOnlysi es necesario:table 0-row-2 1-row-2 Opción Descripción boolean markOnly Configúrelo en true para marcar únicamente las referencias y no barrer en la operación de marcar y barrer. Este modo se utilizará cuando el BlobStore subyacente se comparta entre varios repositorios diferentes. Para todos los demás casos, configúrelo en false para realizar la colección de residuos completa. -
Haga clic en Invocar. CRX ejecuta la colección de residuos e indica cuándo se ha completado.
Cannot perform operation: no service of type BlobGCMBean found después de invocar a . Consulte Configuración de almacenes de nodos y almacenes de datos en AEM 6 para obtener información sobre cómo configurar un almacén de datos de archivos.Automatización de la colección de residuos del almacén de datos automating-data-store-garbage-collection
Si es posible, la colección de residuos del almacén de datos debe ejecutarse cuando haya poca carga en el sistema, por ejemplo por la mañana.
La ventana de mantenimiento semanal incorporada, disponible a través de la Tablero de operaciones, contiene una tarea integrada para almacenar en déclencheur la colección de residuos del almacén de datos a la 1 a. m. los domingos. También debe comprobar que no hay copias de seguridad en ejecución en este momento. El inicio de la ventana de mantenimiento se puede personalizar mediante el panel de control según sea necesario.
Si no desea ejecutar la colección de residuos del almacén de datos con la ventana de mantenimiento semanal en el panel de operaciones, también se puede automatizar mediante los clientes HTTP wget o curl. A continuación se muestra un ejemplo de cómo automatizar la copia de seguridad mediante curl:
curl comandos puede que sea necesario configurar varios parámetros para la instancia; por ejemplo, el nombre de host ( localhost), puerto ( 4502), contraseña de administrador ( xyz) y varios parámetros para la colección de residuos del almacén de datos real.Este es un ejemplo de comando curl para invocar la colección de residuos del almacén de datos a través de la línea de comandos:
curl -u admin:admin -X POST --data markOnly=true http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean
El comando curl devuelve inmediatamente.
Comprobación de la coherencia del almacén de datos checking-data-store-consistency
La comprobación de coherencia del almacén de datos informará de cualquier binario del almacén de datos que falte pero al que se siga haciendo referencia. Para iniciar una comprobación de coherencia, siga estos pasos:
-
Vaya a la consola JMX. Para obtener información sobre cómo utilizar la consola JMX, consulte este artículo.
-
Busque la variable Blob GC Mbean y haga clic en él.
-
Haga clic en el
checkConsistency()vínculo.
Una vez completada la comprobación de coherencia, un mensaje mostrará el número de binarios que se han notificado como faltantes. Si el número es bueno a 0, marque la casilla error.log para obtener más información sobre los binarios que faltan.
A continuación encontrará un ejemplo de cómo se informan los binarios que faltan en los registros:
11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs
11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243