Problemen met Oak-indexen oplossen troubleshooting-oak-indexes
Langzaam opnieuw indexeren slow-re-indexing
AEM intern herindexeringsproces verzamelt gegevens in de opslagplaats en slaat deze op in Oak-indexen ter ondersteuning van het opvragen van inhoud door uitvoerders. 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 onredelijk 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. Het duurt dus langer om grote productieopslagplaatsen opnieuw te indexeren dan kleine opslagplaatsen.
Zie Beste praktijken op Vragen en het Indexerenvoor extra informatie over wanneer en hoe te om inhoud opnieuw te indexeren.
Aanvankelijke detectie initial-detection
Voor een trage indexering van de eerste detectie moet de IndexStats
JMX MBans worden gecontroleerd. Ga als volgt te werk voor de betreffende AEM instantie:
-
Open de Console van het Web en klik het lusje JMX of ga naar https://<host>:<port>/system/console/jmx (bijvoorbeeld, http://localhost:4502/system/console/jmx).
-
Navigeer naar de
IndexStats
mbeans. -
Open de
IndexStats
MBans voor "async
" en "fulltext-async
". -
Voor beide MBeans, controleer als Gedaan timestamp en LastIndexTime timestamp minder dan 45 min van de huidige tijd zijn.
-
Voor één van beide MBean, als de tijdwaarde (Gedaan of LastIndexedTime) groter is dan 45 min van de huidige tijd, dan ontbreekt de indexbaan of neemt te lang. Dit probleem veroorzaakt de asynchrone indexen om stabiel te zijn.
De indexering wordt gepauzeerd na een gedwongen sluiting indexing-is-paused-after-a-forced-shutdown
Een gedwongen sluiting resulteert in AEM het opschorten van asynchrone indexering tot 30 minuten na het opnieuw beginnen. En, vereist het typisch een andere 15 minuten om de eerste het opnieuw indexeren pas te voltooien, voor een totaal van ongeveer 45 minuten (het binden terug naar Begeleidende Chronologie van de Opsporingvan 45 minuten). Als indexeren wordt gepauzeerd na een gedwongen sluiting:
-
Bepaal eerst of de AEM instantie geforceerd is afgesloten (het AEM proces is met kracht gedood of er is een stroomstoring opgetreden) en begin later opnieuw.
- AEM het registrerenkan voor dit doel worden herzien.
-
Als de gedwongen sluiting optrad, na het opnieuw opstarten, AEM automatisch het opnieuw indexeren gedurende maximaal 30 minuten op.
-
Wacht ongeveer 45 minuten op AEM om normale asynchrone indexeringsverrichtingen te hervatten.
Thread pool overloaded thread-pool-overloaded
In uitzonderlijke omstandigheden, kan de draadpool die wordt gebruikt om asynchrone indexering te beheren overbelast worden. Om het het indexeren proces te isoleren, kan een draadpool worden gevormd om ander AEM werk te verhinderen zich in het vermogen van Oak te mengen om inhoud op geschikte wijze te indexeren. Voer in dergelijke gevallen de volgende handelingen uit:
-
Definieer een nieuwe, geïsoleerde draadpool voor de Apache Sling Scheduler voor asynchrone indexering:
- Voor de beïnvloede AEM instantie, navigeer aan AEM OSGi 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".
- Om de veranderingen te bewaren, klik sparen in het bodem-recht.
-
Controleer of de nieuwe Apache Sling Scheduler-thread-pool is geregistreerd en wordt weergegeven in de webconsole van Apache Sling Scheduler-status.
-
Navigeer aan de AEM OSGi Webconsole>Status>Sling Planner of ga naar https://<host>:<port>/system/console/status-slingplanner (bijvoorbeeld, http://localhost:4502/system/console/status-slingscheduler)
-
Controleer of de volgende poolitems aanwezig zijn:
- ApacheSlingoak
- ApacheSlingdefault
-
De waarnemingswachtrij is vol observation-queue-is-full
Als er te veel veranderingen en verplichtingen in korte tijd aan de gegevensopslagplaats worden aangebracht, kan de indexering worden vertraagd vanwege een volledige waarnemingswachtrij. Bepaal eerst of de waarnemingswachtrij vol is:
-
Ga naar de Console van het Web en klik het JMX lusje of ga naar https://<host>:<port>/system/console/jmx (bijvoorbeeld, http://localhost:4502/system/console/jmx)
-
Open Oak Repository Statistics MBean en bepaal of een
ObservationQueueMaxLength
-waarde groter is dan 10.000.- Bij normale bewerkingen moet deze maximumwaarde uiteindelijk altijd tot nul worden gereduceerd (vooral in de sectie
per second
), zodat wordt gecontroleerd of de waarden voor seconden vanObservationQueueMaxLength
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 Oak-cache af naarmate de lengte van de wachtrij groter wordt. Deze correlatie is zichtbaar in een toename
missRate
voor deDocChildren
cache in deConsolidated Cache
statistics MBean.
- Bij normale bewerkingen moet deze maximumwaarde uiteindelijk altijd tot nul worden gereduceerd (vooral in de sectie
-
Om te voorkomen dat de limieten van de waarnemingswachtrij worden overschreden, wordt aanbevolen:
- Verlaag de constante snelheid van komma's. Korte pieken in vastleggingen zijn aanvaardbaar, maar de constante snelheid moet worden verlaagd.
- Verhoog de grootte van
DiffCache
zoals die in Prestaties het stemmen uiteinden > Mongo Opslag het Tunnen > de geheim voorgeheugengrootte van het Documentwordt beschreven.
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 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 duurt om te beëindigen.
-
Het 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 een of meer uitzonderingen in het logbestand geeft aan dat Oak probeert 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 repareren:
-
Om de oorzaak van het vastlopen van indexering te identificeren, moet de volgende informatie worden verzameld:
-
Verzamel 5 notulen van draadstortplaats, één draadstortplaats om de 2 seconden.
-
plaats FOUTOPSPORINGSniveau en logboeken voor de toevoegers.
- 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
-
-
De consolemodus van het gebruik eak-run.jarom de details van te verzamelen wat onder de *
/:async
* knoop bestaat. -
Verzamel een lijst met controlepunten in de opslagplaats met behulp van
CheckpointManager
MBean:-
AEM OSGi Webconsole>Main>JMX>CheckpointManager>listCheckpoints()
-
-
-
Na het verzamelen van alle informatie die in Stap 1 wordt geschetst, begin AEM opnieuw.
- Het opnieuw opstarten van AEM kan het probleem oplossen als er een hoge gelijktijdige belasting is (overloop van de waarnemingswachtrij of iets dergelijks).
- Als een nieuw begin niet het probleem oplost, open een kwestie met de Zorg van de Klant van de Adobeen verstrekt alle informatie die in Stap 1 wordt verzameld.
Asynchrone herindexering veilig afbreken safely-aborting-asynchronous-re-indexing
Opnieuw indexeren kan veilig worden afgebroken (gestopt voordat het wordt voltooid) via de async, async-reindex
- en f ulltext-async
-indexbanen ( IndexStats
-boon). Voor meer informatie, zie ook de documentatie van Apache Oak op hoe te Reindexingafbreken. Overweeg ook het volgende:
- Het opnieuw indexeren van de indexen van het Bezit van Lucene en van Lucene kan worden geaborteerd aangezien zij van nature asynchroon zijn.
- Het opnieuw indexeren van Oak-eigenschappenindexen kan alleen worden afgebroken als opnieuw indexeren is gestart via de
PropertyIndexAsyncReindexMBean
.
Voer de volgende stappen uit om opnieuw indexeren veilig af te breken:
-
Identificeer de IndexStats MBean die de het opnieuw indexeren weg controleert die moet worden tegengehouden.
-
Navigeer aan aangewezen IndexStats MBean via de console JMX door of AEM Console OSGi Web>Main>JMX of https://<host> te gaan:<port>/system/console/jmx (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
, offulltext-async
)- Om de aangewezen weg en zo de IndexStats MBean instantie te identificeren, bekijk het "async"bezit van de Indexen van Oak. De eigenschap "async" bevat de naam van het pad:
async
,async-reindex
offulltext-async
. - De strook is ook beschikbaar door tot de Manager van de Index van AEM toegang te hebben in de kolom "Async". Navigeer naar Operations>Diagnosis>Indexbeheer om Indexbeheer te openen.
- Om de aangewezen weg en zo de IndexStats MBean instantie te identificeren, bekijk het "async"bezit van de Indexen van Oak. De eigenschap "async" bevat de naam van het pad:
-
-
Roep de opdracht
abortAndPause()
aan op de juisteIndexStats
MBean. -
Markeer de Oak-indexdefinitie op de juiste wijze om te voorkomen dat het indexeren van de rijstrook wordt hervat.
-
Wanneer het opnieuw indexeren van een bestaande index, plaats het herindexbezit aan vals
/oak:index/someExistingIndex@reindex=false
-
Of anders, voor a nieuwe 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.
-
-
Tot slot hervat asynchrone indexering op de geaborteerde indexerende weg.
- In
IndexStats
MBean die hetabortAndPause()
bevel in Stap 2 uitgeeft, haal hetresume()
bevel aan.
- In
Langzaam opnieuw indexeren voorkomen preventing-slow-re-indexing
Het is het beste om opnieuw te indexeren tijdens rustige perioden (bijvoorbeeld niet tijdens een grote inname van inhoud), en idealiter tijdens onderhoudsvensters wanneer AEM lading bekend en gecontroleerd is. Zorg er ook voor dat de herkoppeling niet plaatsvindt tijdens andere onderhoudsactiviteiten.