Documentatie

Gemeenschappelijke kritieke AEM-problemen analyseren

Last update: Tue Oct 14 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Meer informatie over de meest voorkomende kritieke AEM-problemen en hoe u deze kunt analyseren.

Beschrijving description

Omgeving

Adobe Experience Manager (AEM)

Probleem/symptomen

In dit artikel worden de meest voorkomende kritieke AEM-problemen beschreven en beschreven hoe u deze kunt analyseren.

  • AEM Sites-prestaties
  • AEM Assets-prestaties
  • Geheugenproblemen
  • Indexeringsproblemen
  • Replicatieproblemen
  • TarMK-corruptieproblemen

Resolutie resolution

AEM Sites-prestatieproblemen

Symptomen van een prestatieskwestie

  1. Langzaam laden van pagina's
  2. Langzaam maken of bewerken van pagina's
  3. AEM-responstijden zijn traag
  4. AEM reageert niet op bepaalde verzoeken
  5. De request.log on AEM geeft een lange responstijd weer

wat prestatieskwesties veroorzaakt

  1. Bezwaar van de draad: Lange lopende verzoeken zoals langzame onderzoeken, schrijven-zware achtergrondbanen, het bewegen van volledige takken van plaatsinhoud, etc.
  2. Hoog CPU-gebruik
  3. Duurzame verzoeken zoals dure zoekopdrachten of inefficiënte toepassingscode, componenten, enz.
  4. Gebrek aan behoorlijk onderhoud
  5. Onvoldoende caching van de verzender
  6. Geen CDN
  7. Geen caching browser
  8. Te veel scripts die op de pagina zijn geladen en boven aan de pagina zijn geladen
  9. CSS geladen door pagina in plaats van in de HTML-kop
  10. Onvoldoende serverformaat of onjuiste architectuur
  11. Geheugenproblemen (zie hieronder)

hoe te om de prestatieskwestie te analyseren

  1. ​ Vang een reeks draaddumps ​ en ​ analyseert hen ​.

  2. Schakel op het niveau van het besturingssysteem in als het AEM-Java-proces een hoge CPU-benutting veroorzaakt: als AEM een hoog CPU-gebruik veroorzaakt, voert u het hulpprogramma voor het maken van profielen een paar minuten uit en analyseert u het resultaat.

    • Linux: gebruik de bovenste opdracht om het gebruik van CPU te controleren.
    • Venster: Windows Taakbeheer gebruiken

  3. ​ analyseert het request.log dossier voor om het even welke langzame verzoeken ​.

  4. Controleer uw procedures voor systeemonderhoud. Zie dit ​ artikel ​ voor details op het onderhoud van AEM en zorg ervoor dat u behoorlijk onderhoud op AEM met inbegrip van doet:

    • Revision Clean Up (alleen MongoMK en Database DocumentNodeStore) - dagelijks of vaker
    • Offlinetar-compressie (alleen TarMK) - twee weken
    • Opschoonfunctie voor gegevensopslag (alleen systemen met FileDataStore of S3 DataStore) - wekelijks
    • Werkstroom leegmaken - wekelijks
    • Versie wissen - wekelijks
    • AuditLog Leegmaken - wekelijks

  5. Herzie in het voorgeheugen onderbrengende strategieën die op het ​ niveau van de AEM verzender ​ worden uitgevoerd.

  6. Herzie ​ caching van uw plaats ​.

  7. De cliënt-zijhulpmiddelen van de plaatsanalyse van het gebruik zoals de eigenschap van Audits in browser van Google Chrome de hulpmiddelen van de Ontwikkelaar paneel. Deze hulpmiddelen zullen u aanbevelingen op cliënt-zijprestatiesverbeteringen geven.

Oplossingen aan gemeenschappelijke prestatieskwesties

Assets-prestatieproblemen

Symptomen van een de prestatieskwestie van Assets

  • Trage bestandsuploads naar /assets.html of /damadmin-interface
  • Het genereren van miniaturen duurt te lang
  • Assets-bewerkingen zoals verplaatsen, verwijderen, bewerken en bijwerken van metagegevens duurt te lang

wat veroorzaakt kwesties met de prestaties van Assets

  • Gebrek aan behoorlijk onderhoud
  • Laatste fix-pakketten niet toegepast
  • Optimalisatie niet toegepast
  • Onvoldoende serverzijd voor het laden van de gebruiker

hoe te om de de prestatieskwestie van Assets te analyseren

Oplossingen aan gemeenschappelijke de prestatieskwesties van Assets

Geheugenproblemen

Symptomen van een geheugenkwestie

  • AEM crasht willekeurig en in de logoutOfMemoryError wordt waargenomen
  • AEM wordt langzamer in de tijd en loopt uiteindelijk vast
  • AEM reageert niet

het Diagnose van een geheugenkwestie

  • Zoek in de logbestanden naar OutOfMemoryError als er overeenkomende bestanden zijn, dan is er een geheugenprobleem

  • Herzie http://aem-gastheer:port/system/console/memoryusage het scherm

    Als het gebruik van de "Oude Generatie" (JDK 7 en eerder) of "Gehuurde Generatie" (JDK8 of later) hoog is, kan dit een teken zijn van een probleem met het heapgeheugengebruik. Klik op "Afvalophaling uitvoeren" om de JVM te vragen een volledige heap-afvalophaling uit te voeren. Als het hoge heapgebruik hoog blijft na het aanvragen van GC, is er waarschijnlijk een probleem. Op een AEM-exemplaar met Oak Tar-opslagruimte kan er een probleem optreden als het aanbevolen gebruik hoger is dan 3 GB. Een hoog heapgebruik op een systeem met Mongo-opslag kan het gevolg zijn van de cacheconfiguratie in het geheugen.

  • ​ neem draaddumps en hoogste output ​ en voer ​ draadanalyse ​ uit. Controleer of de threads die een hoog CPU-gebruik veroorzaken, native JVM Garbage Collection-threads zijn. Als de draad die de meeste tijd van CPU gebruikt de "Draad van VM"of om het even welke vuilnisthreads zijn, dan is er waarschijnlijk een geheugenkwestie.

wat geheugenkwesties veroorzaakt

  • Geheugenlek van Java-toepassing
  • Java Finalizer stapelt omhoog vanwege onjuist gebruik van finalizing in aangepaste code
  • Onvoldoende maximale heapconfiguratie

hoe te om de oorzaak van uw geheugenkwestie te analyseren

Zie ​ dit artikel ​ voor details op hoe te om een heapstortplaats te vangen.

De beste manier om de oorzaak van een geheugenkwestie te identificeren is een heapstortplaats te analyseren.

Zodra u een dossier van de Dumpel van de Hap dan het in ​ MAT van de Verduistering ​ of ​ het hulpmiddel van de Analysator van het Geheugen van IBM ​ hebt gevangen. Voer in Eclipse MAT het rapport Leak Suspects uit en open de weergave "Thread Details" om mogelijke oorzaken voor het geheugenprobleem te zien.

Oplossingen aan gemeenschappelijke geheugenkwesties

  • Optimaliseer uw toepassingscode om minder geheugen te gebruiken als u lange huisvuilinzameling merkt pauzeert. De meeste problemen met afvalophaling kunnen het best worden opgelost door de toepassing te optimaliseren in plaats van de JVM af te stemmen.
  • Als u reeds uw toepassing hebt geoptimaliseerd en nog lange GC ervaren pauzes dan ​ nadruk op het stemmen van JVM ​.

AEM Indexing Issue

Symptomen van het indexeren kwesties

Hieronder ziet u tekenen van een uitgave met AEM/Oak-indexering:

  • Zoekresultaten zijn meer dan 10 minuten verouderd
  • Er ontbreken zoekresultaten
  • Fouten worden geretourneerd in de gebruikersinterface of in de logbestanden tijdens het zoeken via de gebruikersinterface van de site, zoekopdracht in Query Builder of uitvoering van JCR-query

het Diagnose een indexeren kwestie

Ga als volgt te werk om te zien of asynchrone indexering traag of mislukt:

  1. Open deze URLs op uw instantie van AEM om statistieken over Async indexer te bekijken: http://aemhost:port /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%3Ctype%3DIndexStats http://aemhost:port /system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats - Deze URL is slechts op van toepassing AEM6.2 en hoger

  2. Controleer op elk van deze pagina's de volgende velden:

    FailingSince - dit wijst op wanneer het indexeren eerst begon te ontbreken.

    LastError - dit is het stapelspoor dat toont wat indexeren om veroorzaakt te ontbreken. Als dit leeg is, mislukt het indexeren niet.

    LastErrorTime - dit wijst op de laatste tijd het indexeren de fout wierp.

    LastIndexedTime - als de datum en de tijd van dit gebied meer dan 5 minuten oud zijn dan het indexeren te langzaam loopt.

wat veroorzaakt kwesties met het indexeren

  • Onjuist onderhoud of geen onderhoud, zoals Revision Garbage Collection, Workflow Purge, Audit Purge, Version Purge, enz.
  • Beschadigde of ontbrekende segmenten in Tar-opslag
  • Revision Corruption in a clustered environment (DocumentNodeStore - Mongo of Database)
  • Een kwestie met de clustertopologie in een gegroepeerd milieu

hoe te analyseren wat het indexeren kwesties veroorzaakt

Replicatieproblemen

Symptomen van de Kwesties van de Replicatie

  • Publicatieverzoeken worden in de wachtrij met replicatieagents in een wachtrij geplaatst
  • De gepubliceerde inhoud wordt niet weergegeven op de publicatieserver
  • Gevolgen voor de systeemprestaties

wat de kwesties van de Replicatie veroorzaakt:

  • De agent van de replicatie is misconfigured en kan niet met publiceren agent verbinden
  • Er is een fout op het tijdstip van replicatie die de replicatierij ertoe brengt vast te komen
  • Het systeem is traag en replicaties worden langzaam uitgevoerd
  • De replicatie vindt plaats als onderdeel van een aangepaste workflow en het probleem is met workflowverwerking.

hoe te om de kwesties van de Replicatie te analyseren:

  1. Controleer de status van de replicatierij 🔗:

    Actief: wanneer de punten worden verwerkt.

    Nutteloos: wanneer de rij leeg is.

    Geblokkeerd: wanneer de punten in de rij zijn, maar niet kunnen worden verwerkt; bijvoorbeeld, wanneer de agent aan een gastheer richt die neer of niet-bestaand is.

  2. Herzie de replicatieconfiguraties als uw server wordt gekloond of de agent onlangs is gevormd. Voor details, zie ​ hier ​.

  3. Herzie de logboeken van de replicatieagent in http://host :port /etc/replication/agents.author/AgentName.log.html#end . Als u geen items kunt identificeren, verzamelt u dit logboek en presenteert u dit aan de ondersteuning van AEM.

  4. Herzie server error.log van AEMinstall/crx-quickstart/logs ; Als u geen punten kunt identificeren verzamelt dit logboek en presenteert aan de steun van AEM.

  5. Als de replicatierij in "nutteloze"staat is en geen van bovenstaande van toepassing is, in dit geval wordt het probleem zeer waarschijnlijk veroorzaakt door de werkschema's. Als de werkschema's niet worden verwerkt dan krijgt het replicatiepunt nooit aan de replicatierij. Om de status van uw workflows te controleren, kunt u het werkstroomdashboard controleren om het aantal actieve werkschemainstanties te controleren. U kunt over het beheren van werkschema's ​ hier ​ lezen.

  6. Replicaties vertragen wanneer het systeem zwaar wordt belast of andere prestatieproblemen ondervindt.

Oplossing aan Gemeenschappelijke kwesties van de Replicatie:

  1. ​ herzie de de rijkwesties van de Replicatie ​.
  2. Als het probleem toe te schrijven is aan de werkschema's die efficiënt niet lopen, kunt u de gezamenlijke ​ uiteinden van de werkschemaverwerking ​ herzien.

TarMK-corruptieproblemen

Symptomen van Corruptie TarMK

  • Instantie werkt niet meer na offlinecompressie.
  • Instantie die in wordt geplakt Opstarten in lopende staat.
  • De dossiers van het logboek of van het samenstellingsbevel outputrapport SegmentNotFoundException .

wat corruptiekwesties veroorzaakt

  • Het segment wordt door manuele tussenkomst verwijderd (bv. rm-rf).
  • Het segment wordt verwijderd door de inzameling van het revisiehuisvuil of het segment kan niet wegens één of andere insect in de code worden gevonden.
  • Het segment kan niet worden gevonden wegens een fout in de code.
  • Verschillende onderhoudstaken worden niet uitgevoerd op tijd, wat leidt tot groei van de opslagplaats en een lage schijfruimte.
  • AEM krachtig stoppen door het java-proces te doden.

het diagnostiseren van de gegevensopslagplaats corruptiekwesties:

  • Herzie het error.log dossier en controleer als er SegmentNotFoundException of Uitzondering IllegalArgument is.
  • Om te bepalen of een segment door de inzameling van het revisiehuisvuil is verwijderd, controleer de output van org.apache.jackrabbit.eak.plugins.segment.file.TarReader-GC (laat zuiveringslogboek) registreerapparaat toe. Dat registreerapparaat registreert segmentids van alle segmenten die door de schoonmaakbeurt fase worden verwijderd. Slechts wanneer beledigende segmentidentiteitskaart in de output van dat registreerapparaat verschijnt is de inzameling van het revisiehuisvuil de oorzaak voor de uitzondering.
  • In geval van corruptie in externe datastore, voorkwam het dossier van het onderzoekslogboek voor alle voorkomen van fout Fout terwijl het verkrijgen van InputStream voor blobId . Deze fout houdt in dat er bestanden ontbreken in de map AEM datastore.

Oplossing om corruptiekwesties te herstellen:

  • Bepaal de laatste bekende goede revisie van de segmentopslag door de ​ controle ​ run-mode van eiken-looppas te gebruiken. Herstel handmatig de laatste goede revisie van de beschadigde segmentopslag. Met deze bewerking wordt de Oak-opslagplaats teruggezet naar een eerder tijdstip. Maak een volledige back-up van de opslagplaats voordat u deze bewerking uitvoert.

  • Als u geen datastore gebruikt, dan gebruik een extern dossier, S3 of Azure datastore, in plaats van standaard segmentstore.

    • Het gebruik van een datastore biedt betere prestaties.
    • Migreer de instantie aan met een datastore gebruikend ​ crx2oak ​.

  • Pas het nieuwste Service Pack en Cumulative Fix Pack toe en Oak Cumulative Fix Pack.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f