Dépannage des index Oak troubleshooting-oak-indexes
Réindexation lente slow-re-indexing
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 un long 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.
Détection initiale initial-detection
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.
L’indexation est suspendue après un arrêt forcé indexing-is-paused-after-a-forced-shutdown
Un arrêt forcé entraîne AEM suspension de l’indexation asynchrone pendant jusqu’à 30 minutes après le redémarrage. En règle générale, 15 minutes supplémentaires sont nécessaires pour terminer le premier passage de réindexation, pour un total d’environ 45 minutes (en revenant au délai Détection initiale période de 45 minutes). Dans le cas où vous pensez que l’indexation est suspendue après un arrêt forcé :
-
Tout d’abord, déterminez si l’instance AEM a été arrêtée de manière forcée (le processus AEM a été tué par la force, ou une panne de courant s’est produite) et ensuite redémarrée.
- La journalisation AEM peut être consultée à cet effet.
-
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.
Pool de threads surchargé thread-pool-overloaded
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’é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éfinissez un nouveau pool de threads isolé à utiliser par le planificateur Apache Sling pour l’indexation asynchrone :
- Sur l’instance affectée, accédez à la console web AEM OSGi > Configuration > Planificateur Apache Sling ou rendez-vous sur https://<hôte>:<port>/system/console/configMgr (par exemple, http://localhost:4502/system/console/configMgr).
- Ajoutez une entrée au champ "Pools de threads autorisés" avec la valeur "oak".
- Cliquez sur Enregistrer en bas à droite pour enregistrer les modifications.
-
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 de pool suivantes existent :
- ApacheSlingoak
- ApacheSlingdefault
-
La file d'attente d'observation est pleine observation-queue-is-full
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.- Lors de l’exécution d’opérations normales, cette valeur maximale doit toujours finalement se réduire à zéro (surtout dans la section
per second
). Vérifiez donc que la mesure en secondes deObservationQueueMaxLength
est de 0. - Si les valeurs sont supérieures ou égales à 10 000 et augmentent de manière régulière, cela indique qu’au moins une file d’attente (peut-être plus) ne peut pas être traitée aussi rapidement que de nouvelles modifications (validations) se produisent.
- Chaque file d’attente d’observation a une limite (10 000 par défaut) et si la file d’attente atteint cette limite, son traitement se dégrade.
- Lorsque vous utilisez MongoMK, comme la longueur des files d’attente augmente beaucoup, la performance du cache Oak interne se détériore. Cette corrélation peut être vue dans un
missRate
augmenté pour le cacheDocChildren
dans le MBean de statistiquesConsolidated Cache
.
- Lors de l’exécution d’opérations normales, cette valeur maximale doit toujours finalement se réduire à zéro (surtout dans la section
-
Pour éviter de dépasser les limites acceptables des files d’attente d’observation, il est recommandé de :
- Réduisez le taux constant de validations. De courts pics de validations sont acceptables, mais le taux constant doit être réduit.
- Augmentez la taille de
DiffCache
tel que décrit dans Conseils de réglages de performance > Réglage du stockage Mongo > Taille du cache des documents.
Identification et correction d’un processus de réindexation bloqué identifying-and-remediating-a-stuck-re-indexing-process
La réindexation peut être considérée comme "complètement 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 noeuds parcourus.
- Par exemple, s’il n’y a aucun message sur une heure ou si la progression est si lente qu’il faudra une semaine ou plus pour finir.
-
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 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.
- org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate
- org.apache.jackrabbit.oak.plugins.index.IndexUpdate
-
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.
- Le redémarrage d’AEM peut résoudre le problème dans le cas d’un chargement simultané élevé (un élément de la file d’attente d’observation ou élément similaire).
- Si un redémarrage ne permet pas de résoudre le problème, signalez-le à l’Assistance clientèle d’Adobe et fournissez toutes les informations collectées lors de l’étape 1.
Abandon sécurisé de la réindexation asynchrone safely-aborting-asynchronous-re-indexing
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 :
- La réindexation des index Lucene et Lucene Property peut être abandonnée car ils sont naturellement asynchrones.
- La réindexation des index de propriété Oak ne peut être interrompue si la réindexation a été initiée via
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 basé sur la piste de réindexation que vous souhaitez arrêter (
async
,async-reindex
oufulltext-async
).- Pour identifier la piste appropriée et donc l’instance MBean IndexStats, regardez la propriété « async » des index Oak. La propriété « async » contient le nom de piste :
async
,async-reindex
oufulltext-async
. - La piste est également disponible en accédant à AEM Gestionnaire d’index dans la colonne "Async". Pour accéder au gestionnaire d’index, accédez à Opérations > Diagnostic > Gestionnaire d’index.
- Pour identifier la piste appropriée et donc l’instance MBean IndexStats, regardez la propriété « async » des index Oak. La propriété « async » contient le nom de piste :
-
-
Invoquez la commande
abortAndPause()
sur le MBeanIndexStats
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
-
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.
- Dans le MBean
IndexStats
qui a envoyé la commandeabortAndPause()
à l’étape 2, invoquez la commanderesume()
.
- Dans le MBean
Prévention d’une réindexation lente preventing-slow-re-indexing
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.