Show Menu
THEMEN×

Fehlerbehebung bei Oak-Indizes

Langsame Neuindizierung

Bei der internen AEM-Neuindizierung werden Repository-Daten gesammelt und in Oak-Indizes gespeichert, die die performante Abfrage von Inhalt unterstützen. Bei außergewöhnlichen Umständen kann der Vorgang langsam werden oder sogar anhalten. Diese Seite dient als Leitfaden zur Fehlerbehebung und soll Sie dabei unterstützen, langsame Indizierungen und deren Ursache zu erkennen und zu beheben.
Dabei muss zwischen Neuindizierungen unterschieden werden, die ungewöhnliche lange dauern, und Neuindizierungen, die aufgrund der sehr großen Menge an Inhalt lange brauchen. Die für die Inhaltsindizierung benötigte Zeit ist beispielsweise abhängig von der Menge an Inhalt. Daher dauert die Neuindizierung großer Produktions-Repositorys länger als die Indizierung kleiner Entwicklungs-Repositorys.
Weitere Informationen dazu, wann und wie Sie Inhalt neu indizieren, finden Sie unter Best Practices für Abfragen und Indizierung .

Anfängliche Erkennung

Um eine langsame Indizierung anfänglich zu erkennen, müssen die IndexStats -JMX-MBeans überprüft werden. Klicken Sie auf die betroffene AEM-Instanz und gehen Sie wie folgt vor:
  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. Öffnen Sie die IndexStats MBeans für " async " und " fulltext-async ".
  4. For both MBeans, check if the Done timestamp and LastIndexTime timestamp are less than 45 mins from the current time.
  5. Falls für eines der MBeans der Zeitstempel ( Done oder LastIndexedTime ) mehr als 45 Minuten zurückliegt, dauert der Indizierungsvorgang zu lange oder ist fehlgeschlagen. Dies führt dazu, dass die asynchronen Indizes veraltet sind.

Indizierung wird nach erzwungenem Abschalten angehalten

Nach einem erzwungenen Abschalten hält AEM die asynchrone Indizierung bis zu 30 Minuten nach dem Neustart an und benötigt in der Regel weitere 15 Minuten, also insgesamt 45 Minuten, um den ersten Indizierungsdurchgang abzuschließen. (Dies entspricht dem Zeitrahmen von 45 Minuten für die anfängliche Erkennung ). Falls Sie vermuten, dass die Indizierung nach einem erzwungenen Abschalten angehalten wurde, gehen Sie wie folgt vor:
  1. Finden Sie zuerst heraus, ob das Abschalten der AEM-Instanz erzwungen wurde (das Ende des AEM-Vorgangs wurde erzwungen oder ein Stromausfall trat auf) und diese anschließend neu gestartet wurde.
  2. Falls das Abschalten erzwungen wurde, wurde die Neuindizierung von AEM beim Neustart automatisch für bis zu 30 Minuten angehalten.
  3. Warten Sie ungefähr 45 Minuten, dass AEM den normalen asynchronen Indizierungsvorgang wieder aufnimmt.

Thread-Pool überlastet

For AEM 6.1, ensure that AEM 6.1 CFP 11 is installed.
Bei außergewöhnlichen Umständen kann der zum Verwalten der asynchronen Indizierung verwendete Thread-Pool überlastet sein. Um den Indizierungsvorgang zu isolieren, kann ein Thread-Pool konfiguriert werden, der verhindert, dass andere AEM-Vorgänge die zügige Inhaltsindizierung von Oak beeinträchtigen. Gehen Sie dazu wie folgt vor:
  1. Definieren Sie einen neuen, isolierten Thread-Pool für den Apache Sling Scheduler:
    • 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 )
    • Geben Sie in das Feld „Allowed Thread Pools“ den Wert „Oak“ ein.
    • Klicken Sie unten rechts auf „Save“, um die Änderungen zu speichern.
  2. Überprüfen Sie, dass der neue Thread-Pool in Apache Sling Scheduler registriert ist und in der Statusanzeige der Web-Konsole von Apache Sling Scheduler angezeigt wird.
    • 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 )
    • Vergewissern Sie sich, dass die folgenden Pool-Einträge vorhanden sind:
      • ApacheSlingoak
      • ApacheSlingdefault

Überwachungswarteschlange ist voll

Falls am Repository in kurzer Zeit zu viele Änderungen oder Commits erfolgen, kann dies die Indizierung verzögern, da die Überwachungswarteschlange voll ist. Stellen Sie zuerst fest, ob die Überwachungswarteschlange voll ist:
  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. Öffnen Sie im Oak-Repository das Statistik-MBean und überprüfen Sie, ob einer der Werte für ObservationQueueMaxLength mehr als 10.000 beträgt.
    • Bei normalem Betrieb wird dieser Höchstwert letztendlich auf Null reduziert (insbesondere im Abschnitt per second ). Überprüfen Sie daher, ob der Sekundenwert für ObservationQueueMaxLength 0 beträgt.
    • Falls die Werte 10.000 oder mehr betragen und ständig steigen, deutet dies darauf hin, dass mindestens eine Warteschlange nicht so schnell verarbeitet werden kann wie neue Änderungen (Commits) erfolgen.
    • Jede Beobachtungswarteschlange hat einen Grenzwert (standardmäßig 10,000). Wenn dieser Grenzwert erreicht ist, verschlechtert sich die Verarbeitung der Warteschlange.
    • Bei Verwendung von MongoMK verschlechtert sich die interne Leistung des Oak-Cache mit zunehmender Warteschlangengröße. This correlation can be seen in an increased missRate for the DocChildren cache in the Consolidated Cache statistics MBean.
  3. Folgende Vorgehensweise ist empfohlen, um das Überschreiten der akzeptablen Grenzwerte für die Überwachungswarteschlange zu vermeiden:

Erkennen und Beheben von Unterbrechungen beim Neuindizierungsvorgang

Die Neuindizierung gilt unter zwei Bedingungen als „vollständig unterbrochen“:
  • Die Neuindizierung ist sehr langsam. In den Protokolldateien wird kein wirklicher Fortschritt bei der Anzahl der durchsuchten Knoten erfasst.
    • Beispiel: Falls innerhalb einer Stunde keine Meldungen erfolgen oder der Fortschritt so langsam ist, dass der Vorgang mindestens eine Woche dauert.
  • Die Neuindizierung hängt in einer endlosen Schleife, wenn wiederholte Ausnahmen in den Protokolldateien des Indizierungs-Thread angezeigt werden (beispielsweise OutOfMemoryException ). Die Wiederholung der gleichen Ausnahmen im Protokoll deutet auf Oak-Versuche hin, die gleichen Daten wiederholt zu indizieren, wobei immer der gleiche Fehler auftritt.
Gehen Sie wie folgt vor, um einen unterbrochenen Neuindizierungsvorgang zu identifizieren und zu beheben:
  1. Um die Ursache einer unterbrochenen Indizierung zu finden, benötigen Sie folgende Informationen:
  2. Nachdem Sie alle in Schritt 1 beschriebenen Informationen gesammelt haben, starten Sie AEM neu.
    • Durch Neustarten von AEM kann das Problem im Fall von hohen gleichzeitigen Lasten (überlaufende Überwachungswarteschlange oder Ähnliches) eventuell behoben werden.
    • If a restart does not solve the problem, open an issue with Adobe Customer Care and provide all the information collected in Step 1.

Sicheres Abbrechen der asynchronen Neuindizierung

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 . Berücksichtigen Sie zusätzlich Folgendes:
  • Die Neuindizierung von Lucene- und Lucene-Eigenschaftenindizes kann abgebrochen werden, da sie asynchron ist.
  • The re-indexing of Oak Property Indexes can only be aborted if re-indexing was intiated via the PropertyIndexAsyncReindexMBean .
Um die Neuindizierung sicher abzubrechen, führen Sie folgende Schritte aus:
  1. Identifizieren Sie das indexStats-MBean, das die Neuindizierungsspur steuert, die Sie stoppen möchten.
    • 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 )
      • Um die entsprechende Spur und damit die IndexStats MBean-Instanz zu identifizieren, sehen Sie sich die Eigenschaft "async"der Oak-Indizes an. The "async" property will contain the lane name: async , async-reindex , or fulltext-async .
      • Sie können auch über den AEM-Index-Manager in der Spalte „Asynchron“ auf die Spur zugreifen. Um auf den Index-Manager zuzugreifen, wechseln Sie zu „Vorgänge“ > „Diagnose“ > „Index-Manager“.
  2. Invoke the abortAndPause() command on the appropriate IndexStats MBean.
  3. Markieren Sie die Indexdefinition der Oak, um zu verhindern, dass die Neuindizierung fortgesetzt wird, wenn die Indexspur wieder aufgenommen wird.
    • When re-indexing an existing index, set the reindex property to false
      • /oak:index/someExistingIndex@reindex=false
    • Bei einem neuen Index gehen Sie wie folgt vor:
      • Setzen Sie die Type-Eigenschaft auf „disabled“
        • /oak:index/someNewIndex@type=disabled
      • oder entfernen Sie die Indexdefinition vollständig. Speichern Sie die Änderungen nach Beendigung des Vorgangs im Repository.
  4. Setzen Sie dann die asynchrone Indizierung auf den abgebrochenen Index-Spuren fort.
    • In the IndexStats MBean that issued the abortAndPause() command in Step 2, invoke the resume() command.

Verhindern der langsamen Neuindizierung

Am besten ist es, die Indexierung während ruhiger Zeiträume (z. B. nicht während einer großen Inhaltsaufnahme) und idealerweise während Wartungsfenstern, wenn AEM-Ladezeit bekannt und kontrolliert ist, erneut durchzuführen. Vergewissern Sie sich außerdem, dass Ihre Neuindizierung nicht während anderer Wartungstätigkeiten stattfindet.