Documentación AEM 6.4 Guía de implementación

Resolución de problemas de índices Oak troubleshooting-oak-indexes

Last update: Fri May 05 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Temas:
Deploying

Creado para:

Developer

CAUTION

AEM 6.4 ha llegado al final de la compatibilidad ampliada y esta documentación ya no se actualiza. Para obtener más información, consulte nuestra períodos de asistencia técnica. Buscar las versiones compatibles here.

Reindexación lenta slow-re-indexing

AEM proceso de reindexación interna recopila datos del repositorio y los almacena en los índices Oak para admitir la consulta del contenido de forma eficaz. En circunstancias excepcionales, el proceso puede llegar a ser lento o incluso atascado. Esta página actúa como guía de solución de problemas para ayudar a identificar si la indexación es lenta, encontrar la causa y resolver el problema.

Es importante distinguir entre la reindexación que lleva una cantidad de tiempo inapropiadamente larga y la reindexación que lleva mucho tiempo porque está indexando grandes cantidades de contenido. Por ejemplo, el tiempo que se tarda en indexar el contenido se escala con la cantidad de contenido, por lo que los repositorios de producción grandes tardarán más en reindexarse que los repositorios de desarrollo pequeños.

Consulte la Prácticas recomendadas en consultas e indexación para obtener información adicional sobre cuándo y cómo volver a indexar contenido.

Detección inicial initial-detection

La detección inicial de la indexación lenta requiere la revisión de la variable IndexStats JMX MBeans. En la instancia de AEM afectada, haga lo siguiente:

Abra la consola web y haga clic en la pestaña JMX o vaya a https://<host>:<port>/system/console/jmx (por ejemplo, http://localhost:4502/system/console/jmx).
Vaya a la IndexStats Mbeans.
Abra el IndexStats MBeans para " async" y " fulltext-async".
Para ambos MBeans, compruebe si la variable Listo timestamp y LastIndexTime la marca de tiempo es inferior a 45 minutos desde la hora actual.
Para cualquiera de los MBean, si el valor de tiempo (Listo o LastIndexedTime) es bueno a 45 minutos desde el momento actual, entonces el trabajo de índice está fallando o tardando demasiado. Esto hace que los índices asíncronos estén obsoletos.

La indexación se pone en pausa después de un cierre forzado indexing-is-paused-after-a-forced-shutdown

Un cierre forzado provoca AEM suspensión de la indexación asincrónica durante un máximo de 30 minutos después del reinicio y, por lo general, requiere otros 15 minutos para completar la primera fase de reindexación, durante un total aproximado de 45 minutos (volver a la Detección inicial periodo de tiempo de 45 minutos). En el caso de que sospeche que la indexación está en pausa después de un cierre forzado:

En primer lugar, determine si la instancia de AEM se cerró de manera forzada (el proceso de AEM fue violado a la fuerza o se produjo un fallo de energía) y luego se reinició.
- Registro de AEM puede revisarse con este fin.
Si se produjo el cierre forzado, al reiniciar, AEM suspende automáticamente la reindexación durante un máximo de 30 minutos.
Espere aproximadamente 45 minutos para que la AEM reanude las operaciones de indexación asíncronas normales.

Grupo de subprocesos sobrecargado thread-pool-overloaded

NOTE

Para AEM 6.1, asegúrese de que AEM 6.1 CFP 11 está instalado.

En circunstancias excepcionales, el grupo de subprocesos utilizado para administrar la indexación asíncrona puede sobrecargarse. Para aislar el proceso de indexación, se puede configurar un grupo de subprocesos para evitar que otros trabajos de AEM interfieran con la capacidad de Oak de indexar contenido de manera oportuna. Para ello, debe:

Defina un nuevo grupo de subprocesos aislado para el programador de Sling de Apache que se utilizará para la indexación asíncrona:
- En la instancia de AEM afectada, vaya a AEM OSGi Web Console>OSGi>Configuration>Apache Sling Scheduler o vaya a https://<host>:<port>/system/console/configMgr (por ejemplo, http://localhost:4502/system/console/configMgr)
- Agregue una entrada al campo "Grupos de subprocesos permitidos" con el valor "roak".
- Haga clic en Guardar en la parte inferior derecha para guardar los cambios.
Compruebe que el nuevo grupo de subprocesos del programador de Sling de Apache esté registrado y se muestre en la consola web del estado del programador de Sling de Apache.
- Vaya a la consola web OSGi de AEM > Estado > Programador de Sling o vaya a https://<host>:<port>/system/console/status-slingscheduler (por ejemplo, http://localhost:4502/system/console/status-slingscheduler)
- Compruebe que existen las siguientes entradas de grupo:
  - ApacheSlingoak
  - ApacheSlingdefault

La cola de observación está llena observation-queue-is-full

Si se realizan demasiados cambios y confirmaciones en el repositorio en un corto periodo de tiempo, la indexación se puede retrasar debido a una cola de observación completa. En primer lugar, determine si la cola de observación está llena:

Vaya a la consola web y haga clic en la pestaña JMX o vaya a https://<host>:<port>/system/console/jmx (por ejemplo, http://localhost:4502/system/console/jmx)
Abra Oak Repository Statistics MBean y determine si existe ObservationQueueMaxLength es bueno que 10 000.
- En las operaciones normales, este valor máximo siempre debe reducirse eventualmente a cero (especialmente en la variable per second (sección) para verificar que la variable ObservationQueueMaxLengthLas métricas de segundos de son 0.
- Si los valores son 10 000 o más y aumentan de forma constante, esto indica que al menos una (posiblemente más) cola no se puede procesar tan rápido como se produzcan nuevos cambios (confirmaciones).
- Cada cola de observación tiene un límite (10 000 por defecto) y si la cola alcanza ese límite, su procesamiento se degrada.
- Cuando se utiliza MongoMK, a medida que aumentan las longitudes de cola, se degrada el rendimiento interno de la caché de Oak. Esta correlación se puede ver en un aumento missRate para el DocChildren en el Consolidated Cache statistics MBean.
Para evitar superar los límites aceptables de las colas de observación, se recomienda:
- Reduzca la velocidad constante de confirmaciones. Los picos cortos en confirmaciones son aceptables, pero la tasa constante debería reducirse.
- Aumente el tamaño de la variable DiffCache tal como se describe en Consejos de ajuste de rendimiento > Ajuste de almacenamiento Mongo > Tamaño de la caché del documento.

Identificación y corrección de un proceso de reindexación atascado identifying-and-remediating-a-stuck-re-indexing-process

La reindexación puede considerarse "completamente atascada" bajo dos condiciones:

La reindexación es muy lenta, hasta el punto en que no se notifica ningún progreso significativo en los archivos de registro con respecto al número de nodos atravesados.
- Por ejemplo, si no hay mensajes en el curso de una hora o si el progreso es tan lento que tardará una semana o más en terminar.
La reindexación está atascada en un bucle sin fin si aparecen excepciones repetidas en los archivos de registro (por ejemplo, OutOfMemoryException) en el subproceso de indexación. La repetición de las mismas excepciones en el registro, indica que Oak intenta indexar lo mismo repetidamente, pero falla en el mismo tema.

Para identificar y corregir un proceso de reindexación atascado, haga lo siguiente:

Para identificar la causa de la indexación atascada, se debe recopilar la siguiente información:
- Recopile 5 minutos de volcado de subprocesos, un volcado de subprocesos cada 2 segundos.
- Establezca el nivel de depuración y los registros para los anexadores.
  - org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate
  - org.apache.jackrabbit.oak.plugins.index.IndexUpdate
- Recopilación de datos de async IndexStats MBean:
  - Vaya a AEM OSGi Web Console>Main>JMX>IndexStat>async
    
    o vaya a http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats
- Uso modo de consola de oak-run.jar para recopilar los detalles de lo que existe en el * /:async* nodo.
- Recopile una lista de puntos de comprobación del repositorio utilizando el CheckpointManager MBean:
  - AEM OSGi Web Console>Principal>JMX>CheckpointManager>listCheckpoints()
    
    o vaya a http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DSegment+node+store+checkpoint+management%2Ctype%3DCheckpointManager
Después de recopilar toda la información descrita en el paso 1, reinicie AEM.
- El reinicio AEM puede resolver el problema en el caso de una carga simultánea alta (desbordamiento de la cola de observación o algo similar).
- Si un reinicio no resuelve el problema, abra un problema con Servicio de atención al cliente de Adobe y proporcionar toda la información recopilada en el paso 1.

Anulación segura de la reindexación asincrónica safely-aborting-asynchronous-re-indexing

La reindexación se puede anular de forma segura (se detiene antes de que se complete) mediante la variable async, async-reindexy f ulltext-async rutas de indexación ( IndexStats Mbean). Para obtener más información, consulte también la documentación de Apache Oak sobre Cómo evitar la reindexación. Además, tenga en cuenta que:

La reindexación de los índices de propiedades de Lucene y Lucene puede anularse porque son naturalmente asíncronos.
La reindexación de los índices de propiedades de Oak solo se puede anular si la reindexación se inició mediante la variable PropertyIndexAsyncReindexMBean.

Para anular la reindexación de forma segura, siga estos pasos:

Identifique el IndexStats MBean que controla el carril de reindexación que debe detenerse.
- Vaya a la consola JMX de IndexStats MBean adecuada en AEM OSGi Web Console>Main>JMX o https://<host>:<port>/system/console/jmx (por ejemplo, http://localhost:4502/system/console/jmx)
- Abra IndexStats MBean en función del carril de reindexación que desee detener ( async, async-reindexo fulltext-async)
  - Para identificar el carril apropiado y, por lo tanto, la instancia de IndexStats MBean, consulte la propiedad "async" de los índices Oak. La propiedad "async" contiene el nombre del carril: async, async-reindexo fulltext-async.
  - El carril también está disponible accediendo AEM Administrador de índices en la columna "Sincronización". Para acceder al Administrador de índices, vaya a Operaciones > Diagnóstico > Administrador de índices.
Invocar el abortAndPause() en el IndexStats MBean.
Marque la definición del índice Oak adecuadamente para evitar reanudar la reindexación cuando se reanude el carril de indexación.
- Cuando se vuelve a indexar un existente index, establezca la propiedad reindex en false
  - /oak:index/someExistingIndex@reindex=false
- O bien, para un new índice, ya sea:
  - Establezca la propiedad de tipo como deshabilitada
    - /oak:index/someNewIndex@type=disabled
  - o eliminar por completo la definición del índice
Confirme los cambios en el repositorio cuando se completen.
Finalmente, reanude la indexación asíncrona en el carril de indexación anulado.
- En el IndexStats MBean que emitió el abortAndPause() en el paso 2, invoque la función resume()comando.

Prevención de la reindexación lenta preventing-slow-re-indexing

Es mejor volver a indexar durante periodos silenciosos (por ejemplo, no durante una ingesta de contenido grande) e idealmente durante las ventanas de mantenimiento cuando AEM carga se conoce y controla. Además, asegúrese de que la reindexación no tenga lugar durante otras actividades de mantenimiento.

recommendation-more-help

6a71a83d-c2e0-4ce7-a6aa-899aa3885b56