Documentatie AEM 6.4 Implementatiehandleiding

Probleemoplossing voor Oak-indexen troubleshooting-oak-indexes

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Onderwerpen:
Deploying

Gemaakt voor:

Developer

CAUTION

AEM 6.4 heeft het einde van de uitgebreide ondersteuning bereikt en deze documentatie wordt niet meer bijgewerkt. Raadpleeg voor meer informatie onze technische ondersteuningsperioden. Ondersteunde versies zoeken hier.

Langzaam opnieuw indexeren slow-re-indexing

AEM intern herindexeringsproces verzamelt gegevens in de opslagplaats en slaat deze op in Eak-indexen om het vragen van inhoud door prestaties te ondersteunen. In uitzonderlijke omstandigheden kan het proces langzaam of zelfs vastlopen. Deze pagina fungeert als gids voor het oplossen van problemen, zodat u kunt zien of de indexering langzaam verloopt, de oorzaak vindt en het probleem verhelpt.

Het is belangrijk om onderscheid te maken tussen opnieuw indexeren die een onterecht lange hoeveelheid tijd vergt, en opnieuw indexeren die een lange hoeveelheid tijd vergt omdat het enorme hoeveelheden inhoud indexeert. De tijd die nodig is om de inhoud te indexeren, wordt bijvoorbeeld geschaald met de hoeveelheid inhoud, zodat grote productieopslagplaatsen langer nodig hebben om opnieuw te indexeren dan kleine opslagplaatsen.

Zie de Beste praktijken op Vragen en het Indexeren voor aanvullende informatie over wanneer en hoe inhoud opnieuw moet worden geïndexeerd.

Eerste detectie initial-detection

De initiële detectie vertraagt de indexering vereist dat de IndexStats JMX MBeans. Ga als volgt te werk voor de betreffende AEM instantie:

Open de webconsole en klik op het tabblad JMX of ga naar https://<host>:<port>/system/console/jmx (bijvoorbeeld http://localhost:4502/system/console/jmx).
Ga naar de IndexStats Bonen.
Open de IndexStats MBeans voor " async" en " fulltext-async".
Voor beide MBeans, controleer als Gereed tijdstempel en LastIndexTime de tijdstempel is minder dan 45 minuten van de huidige tijd.
Voor één van beide MBean, als de tijdwaarde (Gereed of LastIndexedTime) is meer dan 45 minuten van de huidige tijd, dan ontbreekt de indexbaan of neemt te lang. Hierdoor worden de asynchrone indexen stabiel.

De indexering wordt gepauzeerd na een gedwongen sluiting indexing-is-paused-after-a-forced-shutdown

Een gedwongen sluiting resulteert in AEM het schorsen van asynchrone indexering tot 30 minuten na het opnieuw beginnen, en typisch vereist nog 15 minuten om de eerste re-indexerende pas te voltooien, voor een totaal van ongeveer 45 minuten (die terug naar het terugkoppelen Eerste detectie tijdsbestek van 45 minuten). Als u vermoedt dat indexering is gepauzeerd na een geforceerde afsluiting:

Ten eerste, bepaal of de AEM instantie op gedwongen wijze werd afgesloten (het AEM proces werd met kracht gedood, of er een stroomuitval plaatsvond) en vervolgens opnieuw werd opgestart.
- AEM kunnen voor dit doel worden herzien.
Als de gedwongen sluiting optrad, na opnieuw beginnen, AEM automatisch het opnieuw indexeren voor maximaal 30 minuten opschort.
Wacht ongeveer 45 minuten op AEM om normale asynchrone indexeringsverrichtingen te hervatten.

Thread pool overloaded thread-pool-overloaded

NOTE

Voor AEM 6.1 moet u ervoor zorgen dat AEM 6.1 GVB 11 is geïnstalleerd.

In uitzonderlijke omstandigheden, kan de draadpool die wordt gebruikt om asychronous indexing te beheren overbelast worden. Om het indexeren proces te isoleren, kan een draadpool worden gevormd om ander AEM werk te verhinderen met de capaciteit van het Eak om inhoud op geschikte wijze te indexeren. Om dit te doen, zou u moeten:

Definieer een nieuwe, geïsoleerde draadpool voor de Apache Sling Scheduler voor asynchrone indexering:
- Navigeer in de betreffende AEM naar AEM OSGi Web Console>OSGi>Configuration>Apache Sling Scheduler of ga naar https://<host>:<port>/system/console/configMgr (bijvoorbeeld http://localhost:4502/system/console/configMgr)
- Voeg een item aan het veld "Toegestane threads" toe met de waarde "eikel".
- Klik op Opslaan in de rechterbenedenhoek om de wijzigingen op te slaan.
Controleer of de nieuwe Apache Sling Scheduler-thread-pool is geregistreerd en wordt weergegeven in de Apache Sling Scheduler-webconsole.
- Navigeer naar de AEM OSGi Webconsole>Status>Sling Scheduler of ga naar https://<host>:<port>/system/console/status-slingplanner (bijvoorbeeld http://localhost:4502/system/console/status-slingscheduler)
- Controleer of de volgende poolitems bestaan:
  - ApacheSlingoak
  - ApacheSlingdefault

De waarnemingswachtrij is vol observation-queue-is-full

Als er te veel veranderingen en verplichtingen in korte tijd aan de repository worden aangebracht, kan de indexering vertraagd worden vanwege een volledige waarnemingswachtrij. Ten eerste bepalen of de waarnemingswachtrij vol is:

Ga naar de webconsole en klik op het tabblad JMX of ga naar https://<host>:<port>/system/console/jmx (bijvoorbeeld http://localhost:4502/system/console/jmx)
Open de Statistieken van de Bewaarplaats van de Eak MB en bepaal als om het even welk ObservationQueueMaxLength waarde is groter dan 10.000.
- Bij normale bewerkingen moet deze maximumwaarde uiteindelijk altijd tot nul worden teruggebracht (met name in de per second ) om te controleren of de ObservationQueueMaxLengths seconden metriek is 0.
- Als de waarden 10.000 of meer zijn en gestaag toenemen, geeft dit aan dat ten minste één (mogelijk meer) wachtrij niet kan worden verwerkt zodra nieuwe wijzigingen (vastleggingen) optreden.
- Elke waarnemingswachtrij heeft een limiet (standaard ingesteld op 10.000) en als de wachtrij deze limiet bereikt, neemt de verwerking af.
- Als u MongoMK gebruikt, neemt de snelheid van de interne cache van de eiken toe naarmate de lengte van de rijen toeneemt. Deze correlatie kan gezien worden in een verhoogde missRate voor de DocChildren in de cache Consolidated Cache Statistieken MBean.
Om te voorkomen dat de limieten van de waarnemingswachtrij worden overschreden, wordt aanbevolen:
- Verlaag de constante snelheid van komma's. Korte punten in vastleggingen zijn aanvaardbaar, maar de constante snelheid moet worden verlaagd.
- De grootte van de DiffCache zoals beschreven in Tips voor het afstemmen van prestaties > Mongo Storage Tuning > Documentcachegrootte.

Een vast herindexeringsproces identificeren en corrigeren identifying-and-remediating-a-stuck-re-indexing-process

Herindexering kan onder twee omstandigheden als "volledig vastzitten" worden beschouwd:

Het opnieuw indexeren is zeer langzaam, tot het punt waar geen significante vooruitgang in logboekdossiers betreffende het aantal getransformeerde knopen wordt gemeld.
- Bijvoorbeeld, als er geen berichten in de loop van een uur zijn, of als de vooruitgang zo langzaam is dat het een week of meer zal vergen om te beëindigen.
Opnieuw indexeren blijft vastzitten in een eindeloze lus als herhaalde uitzonderingen in de logbestanden verschijnen (bijvoorbeeld OutOfMemoryException) in de indexeringsthread. De herhaling van dezelfde uitzondering(en) in het logbestand geeft aan dat er wordt geprobeerd hetzelfde item herhaaldelijk te indexeren, maar dat dit probleem niet wordt opgelost.

Ga als volgt te werk om een vast opnieuw indexeringsproces te identificeren en te corrigeren:

Om de oorzaak van de vastgezette indexering te achterhalen, moeten de volgende gegevens worden verzameld:
- Verzamel 5 notulen van draadstortplaats, één draadstortplaats om de 2 seconden.
- FOUTOPSPORINGSNIVEAU en logboeken voor de kandidaten instellen.
  - org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate
  - org.apache.jackrabbit.oak.plugins.index.IndexUpdate
- Gegevens verzamelen van de async IndexStats MBean:
  - Navigeer naar AEM OSGi Webconsole>Main>JMX>IndexState>async
    
    of ga naar http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats
- Gebruiken de consolemodus van eak-run.jar om de details te verzamelen van wat er in het kader van de * bestaat /:async* node.
- Een lijst met controlepunten in de opslagplaats verzamelen met de CheckpointManager MBean:
  - AEM OSGi Webconsole>Main>JMX>CheckpointManager>listCheckpoints()
    
    of ga naar http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DSegment+node+store+checkpoint+management%2Ctype%3DCheckpointManager
Na het verzamelen van alle informatie die in Stap 1 wordt geschetst, begin AEM opnieuw.
- Het opnieuw opstarten van AEM kan het probleem oplossen in geval van een hoge gelijktijdige belasting (overloop van de waarnemingswachtrij of iets dergelijks).
- Als het probleem niet wordt opgelost door opnieuw opstarten, opent u een probleem met Adobe Klantenservice en verstrekt alle informatie die in Stap 1 wordt verzameld.

Het veilig aborteren van asynchrone re-indexering safely-aborting-asynchronous-re-indexing

Opnieuw indexeren kan veilig worden afgebroken (gestopt voordat het wordt voltooid) via het dialoogvenster async, async-reindexen f ulltext-async indexeringsstroken ( IndexStats bonen). Raadpleeg voor meer informatie de documentatie bij Apache Oak op Opnieuw indexeren afbreken. Houd er daarnaast rekening mee dat:

Het opnieuw indexeren van de eigenschappenindexen Lucene en Lucene kan worden afgebroken, omdat deze van nature asynchroon zijn.
Het opnieuw indexeren van de indexen van het Bezit van de Eik kan slechts worden geaborteerd als het re-indexeren via PropertyIndexAsyncReindexMBean.

Voer de volgende stappen uit om opnieuw indexeren veilig af te breken:

Identificeer de IndexStats MBean die de re-indexerende weg controleert die moet worden tegengehouden.
- Navigeer naar de juiste IndexStats MBean via de JMX-console door naar AEM OSGi Web Console>Main>JMX of https:// te gaan<host>:<port>/system/console/jmx (bijvoorbeeld http://localhost:4502/system/console/jmx)
- Open de IndexStats MBean op basis van het opnieuw indexeren pad dat u wilt stoppen ( async, async-reindex, of fulltext-async)
  - Om de aangewezen weg en zo de IndexStats MBean instantie te identificeren, bekijk het "async"bezit van de Indexen van het Eak. De eigenschap "async" bevat de naam van het pad: async, async-reindex, of fulltext-async.
  - De strook is ook beschikbaar door tot AEM Manager van de Index in de kolom "Async"toegang te hebben. Navigeer naar Operations>Diagnosis>Indexbeheer om Indexbeheer te openen.
De abortAndPause() de juiste IndexStats MBean.
Markeer de definitie van de eiken-index op de juiste wijze om te voorkomen dat de indexering wordt hervat wanneer de indexeringsstrook wordt hervat.
- Bij het opnieuw indexeren van een bestaand index, stel de eigenschap voor opnieuw indexeren in op false
  - /oak:index/someExistingIndex@reindex=false
- Of anders, voor een new index, ofwel:
  - De eigenschap type instellen op uitgeschakeld
    - /oak:index/someNewIndex@type=disabled
  - of verwijder de indexdefinitie volledig
Leg de wijzigingen vast in de opslagplaats wanneer deze zijn voltooid.
Ten slotte kunt u de asychrone indexering op de geaborteerde indexeringsstrook hervatten.
- In de IndexStats MBean die de abortAndPause() bevel in Stap 2, haalt het resume()gebruiken.

Langzaam opnieuw indexeren voorkomen preventing-slow-re-indexing

Het is aan te bevelen om tijdens stille periodes (bijvoorbeeld, niet tijdens een grote inhoudspen), en ideaal tijdens onderhoudsvensters opnieuw te indexeren wanneer AEM lading gekend en gecontroleerd is. Zorg er ook voor dat de herindexering niet plaatsvindt tijdens andere onderhoudsactiviteiten.

recommendation-more-help

6a71a83d-c2e0-4ce7-a6aa-899aa3885b56