Show Menu
SUJETS×

Dépannage des index Oak

Réindexation lente

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.

Détection initiale

L’indexation lente de la détection initiale nécessite de parcourir les MBeans IndexStats JMX. Sur l’instance AEM affectée, procédez comme suit :
  1. Open the Web Console and click the JMX tab or go to https://<host>:<port>/system/console/jmx (for example, http://localhost:4502/system/console/jmx ).
  2. Navigate to the IndexStats Mbeans.
  3. Ouvrez les IndexStats MBeans pour " async " et " fulltext-async ".
  4. For both MBeans, check if the Done timestamp and LastIndexTime timestamp are less than 45 mins from the current time.
  5. Pour un MBean, si la valeur temporelle ( Done ou LastIndexedTime ) date de plus de 45 minutes avant l’heure actuelle, alors la tâche d’index est défectueuse ou prend trop de temps. Les index asynchrones sont donc obsolètes.

L’indexation est interrompue après une fermeture forcée

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 :
  1. 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.
  2. Si la fermeture forcée se produit, au redémarrage, AEM suspend automatiquement la réindexation pendant 30 minutes.
  3. Attendez environ 45 minutes pour qu’AEM reprenne les opérations d’indexation asynchrones normales.

Pool de threads surchargé

For AEM 6.1, ensure that AEM 6.1 CFP 11 is installed.
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 :
  1. Définir un pool de nouveaux threads isolés que le planificateur Apache Sling peut utiliser pour l’indexation asynchrone :
    • On the affected AEM instance, navigate to AEM OSGi Web Console>OSGi>Configuration>Apache Sling Scheduler or go to https://<host>:<port>/system/console/configMgr (for example, http://localhost:4502/system/console/configMgr )
    • Ajoutez une entrée au champ « Allowed Thread Pools » (Pools de threads autorisés), avec la valeur « oak ».
    • Cliquez sur Enregistrer en bas à droite pour enregistrer les modifications.
  2. 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.
    • Navigate to the AEM OSGi Web console>Status>Sling Scheduler or go to https://<host>:<port>/system/console/status-slingscheduler (for example, http://localhost:4502/system/console/status-slingscheduler )
    • Vérifiez que les entrées suivantes du pool existent :
      • ApacheSlingoak
      • ApacheSlingdefault

La file d’attente d’observation est pleine

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 :
  1. Go to the Web Console and click the JMX tab or go to https://<host>:<port>/system/console/jmx (for example, http://localhost:4502/system/console/jmx )
  2. Ouvrez le MBean Statistiques de référentiel Oak et déterminez si une valeur ObservationQueueMaxLength est supérieure à 10 000.
    • In normal operations, this maximum value must always eventually reduce to zero (especially in the per second section) so verify that the ObservationQueueMaxLength 's seconds metrics are 0.
    • Si les valeurs sont de 10 000 ou plus et augmentent progressivement, cela signifie qu’au moins une file d’attente (probablement plusieurs) ne peut pas être traitée aussi rapidement pendant que de nouvelles modifications (commits) ont lieu.
    • Chaque file d’attente d’observation est limitée (10 000 par défaut), et si la file d’attente atteint cette limite, son traitement se détériore.
    • Lorsque vous utilisez MongoMK, comme la longueur des files d’attente augmente beaucoup, la performance du cache Oak interne se détériore. This correlation can be seen in an increased missRate for the DocChildren cache in the Consolidated Cache statistics MBean.
  3. Pour éviter de dépasser les limites acceptables des files d’attente d’observation, il est recommandé de procéder comme suit :

Identification d’un processus de réindexation bloqué et résolution du problème

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.
    • Par exemple, s’il n’y a aucun message pendant une heure, ou si la progression est tellement lente qu’elle prend une semaine ou plus à se terminer.
  • 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 :
  1. Pour identifier la cause d’une indexation bloquée, les informations suivantes doivent être collectées :
  2. Après avoir collecté 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).
    • If a restart does not solve the problem, open an issue with Adobe Customer Care and provide all the information collected in Step 1.

Abandon sécurisé de la réindexation asynchrone

Re-indexing can be safely aborted (stopped before it is completed) via the async, async-reindex and f ulltext-async indexing lanes ( IndexStats Mbean). For more information, also see the Apache Oak documentation on How to Abort Reindexing . En outre, il faut tenir compte du fait que :
  • La réindexation des index Lucene et Lucene Property peut être abandonnée, car ils sont naturellement asynchrones.
  • The re-indexing of Oak Property Indexes can only be aborted if re-indexing was intiated via the PropertyIndexAsyncReindexMBean .
Pour abandonner la réindexation, procédez comme suit :
  1. Identifiez le MBean IndexStats qui contrôle la piste de réindexation qui doit être désactivée.
    • Navigate to the appropriate IndexStats MBean via the JMX console by going to either AEM OSGi Web Console>Main>JMX or https://<host>:<port>/system/console/jmx (for example, http://localhost:4502/system/console/jmx )
    • Open the IndexStats MBean based on the re-indexing lane that you wish to stop ( async , async-reindex , or fulltext-async )
      • Pour identifier la voie appropriée et donc l’instance MBean IndexStats, consultez la propriété "async" des index Oak. The "async" property will contain the lane name: async , async-reindex , or fulltext-async .
      • La piste est également disponible en accédant au gestionnaire d’index d’AEM dans la colonne « Async ». Pour accéder au gestionnaire d’index, rendez-vous sur Opération > Diagnostic > Gestionnaire d’index.
  2. Invoke the abortAndPause() command on the appropriate IndexStats MBean.
  3. Marquez la définition de l’index Oak de manière appropriée afin d’empêcher la reprise de l’indexation lorsque la voie d’indexation reprend.
    • When re-indexing an existing index, set the reindex property to 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.
  4. Enfin, reprenez l’indexation asynchrone sur la piste d’indexation abandonnée.
    • In the IndexStats MBean that issued the abortAndPause() command in Step 2, invoke the resume() command.

Prévention de la réindexation lente

Il est préférable de procéder à une nouvelle indexation pendant les périodes de silence (par exemple, pas pendant un chargement de contenu important), et idéalement pendant les fenêtres de maintenance lorsque la charge d’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.