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.
De eerste detectie trage indexering vereist het evalueren van IndexStats
JMX MBans. 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).
Navigeer naar IndexStats
Monen.
Open IndexStats
MBans voor " async
"en " fulltext-async
".
Voor beide MBeans, controleer als Done timestamp en LastIndexTime timestamp minder dan 45 minuten van de huidige tijd zijn.
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.
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:
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.
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.
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:
Definieer een nieuwe, geïsoleerde draadpool voor de Apache Sling Scheduler voor asynchrone indexering:
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 Web console>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:
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 MBean van de Bewaarplaats van de Eak en bepaal als om het even welke ObservationQueueMaxLength
waarde groter is dan 10.000.
per second
), zodat wordt gecontroleerd of de waarden voor de seconden van ObservationQueueMaxLength
0 zijn.missRate
voor het DocChildren
geheime voorgeheugen in Consolidated Cache
statistieken MBean.Om te voorkomen dat de limieten van de waarnemingswachtrij worden overschreden, wordt aanbevolen:
DiffCache
zoals beschreven in Tips voor het afstemmen van prestaties > Afstemmen van Mongo Storage > Grootte van documentcache.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.
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:
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.
Stel het FOUTOPSPORINGSniveau en de logboeken voor de appanten in.
Verzamel gegevens van async IndexStats
MBean:
Navigeer naar AEM OSGi Webconsole>Main>JMX>IndexState>async
Gebruik de consolemodus van eak-run.jar om de details van te verzamelen wat onder de knoop * /:async
* bestaat.
Verzamel een lijst met controlepunten in de opslagplaats door CheckpointManager
MBean te gebruiken:
AEM OSGi Webconsole>Main>JMX>CheckpointManager>listCheckpoints()
Na het verzamelen van alle informatie die in Stap 1 wordt geschetst, begin AEM opnieuw.
Opnieuw indexeren kan veilig worden afgebroken (gestopt voordat het wordt voltooid) via async, async-reindex
en 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:
PropertyIndexAsyncReindexMBean
werd geïnitieerd.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://<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
)
async
, async-reindex
of fulltext-async
.Roep de opdracht abortAndPause()
op de juiste IndexStats
MBean aan.
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.
Tot slot hervat asychronous indexing on the aborted indexing lane.
IndexStats
MBean die abortAndPause()
bevel in Stap 2 uitgeeft, haal resume()
bevel aan.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.