Le processus de réindexation interne à AEM collecte les données du référentiel et les stocke dans les index Oak pour prendre en charge les requêtes de contenu de haute performance. Dans des cas exceptionnels, ce processus peut être lent, voire bloqué. Cette page servira de guide de dépannage pour vous aider à identifier si l’indexation est lente, rechercher la cause et résoudre le problème.
Il est important de faire la distinction entre la réindexation qui prend beaucoup de temps de manière inopportune et la réindexation qui prend un certain temps, car elle indexe de grandes quantités de contenu. Par exemple, le temps nécessaire pour indexer le contenu augmente en fonction de la quantité de contenu. Par conséquent, la réindexation des grands référentiels de production va prendre plus de temps que celle des petits référentiels de développement.
Voir Meilleures pratiques relatives aux requêtes et à l’indexation pour obtenir des informations supplémentaires indiquant 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. Cela rend les index asynchrones obsolètes.
Une fermeture forcée entraîne l’arrêt de l’indexation asynchrone par AEM pendant jusqu’à 30 minutes après le redémarrage et nécessite généralement 15 minutes supplémentaires pour terminer le premier passage de réindexation, pour un total d’environ 45 minutes (revenant à la durée de détection initiale de 45 minutes). Si vous pensez que l’indexation est mise en pause après une fermeture forcée :
Tout d’abord, déterminez si une instance AEM a été arrêtée de manière forcée (le processus AEM a été interrompu de manière brutale ou une coupure de courant s’est produite), puis redémarrée.
Si la fermeture forcée se produit, au redémarrage, AEM suspend automatiquement la réindexation pendant 30 minutes.
Attendez environ 45 minutes pour qu’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 cas exceptionnels, le pool de threads utilisé pour gérer l’indexation asynchrone risque d’être surchargé. Pour isoler le processus d’indexation, un pool de threads peut être configuré afin d’éviter qu’une autre tâche AEM interfère avec la capacité d’indexation du contenu en temps voulu d’Oak. Pour ce faire, vous devez :
Définir un pool de nouveaux threads isolés que le planificateur Apache Sling peut utiliser 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 Statut 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 suivantes du pool existent :
Si un trop grand nombre de modifications et de validations sont effectuées sur le référentiel en peu de temps, l’indexation peuvent être retardées à cause d’une file d’attente d’osbervation pleine. Tout d’abord, déterminez si la file d’attente 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 procéder comme suit :
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 « totalement bloquée » dans deux conditions :
La réindexation est très lente, au point où aucune progression significative n’est signalée dans les fichiers journaux concernant le nombre de nœuds transmis.
La réindexation est bloquée dans une boucle sans fin si des exceptions répétées apparaissent dans les fichiers journaux (par exemple, OutOfMemoryException
) dans le thread d’indexation. La répétition des mêmes exceptions dans le journal indique qu’Oak tente d’indexer le même élément à plusieurs reprises, mais échoue sur le même problème.
Pour identifier et résoudre un processus de réindexation bloqué, procédez comme suit :
Pour identifier la cause d’une indexation bloquée, les informations suivantes doivent être collectées :
Collectez 5 minutes de vidage des threads, un vidage de thread toutes les 2 secondes.
Définissez le niveau DEBUG et les 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 également être annulée (arrêtée avant qu’elle ne soit terminée) via les pistes d’indexation async, async-reindex
et ulltext-async
fulltext (MBean IndexStats
). Pour plus d’informations, consultez la documentation Apache Oak dans la section Abandon de la réindexation. En outre, prenez les éléments suivants en considération :
PropertyIndexAsyncReindexMBean
.Pour abandonner la réindexation, procédez comme suit :
Identifiez le MBean IndexStats qui contrôle la piste de réindexation qui doit être désactivé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 basé sur 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 éviter la reprise de la réindexation lors du redémarrage de l’indexation de piste.
Lors de la réindexation d’un index existant, définissez la propriété sur false.
/oak:index/someExistingIndex@reindex=false
Pour un nouvel index, vous pouvez également :
Définir la propriété du type sur désactivée
/oak:index/someNewIndex@type=disabled
ou supprimer la définition d’index entièrement
Lorsque cela est fait, validez les modifications dans le référentiel.
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 à la réindexation pendant les périodes calmes (par exemple, pas pendant une assimilation de contenu significative) et idéalement pendant les fenêtres de maintenance lorsque l’activité sur AEM est connue et contrôlée. En outre, assurez-vous que la réindexation n’a pas lieu pendant d’autres activités de maintenance.