Probleemoplossing voor oak-indexen

Langzaam opnieuw indexeren

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 Beste praktijken op Vragen en het Indexeren voor extra informatie over wanneer en hoe te om inhoud opnieuw te indexeren.

Eerste detectie

De eerste detectie trage indexering vereist het evalueren van IndexStats JMX MBans. Ga als volgt te werk voor de betreffende AEM instantie:

  1. 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).

  2. Navigeer naar IndexStats Monen.

  3. Open IndexStats MBans voor " async"en " fulltext-async".

  4. Voor beide MBeans, controleer als Done timestamp en LastIndexTime timestamp minder dan 45 minuten van de huidige tijd zijn.

  5. Voor één van beide MBean, als de tijdwaarde (Done of LastIndexedTime) groter is 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

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

  1. 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 loggingingkan voor dit doel worden herzien.

  2. Als de gedwongen sluiting optrad, na opnieuw beginnen, AEM automatisch het opnieuw indexeren voor maximaal 30 minuten opschort.

  3. Wacht ongeveer 45 minuten op AEM om normale asynchrone indexeringsverrichtingen te hervatten.

Te veel thread pool

OPMERKING

Voor AEM 6.1 moet AEM 6.1 GFP 11 zijn 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:

  1. 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.

    chlimage_1-119

  2. Controleer of de nieuwe Apache Sling Scheduler-thread-pool is geregistreerd en wordt weergegeven in de Apache Sling Scheduler-webconsole.

    chlimage_1-120

De waarnemingswachtrij is vol

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:

  1. 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)

  2. Open de Statistieken MBean van de Bewaarplaats van de Eak en bepaal als om het even welke ObservationQueueMaxLength waarde groter is dan 10.000.

    • Bij normale bewerkingen moet deze maximumwaarde uiteindelijk altijd tot nul worden teruggebracht (met name in de sectie per second), zodat wordt gecontroleerd of de waarden voor de seconden van ObservationQueueMaxLength 0 zijn.
    • 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 worden gezien in een verhoogde missRate voor het DocChildren geheime voorgeheugen in Consolidated Cache statistieken MBean.

  3. Om te voorkomen dat de limieten van de waarnemingswachtrij worden overschreden, wordt aanbevolen:

Een vast opnieuw indexeringsproces identificeren en corrigeren

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 in een eindeloze lijn hangen als de herhaalde uitzonderingen in de logboekdossiers (bijvoorbeeld, OutOfMemoryException) in de het indexeren draad verschijnen. 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:

  1. Om de oorzaak van de vastgezette indexering te achterhalen, moeten de volgende gegevens worden verzameld:

  2. 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 een nieuw begin het probleem niet oplost, open een kwestie met Adobe de Zorg van de Klant en verstrek alle informatie die in Stap 1 wordt verzameld.

asynchrone re-indexering veilig afbreken

Opnieuw indexeren kan veilig worden afgebroken (gestopt voordat het wordt voltooid) via async, async-reindexen f ulltext-async indexbanen ( IndexStats bonen). Raadpleeg voor meer informatie de documentatie bij Apache Oak op How to Abort Reindexing. 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 werd geïnitieerd.

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

  1. 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://<host>:<port>/system/console/jmx te gaan (bijvoorbeeld http://localhost:4502/system/console/jmx)

    • Open de IndexStats MBean op basis van de opnieuw indexerende weg die u wilt tegenhouden ( 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.

    chlimage_1-121

  2. Roep de opdracht abortAndPause() op de juiste IndexStats MBean aan.

  3. 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 bestaande index, plaats het herindexbezit aan vals

      • /oak:index/someExistingIndex@reindex=false

    • Of anders, voor een new index, of:

      • 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.

  4. Tot slot hervat asychronous indexing on the aborted indexing lane.

    • In IndexStats MBean die abortAndPause() bevel in Stap 2 uitgeeft, haal resume()bevel aan.

Traag opnieuw indexeren voorkomen

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.

Op deze pagina