AEM interna omindexeringsprocess samlar in databasdata och lagrar dem i Oak-index för att ge stöd för prestandafrågor. I undantagsfall kan processen bli långsam eller till och med fastna. Den här sidan fungerar som en felsökningsguide som hjälper dig att identifiera om indexeringen är långsam, hitta orsaken och lösa problemet.
Det är viktigt att skilja mellan omindexering som tar en otillräckligt lång tid och omindexering som tar lång tid eftersom det indexerar enorma mängder innehåll. Den tid det tar att indexera innehåll skalas till exempel med mängden innehåll, så stora produktionsdatabaser tar längre tid att indexera om än små utvecklingsdatabaser.
Mer information om när och hur du indexerar om innehåll finns i Bästa praxis för frågor och indexering.
Inledande identifiering av långsam indexering kräver granskning av JMX MBeans för IndexStats
. Gör följande på den påverkade AEM:
Öppna webbkonsolen och klicka på fliken JMX eller gå till https://<värd>:<port>/system/console/jmx (t.ex. http://localhost:4502/system/console/jmx).
Navigera till menyerna IndexStats
.
Öppna IndexStats
MBeans för async
och fulltext-async
.
För båda MBeans ska du kontrollera om tidsstämpeln Done och LastIndexTime är mindre än 45 minuter från den aktuella tiden.
Om tidsvärdet (Done eller LastIndexedTime) är större än 45 minuter från den aktuella tiden i MBean misslyckas indexjobbet eller tar för lång tid. Detta gör att asynkrona index blir inaktuella.
En framtvingad avstängning resulterar i AEM att asynkron indexering avbryts i upp till 30 minuter efter omstarten och kräver normalt ytterligare 15 minuter för att slutföra den första omindexeringsprocessen, i totalt cirka 45 minuter (återkoppling till tidsramen Inledande detektion på 45 minuter). Om du misstänker att indexering har pausats efter en tvingad avstängning:
För det första ska du avgöra om AEM stängdes av på ett tvingat sätt (den AEM processen tvångsdödades eller ett strömavbrott inträffade) och därefter starta om.
Om den framtvingade avstängningen inträffar kommer AEM automatiskt att avbryta omindexering i upp till 30 minuter vid omstart.
Vänta ca 45 minuter tills AEM återupptar vanliga asynkrona indexeringsåtgärder.
För AEM 6.1 kontrollerar du att AEM 6.1 CFP 11 är installerat.
I undantagsfall kan den trådpool som används för att hantera asynkron indexering bli överbelastad. För att isolera indexeringsprocessen kan en trådpool konfigureras för att förhindra att andra AEM stör Oaks förmåga att indexera innehåll i tid. För att göra detta bör du:
Definiera en ny isolerad trådpool för Apache Sling Scheduler som ska användas för asynkron indexering:
Kontrollera att den nya trådpoolen för Apache Sling Scheduler är registrerad och visas i webbkonsolen för Apache Sling Scheduler Status.
Gå till AEM OSGi Web console>Status>Sling Scheduler eller gå till https://<port>/system/console/status-slingscheduler (t.ex. http://localhost:4502/system/console/status-slingscheduler)
Kontrollera att följande poolposter finns:
Om för många ändringar och implementeringar görs i databasen på kort tid kan indexeringen fördröjas på grund av en fullständig observationskö. Börja med att fastställa om observationskön är full:
Gå till webbkonsolen och klicka på fliken JMX eller gå till https://<värd>:<port>/system/console/jmx (t.ex. http://localhost:4502/system/console/jmx)
Öppna MBean för Oak-databasstatistik och kontrollera om något ObservationQueueMaxLength
-värde är större än 10 000.
per second
) så verifiera att sekundmåtten för ObservationQueueMaxLength
är 0.missRate
för cachen DocChildren
i MBean för Consolidated Cache
-statistik.För att undvika att överskrida tillåtna gränser för observationsköer bör du:
DiffCache
enligt beskrivningen i Prestandajusteringstips > Justering av monolagring > Dokumentcache-storlek.Omindexering kan betraktas som"helt fast" under två förhållanden:
Omindexeringen är mycket långsam, till den punkt där inga större framsteg rapporteras i loggfiler om antalet noder som har gått igenom.
Omindexering fastnar i en oändlig slinga om upprepade undantag förekommer i loggfilerna (till exempel OutOfMemoryException
) i indexeringstråden. Upprepningen av samma undantag i loggen anger att Oak försöker indexera samma sak flera gånger, men misslyckas i samma problem.
Så här identifierar och korrigerar du en fast omindexeringsprocess:
För att identifiera orsaken till den fastande indexeringen måste följande information samlas in:
Samla 5 minuters tråddump, en tråddump varannan sekund.
Ange DEBUG-nivå och loggar för tilläggen.
Samla in data från asynkrona IndexStats
MBean:
Navigera till AEM OSGi Web Console>Main>JMX>IndexStat>async
eller gå till http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats
Använd oak-run.jar konsolläge för att samla in information om vad som finns under noden * /:async
*.
Samla in en lista med databaskontrollpunkter med hjälp av CheckpointManager
MBean:
AEM OSGi Web Console>Main>JMX>CheckpointManager>listCheckpoints()
När du har samlat in all information som beskrivs i steg 1 startar du om AEM.
Omindexering kan avbrytas (stoppas innan den är klar) via indexeringsfälten async, async-reindex
och f ulltext-async
( IndexStats
Mbean). Mer information finns också i dokumentationen för Apache Oak om Så här avbryter du omindexering. Ta dessutom hänsyn till att
PropertyIndexAsyncReindexMBean
.Så här avbryter du omindexering:
Identifiera det IndexStats MBean som styr det omindexeringsintervall som behöver stoppas.
Navigera till rätt IndexStats MBean via JMX-konsolen genom att antingen gå till AEM OSGi Web Console>Main>JMX eller https://<host>:<port>/system/console/jmx (t.ex. http://localhost:4502/system/console/jmx)
Öppna IndexStats MBean baserat på det omindexeringsfält som du vill stoppa ( async
, async-reindex
eller fulltext-async
)
async
, async-reindex
eller fulltext-async
.Anropa kommandot abortAndPause()
på lämpligt IndexStats
MBean.
Markera indexdefinitionen på ekv för att förhindra att indexeringen återupptas när indexeringsintervallet återupptas.
När du indexerar om ett befintligt-index ska du ange egenskapen reindex till false
/oak:index/someExistingIndex@reindex=false
Eller, för ett nytt-index, antingen:
Ange att type-egenskapen ska vara inaktiverad
/oak:index/someNewIndex@type=disabled
eller ta bort indexdefinitionen helt
Genomför ändringarna i databasen när de är klara.
Slutligen kan du återuppta asynkron indexering på det avbrutna indexeringsfältet.
resume()
i det IndexStats
MBean som utfärdade kommandot abortAndPause()
i steg 2.Det är bäst att indexera om under tysta perioder (t.ex. inte under en stor innehållsimport) och helst under underhållsperioder när AEM är känd och kontrollerad. Se även till att omindexeringen inte sker under andra underhållsaktiviteter.