AEM processus de réindexation interne collecte les données du référentiel et les stocke dans les index Oak afin de prendre en charge l’interrogation performante du contenu. Dans des circonstances exceptionnelles, le processus peut être lent, voire bloqué. Cette page sert de guide de dépannage pour aider à identifier si l’indexation est lente, trouver la cause et résoudre le problème.
Il est important de faire la distinction entre la réindexation qui prend un temps incorrectement long et la réindexation qui prend beaucoup de temps parce qu’elle indexe de grandes quantités de contenu. Par exemple, le temps nécessaire pour indexer le contenu est mis à l’échelle avec la quantité de contenu, de sorte que les référentiels de production volumineux prennent plus de temps à réindexer que les petits référentiels de développement.
Voir Bonnes pratiques relatives aux requêtes et à l’indexation pour plus d’informations sur quand et comment réindexer le contenu.
L’indexation lente de la détection initiale nécessite de parcourir les MBeans JMX IndexStats
. Sur l’instance AEM affectée, procédez comme suit :
Ouvrez la console web, cliquez sur l’onglet JMX ou rendez-vous sur https://<host>:<port>/system/console/jmx (par exemple, http://localhost:4502/system/console/jmx).
Accédez aux MBeans IndexStats
.
Ouvrez le MBeans IndexStats
pour « async
» et « fulltext-async
».
Pour les deux MBeans, vérifiez si les horodatages Done et LastIndexTime datent de moins de 45 minutes.
Pour un MBean, si la valeur temporelle (Done ou LastIndexedTime) date de plus de 45 minutes, alors la tâche d’indexation a échoué ou prend trop de temps. Ce problème entraîne l’obsolescence des index asynchrones.
Un arrêt forcé entraîne AEM suspension de l’indexation asynchrone pendant 30 minutes au maximum après le redémarrage. En outre, il faut généralement 15 minutes supplémentaires pour terminer la première passe de réindexation, pour un total d’environ 45 minutes (en revenant à la variable Détection initiale période de 45 minutes). Si l’indexation est suspendue après un arrêt forcé :
Tout d’abord, déterminez si l’instance d’AEM a été arrêtée de manière forcée (le processus d’AEM a été interrompu par la force ou une panne d’alimentation s’est produite) et redémarrez ultérieurement.
Si l’arrêt forcé s’est produit, au redémarrage, AEM arrête automatiquement la réindexation pendant 30 minutes au maximum.
Patientez environ 45 minutes pour que AEM reprenne les opérations d’indexation asynchrones normales.
Pour AEM 6.1, assurez-vous que le CFP 11 AEM 6.1 est installé.
Dans des circonstances exceptionnelles, le pool de threads utilisé pour gérer l’indexation asynchrone peut devenir surchargé. Pour isoler le processus d’indexation, un pool de threads peut être configuré afin d’empêcher le travail d’autres AEM d’interférer avec la capacité d’index du contenu d’une manière opportune d’Oak. Dans ce cas, procédez comme suit :
Définissez un nouveau pool de threads isolé à utiliser par le planificateur Apache Sling pour l’indexation asynchrone :
Vérifiez que le nouveau pool de threads du planificateur Apache Sling est enregistré et s’affiche dans la console web d’état du planificateur Apache Sling.
Accédez à la console web AEM OSGi > Statut > Planificateur Sling ou rendez-vous sur https://<hôte>:<port>/system/console/status-slingscheduler (par exemple, http://localhost:4502/system/console/status-slingscheduler).
Vérifiez que les entrées de pool suivantes existent :
Si trop de modifications et de validations sont effectuées dans le référentiel dans un délai court, l’indexation peut être retardée en raison d’une file d’attente d’observation complète. Tout d’abord, déterminez si la file d’attente d’observation est pleine :
Accédez à la console web et cliquez sur l’onglet JMX ou rendez-vous sur https://<hôte>:<port>/system/console/jmx (par exemple, http://localhost:4502/system/console/jmx).
Ouvrez le MBean Statistiques de référentiel Oak et déterminez si une valeur ObservationQueueMaxLength
est supérieure à 10 000.
per second
). Vérifiez donc que la mesure en secondes de ObservationQueueMaxLength
est de 0.missRate
augmenté pour le cache DocChildren
dans le MBean de statistiques Consolidated Cache
.Pour éviter de dépasser les limites acceptables des files d’attente d’observation, il est recommandé de :
DiffCache
tel que décrit dans Conseils de réglages de performance > Réglage du stockage Mongo > Taille du cache des documents.La réindexation peut être considérée comme "complètement bloquée" dans deux conditions :
La réindexation est lente, au point où aucune progression significative n’est signalée dans les fichiers journaux concernant le nombre de noeuds parcourus.
La réindexation est bloquée dans une boucle infinie si des exceptions répétées apparaissent dans les fichiers journaux (par exemple, OutOfMemoryException
) dans le thread d’indexation. La répétition d’une ou de plusieurs mêmes exceptions dans le journal indique qu’Oak tente d’indexer la même chose à plusieurs reprises, mais échoue sur le même problème.
Pour identifier et corriger un processus de réindexation bloqué, procédez comme suit :
Pour identifier la cause de l’indexation bloquée, les informations suivantes doivent être collectées :
Collectez 5 minutes de thread dump, un thread dump toutes les 2 secondes.
Définition du niveau DEBUG et des journaux pour les appenders.
Rassemblez les données du MBean asynchrone IndexStats
:
Accédez à le console web OSGi AEM > Principal > JMX > IndexStat > async
ou rendez-vous sur http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats.
Utilisez le mode console de oak-run.jar pour collecter les informations de ce qui se trouve sous le nœud /:async
.
Collectez une liste des points de contrôle du référentiel à l’aide du MBean CheckpointManager
:
Console web OSGi AEM > Principal > JMX > CheckpointManager > listCheckpoints()
ou rendez-vous sur http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DSegment+node+store+checkpoint+management%2Ctype%3DCheckpointManager.
Après la collecte de toutes les informations décrites à l’étape 1, redémarrez AEM.
La réindexation peut être abandonnée en toute sécurité (arrêtée avant d’être terminée) via le async, async-reindex
et f ulltext-async
pistes d’indexation ( IndexStats
Mbean). Pour plus d’informations, consultez la documentation Apache Oak dans la section Abandon de la réindexation. Tenez également compte des points suivants :
PropertyIndexAsyncReindexMBean
.Pour annuler la réindexation en toute sécurité, procédez comme suit :
Identifiez le MBean IndexStats qui contrôle la piste de réindexation qui doit être arrêtée.
Accédez au MBean IndexStats approprié via la console JMX en accédant à la console web OSGi AEM > Principal > JMX ou à https://<hôte>:<port>/system/console/jmx (par exemple, http://localhost:4502/system/console/jmx).
Ouvrez le MBean IndexStats en fonction de la piste de réindexation que vous souhaitez arrêter ( async
, async-reindex
ou fulltext-async
)
async
, async-reindex
ou fulltext-async
.Invoquez la commande abortAndPause()
sur le MBean IndexStats
approprié.
Marquez la définition d’index Oak de manière appropriée pour empêcher la reprise de la réindexation lorsque la piste d’indexation reprend.
Lors de la réindexation d’une existant index, définissez la propriété reindex sur false
/oak:index/someExistingIndex@reindex=false
Ou sinon, pour un new index, soit :
Définissez la propriété type sur disabled
/oak:index/someNewIndex@type=disabled
ou supprimer entièrement la définition d’index
Validez les modifications apportées au référentiel une fois l’opération terminée.
Enfin, reprenez l’indexation asynchrone sur la piste d’indexation abandonnée.
IndexStats
qui a envoyé la commande abortAndPause()
à l’étape 2, invoquez la commande resume()
.Il est préférable de procéder à une réindexation pendant les périodes de silence (par exemple, pas lors d’une ingestion de contenu importante), et idéalement pendant les fenêtres de maintenance lorsque AEM chargement est connu et contrôlé. Assurez-vous également que la réindexation n’a pas lieu pendant d’autres activités de maintenance.