Dokumentation

Hur man analyserar viktiga AEM-problem

Last update: Fri Sep 12 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Lär dig mer om de vanligaste allvarliga AEM-problemen och hur du analyserar dem.

Beskrivning description

Miljö

Adobe Experience Manager (AEM)

Problem/symtom

I den här artikeln beskrivs de vanligaste allvarliga AEM-problemen och hur du analyserar dem.

  • AEM Sites prestanda
  • AEM Assets prestanda
  • Minnesproblem
  • Indexeringsproblem
  • Replikeringsproblem
  • TjärMK-fel

Upplösning resolution

AEM Sites Performance Issues

Symtomen på ett prestandaproblem

  1. Långsam inläsning av sidor
  2. Skapa och redigera sidor långsamt
  3. AEM svarstider är långsamma
  4. AEM svarar inte på vissa förfrågningar
  5. request.log på AEM visar långsamma svarstider

Vad orsakar prestandaproblem

  1. Trådkonflikt: Långa begäranden som långsamma sökningar, skrivkraftiga bakgrundsjobb, flyttning av hela grenar av webbplatsinnehåll osv.
  2. Hög CPU-användning
  3. Kostnadskrävande sökningar, ineffektiv programkod, komponenter osv.
  4. Brist på korrekt underhåll
  5. Otillräcklig cachelagring av dispatcher
  6. Brist på CDN
  7. Brist på webbläsarcachning
  8. För många skript har lästs in på sidan och lästs in överst på sidan
  9. CSS inläst på hela sidan i stället för i HTML
  10. Otillräcklig serverstorlek eller felaktig arkitektur
  11. Minnesproblem (se nedan)

Analysera prestandaproblemet

  1. Hämta en serie tråddumpar och analysera dem.

  2. Kontrollera på operativsystemsnivå om AEM java-processen ger hög användning av CPU: Om AEM ger hög användning av CPU kör du det körklara profileringsverktyget i några minuter och analyserar resultatet.

    • Linux: använd det översta kommandot för att kontrollera användningen av CPU.
    • Fönster: använd Aktivitetshanteraren

  3. Analysera filen request.log för eventuella långsamma begäranden.

  4. Granska underhållsrutinerna. I den här artikeln finns mer information om AEM-underhåll och information om hur du utför korrekt underhåll på AEM:

    • Rensa Revision (endast MongoMK och Database DocumentNodeStore) - dagligen eller oftare
    • Offline tar Compaction (endast tarMK) - varannan vecka
    • Skräpinsamling för datalager (endast system med FileDataStore eller S3 DataStore) - varje vecka
    • Rensa arbetsflöde - varje vecka
    • Rensa version - varje vecka
    • Rensa granskningslogg - varje vecka

  5. Granska cachelagringsstrategier som implementerats på AEM-dispatchernivå.

  6. Granska din webbplats cachning.

  7. Använd verktyg för analys av webbplatser på klientsidan, till exempel funktionen Granskningar i webbläsaren Utvecklarverktyg i Google Chrome. De här verktygen ger dig rekommendationer om prestandaförbättringar på klientsidan.

Lösningar på vanliga prestandaproblem

Assets Performance Issues

Symtomen på ett Assets-prestandaproblem

  • Långsam filöverföring till /assets.html eller /damadmin-gränssnitt
  • Det tar för lång tid att generera miniatyrbilder
  • Assets-åtgärder som att flytta, ta bort, redigera och uppdatera metadata tar för lång tid

Vad orsakar problem med Assets prestanda

  • Brist på korrekt underhåll
  • De senaste korrigeringspaketen används inte
  • Optimeringar används inte
  • Otillräcklig serverstorlek för användarinläsning

Analysera Assets prestandaproblem

Lösningar på vanliga Assets-prestandaproblem

Minnesproblem

Symtomen på ett minnesproblem

  • AEM kraschar slumpmässigt och i loggarna OutOfMemoryError observeras
  • AEM blir långsammare med tiden och kraschar till slut
  • AEM svarar inte

Diagnostiserar ett minnesfel

  • Sök efter OutOfMemoryError i loggfilerna om du hittar några träffar så har du ett minnesproblem

  • Granska http://aem-host:port/system/console/memoryusage-skärmen

    Om användningen av "Gammal generation" (JDK 7 och tidigare) eller "Tenured Generation" (JDK8 eller senare) är hög kan detta vara ett tecken på ett minnesutnyttjandeproblem i stacken. Klicka på Kör skräpinsamling för att begära att JVM kör en fullständig skräpinsamling. Om det höga stackutnyttjandet förblir högt efter att GC begärts är det sannolikt ett problem. I en AEM-instans med Oak tar-lagring kan ett problem uppstå om den aktuella användningen är större än 3 GB. Hög heapanvändning på ett system med Mongo-lagring kan bero på cachekonfigurationen i minnet.

  • Ta tråddumpar och topputdata och utför trådanalys. Kontrollera om de trådar som orsakar hög användning av CPU är äkta JVM-skräpinsamlingstrådar. Om den tråd som använder den mest CPU-tiden är den virtuella datortråden eller någon skräpinsamlingstrådar finns det troligen ett minnesproblem.

Vad orsakar minnesproblem

  • Java-programmets minnesläcka
  • Java Finalizer-delen har fyllts i på grund av felaktig användning av slutförande i anpassad kod
  • Otillräcklig konfiguration av max heap

Analysera orsaken till ditt minnesproblem

Mer information om hur du hämtar en heap-dump finns i den här artikeln.

Det bästa sättet att identifiera orsaken till ett minnesproblem är att analysera en stackdump.

När du har hämtat en Heap Dump-fil öppnar du den i Eclipse MAT eller IBM Memory Analyzer . I Eclipse MAT kör du Leak Suspects-rapporten och öppnar vyn "Thread Details" (Trådinformation) för att se möjliga orsaker till minnesproblemet.

Lösningar på vanliga minnesproblem

  • Optimera programkoden för att utnyttja mindre minne om du märker att skräpinsamlingen tar lång tid. De flesta problem med skräpinsamlingen kan bäst lösas genom att programmet optimeras och JVM justeras.
  • Om du redan har optimerat programmet och fortfarande upplever långa GC-pauser fokuserar på att justera JVM.

AEM Indexing Issue

Symtomen på indexeringsproblem

Här följer några exempel på problem med AEM/Oak-indexering:

  • Sökresultaten är inaktuella i mer än 10 minuter
  • Sökresultat saknas
  • Fel returneras antingen i användargränssnittet eller i loggar vid sökning via webbplatsens användargränssnitt, Query Builder-sökning eller JCR-frågekörning

Diagnostiserar ett indexeringsproblem

Så här ser du om asynkron indexering är långsam eller misslyckas:

  1. Öppna dessa URL:er på din AEM-instans för att visa statistik om den asynkrona indexeraren: http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats - Den här URL:en gäller endast för AEM 6.2 och senare

  2. Markera följande fält på var och en av dessa sidor:

    FailingSince - Detta indikerar när indexeringen först började misslyckas.

    LastError - Det här är stackspårningen som visar vad som gör att indexering misslyckas. Om detta är tomt misslyckas inte indexeringen.

    LastErrorTime - Detta anger att felet uppstod vid den senaste indexeringen.

    LastIndexedTime - Om datumet och tiden för det här fältet är äldre än 5 minuter körs indexeringen för långsamt.

Vad orsakar problem med indexering

  • Felaktigt underhåll eller fel vid underhåll som Revision Garbage Collection, Workflow Renge, Audit Renge, Version Renge osv.
  • Skadade eller saknade segment i tjärlagring
  • Revision Corruption in a Cluster environment (DocumentNodeStore - Mongo or Database)
  • Ett problem med klustertopologin i en klustrad miljö

Analysera vad som orsakar indexeringsproblem

Replikeringsproblem

Symtomen på replikeringsproblem

  • Publiceringsbegäranden köas i replikeringsagentkön
  • Publicerat innehåll visas inte på publiceringsservern
  • Påverkan på systemets prestanda

Vad orsakar replikeringsproblem:

  • Replikeringsagenten är felkonfigurerad och kan inte ansluta till publiceringsagenten
  • Det uppstod ett fel vid replikeringen som gjorde att replikeringskön fastnade
  • Systemet är långsamt och replikeringarna behandlas långsamt
  • Replikeringen sker som en del av ett anpassat arbetsflöde och problemet är arbetsflödesbearbetning.

Så här analyserar du replikeringsproblem:

  1. Kontrollera replikeringskön status:

    Aktiv: när objekt bearbetas.

    Inaktiv: när kön är tom.

    Blockerad: när objekt finns i kön, men inte kan bearbetas, till exempel när agenten pekar på en värd som är nere eller inte finns.

  2. Granska replikeringskonfigurationerna om servern är klonad eller om agenten har konfigurerats nyligen. Mer information finns här.

  3. Granska loggarna för replikeringsagenten på http://host:port/etc/replication/agents.author/AgentName.log.html#end. Om du inte kan identifiera några objekt samlar du in den här loggen och presenterar den för AEM support.

  4. Granska serverfelet.log från AEMinstall/crx-quickstart/logs. Om du inte kan identifiera några objekt samlar du in den här loggen och presenterar den för AEM support.

  5. Om replikeringskön är i viloläge och inget av ovanstående gäller, beror problemet troligen på arbetsflödena. Om arbetsflödena inte bearbetas kommer replikeringsobjektet aldrig till replikeringskön. Om du vill övervaka arbetsflödenas status kan du kontrollera antalet arbetsflödesinstanser som körs på kontrollpanelen för arbetsflöde. Du kan läsa om hur du administrerar arbetsflöden här.

  6. Replikeringar blir långsammare när systemet är under hög belastning eller upplever andra prestandaproblem.

Lösning på vanliga replikeringsproblem:

  1. Granska problem med replikeringskön.
  2. Om problemet beror på att arbetsflödena inte fungerar som de ska kan du läsa de aktuella arbetsflödestipsen.

TjärMK-fel

Symtomen på TjärMK-skador

  • Instansen kan inte användas efter offlinekomprimering.
  • Instansen har fastnat i tillståndet Startup pågår.
  • Loggfiler eller komprimeringskommandots utdatarapport SegmentNotFoundException.

Vad orsakar korruptionsproblem

  • Segmentet tas bort genom manuell åtgärd (t.ex. rm -rf ).
  • Segmentet tas bort av skräpinsamlingen för revision eller så går det inte att hitta segmentet på grund av ett fel i koden.
  • Det går inte att hitta segmentet på grund av ett fel i koden.
  • Olika underhållsåtgärder utförs inte i tid, vilket leder till databastillväxt och brist på diskutrymme.
  • Tvinga AEM att stoppa Java-processen.

Diagnostiserar fel i databasen:

  • Granska filen error.log och kontrollera om det finns SegmentNotFoundException eller IllegalArgument Exception.
  • Om du vill ta reda på om ett segment har tagits bort genom skräpinsamling kontrollerar du utdata för loggboken org.apache.jackrabbit.oak.plugins.segment.file.tarReader-GC (enable debug log). Den loggaren loggar segment-ID:n för alla segment som tagits bort under rensningsfasen. Det är bara när det felaktiga segment-ID:t visas i utdata från den loggboken som skräpinsamlingen för revideringar orsakar undantaget.
  • Om det finns fel i det externa datalagret, sökloggfilen efter alla förekomster av felet Fel uppstod när InputStream hämtades för blobId. Detta fel innebär att du saknar filer i AEM datalagerkatalog.

Lösning för att reparera fel:

  • Ta reda på den senaste fungerande versionen av segmentarkivet genom att använda körningsläget check för ekrun. Återställ det skadade segmentarkivet manuellt till den senaste fungerande versionen. Den här åtgärden återställer Oak-databasen till ett tidigare läge i tid. Du bör säkerhetskopiera databasen fullständigt innan du utför den här åtgärden.

    • Om du vill utföra kontroll och återställning följer du stegen som anges i den här artikeln.
    • Om kontrollen misslyckas med ConsistencyChecker - Inga bra revideringar hittades implementerar du stegen i del B i den här artikeln.

  • Om du inte använder ett datalager använder du en extern fil, S3- eller Azure-datalager, i stället för standardsegmentlager.

    • Ett datalager ger bättre prestanda.
    • Migrera instansen till en med ett datalager med crx2oak.

  • Använd senaste Service Pack och Cumulative Fix Pack samt Oak Cumulative Fix Pack.

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