Dokumentation

Analysieren häufiger kritischer AEM-Probleme

Last update: Tue Apr 01 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Erfahren Sie mehr über die häufigsten kritischen AEM-Probleme und deren Analyse.

Beschreibung description

Umgebung

Adobe Experience Manager (AEM)

Problem/Symptome

In diesem Artikel werden die häufigsten kritischen AEM-Probleme und deren Analyse beschrieben.

  • AEM Sites-Leistung
  • AEM Assets-Leistung
  • Speicherprobleme
  • Indizierungsprobleme
  • Replikationsprobleme
  • TarMK-Beschädigungsprobleme

Auflösung resolution

AEM Sites-Leistungsprobleme

Symptome eines Leistungsproblems

  1. Langsames Laden von Seiten
  2. Langsame Erstellung oder Bearbeitung von Seiten
  3. AEM-Antwortzeiten sind langsam
  4. AEM reagiert auf einige Anfragen nicht
  5. Die Datei request.log in AEM zeigt langsame Antwortzeiten an

Was verursacht Leistungsprobleme

  1. Thread-Konflikt: Langwierige Anfragen wie langsame Suchen, schreibintensive Hintergrundaufträge, Verschieben ganzer Zweige des Site-Inhalts usw.
  2. Hohe CPU-Auslastung
  3. Teure Anfragen wie teure Suchvorgänge oder ineffizienter Anwendungs-Code, Komponenten usw.
  4. Fehlende Wartung
  5. Nicht genügend Dispatcher-Caching
  6. Fehlendes CDN
  7. Fehlende Browser-Zwischenspeicherung
  8. Zu viele Skripte wurden auf der Seite geladen und oben auf der Seite geladen
  9. CSS wird über die gesamte Seite geladen, anstatt im HTML-Header
  10. Unzureichende Servergröße oder falsche Architektur
  11. Speicherprobleme (siehe unten)

So analysieren Sie das Leistungsproblem

  1. Erfassen Sie eine Reihe von ThreadDumps und analysieren Sie sie.

  2. Überprüfen Sie auf Betriebssystemebene, ob der AEM Java-Prozess eine hohe CPU-Auslastung verursacht: Wenn AEM eine hohe CPU-Auslastung verursacht, führen Sie das vorkonfigurierte Profiling-Tool einige Minuten lang aus und analysieren Sie das Ergebnis.

    • Linux: Verwenden Sie den obersten Befehl, um die CPU-Auslastung zu überprüfen.
    • Fenster: Windows Task-Manager verwenden

  3. Analysieren Sie die Datei request.log auf langsame Anfragen.

  4. Überprüfen Sie Ihre Systemwartungsverfahren. In diesem Artikel finden Sie Einzelheiten zur Wartung von AEM und stellen sicher, dass Sie eine ordnungsgemäße Wartung von AEM durchführen, einschließlich:

    • Revisionsbereinigung (nur MongoMK und DocumentNodeStore-Datenbank) - täglich oder häufiger
    • Offline-Tar-Komprimierung (nur TarMK) - zweiwöchentlich
    • Datenspeicherbereinigung (nur Systeme mit FileDataStore oder S3 DataStore) - wöchentlich
    • Workflow-Bereinigung - wöchentlich
    • Versionsbereinigung - wöchentlich
    • AuditLog Purge - wöchentlich

  5. Überprüfen Sie die auf der AEM-Dispatcher-Ebene implementierten.

  6. Überprüfen Sie die Ihrer Site.

  7. Verwenden Sie Client-seitige Site-Analyse-Tools wie die Funktion Audits im Bedienfeld „Entwickler Tools von Google Chrome. Mit diesen Tools erhalten Sie Empfehlungen zu Client-seitigen Leistungsverbesserungen.

Lösungen für häufige Leistungsprobleme

Assets-Leistungsprobleme

Symptome eines Assets-Leistungsproblems

  • Langsame Datei-Uploads in die Benutzeroberfläche /assets.html oder /damadmin
  • Miniaturen benötigen zu lange, um generiert zu werden
  • Assets-Vorgänge wie Verschieben, Löschen, Bearbeiten und Metadatenaktualisierung dauern zu lange

Was verursacht Probleme mit der Leistung von Assets

  • Fehlende Wartung
  • Neueste Fix Packs nicht angewendet
  • Optimierungen nicht angewendet
  • Unzureichende Servergröße für die Benutzerauslastung

So analysieren Sie das Leistungsproblem von Assets

Lösungen für häufige Assets-Leistungsprobleme

  • AEM Assets Lesen Sie das Handbuch zur Leistungsoptimierung für 🔗.
  • Steigern der Leistung bei der Asset-Verarbeitung, siehe diesen Artikel.

Speicherprobleme

Symptome eines Gedächtnisproblems

  • AEM stürzt zufällig ab und in den Protokollen wird OutOfMemoryError
  • AEM wird mit der Zeit langsamer und stürzt schließlich ab
  • AEM reagiert nicht

Diagnose eines Speicherproblems

  • Suchen Sie in den Protokolldateien nach OutOfMemoryError. Wenn Sie Übereinstimmungen finden, haben Sie ein Speicherproblem

  • Überprüfen Sie den http://aem-host:port/system/console/memoryusage .

    Wenn die Nutzung von „Old Generation“ (JDK 7 und früher) oder „Tenured Generation“ (JDK8 oder später) hoch ist, kann dies ein Zeichen für ein Problem mit der Heap-Speicherauslastung sein. Klicken Sie auf „Garbage Collector ausführen“, um JVM anzufordern, eine vollständige Heap-Speicherbereinigung auszuführen. Wenn die hohe Heap-Auslastung nach der Anforderung von GC hoch bleibt, liegt wahrscheinlich ein Problem vor. Wenn auf einer AEM-Instanz mit Oak-TAR-Speicher die dauerhafte Nutzung größer als 3 GB ist, kann ein Problem auftreten. Eine hohe Heap-Auslastung auf einem System mit Mongo-Speicher kann auf die speicherinterne Cache-Konfiguration zurückzuführen sein.

  • Erstellen von Thread-Dumps und Top- und Durchführen Thread-Analyse. Überprüfen Sie, ob die Threads, die eine hohe CPU-Auslastung verursachen, native JVM-Garbage Collection-Threads sind. Wenn der Thread, der die meiste CPU-Zeit verwendet, der „VM-Thread“ oder ein Speicherbereinigungs-Thread ist, besteht wahrscheinlich ein Speicherproblem.

Was verursacht Speicherprobleme

  • Leck des Java-Anwendungsspeichers
  • Java Finalizer wird aufgrund einer falschen Verwendung der Finalisierung in benutzerdefiniertem Code angehäuft
  • Unzureichende Heap-Konfiguration

Wie analysiere ich die Ursache Ihres Speicherproblems

In diesem Artikel finden Sie Einzelheiten zur Erfassung eines Heap-Dump.

Die beste Möglichkeit, die Ursache eines Speicherproblems zu ermitteln, besteht darin, einen Heap-Dump zu analysieren.

Nachdem Sie eine Heap-Dump-Datei erfasst haben, öffnen Sie sie im Tool Eclipse MAT oder IBM Memory Analyzer. Führen Sie in Eclipse MAT den Bericht zu Leckverdächtigen aus und öffnen Sie die Ansicht „Thread Details“, um mögliche Ursachen für das Speicherproblem anzuzeigen.

Lösungen für gängige Speicherprobleme

  • Optimieren Sie den Anwendungs-Code so, dass weniger Arbeitsspeicher belegt wird, wenn Sie lange Pausen bei der Speicherbereinigung bemerken. Die meisten Probleme bei der automatischen Bereinigung lassen sich am besten lösen, indem die Anwendung im Vergleich zur JVM optimiert wird.
  • Wenn Sie Ihre Anwendung bereits optimiert haben und immer noch lange GC-Pausen haben, Sie sich auf die Optimierung der JVM.

AEM-Indizierungsproblem

Symptome von Indizierungsproblemen

Im Folgenden finden Sie Anzeichen für ein Problem bei der Indizierung mit AEM/Oak:

  • Suchergebnisse sind um mehr als 10 Minuten veraltet
  • Es fehlen Suchergebnisse
  • Fehler werden entweder in der Benutzeroberfläche oder während der Suche über die Site-Benutzeroberfläche, die Query Builder-Suche oder die JCR-Abfrageausführung zurückgegeben

Diagnostizieren eines Indizierungsproblems

Gehen Sie wie folgt vor, um festzustellen, ob die asynchrone Indizierung langsam ist oder fehlschlägt:

  1. Öffnen Sie diese URLs auf Ihrer AEM-Instanz, um Statistiken zum asynchronen Indexer anzuzeigen: 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 - Diese URL gilt nur für AEM6.2 und höher

  2. Aktivieren Sie auf jeder dieser Seiten die folgenden Felder:

    FailingSince - Dies gibt an, wann die Indizierung zum ersten Mal fehlschlägt.

    LastError - Dies ist der Stacktrace, der anzeigt, was zum Fehlschlagen der Indizierung führt. Wenn dieser leer ist, schlägt die Indizierung nicht fehl.

    LastErrorTime - Dies gibt an, wann der Fehler zuletzt bei der Indizierung aufgetreten ist.

    LastIndexedTime - Wenn das Datum und die Uhrzeit dieses Felds über 5 Minuten alt sind, wird die Indizierung zu langsam ausgeführt.

Was verursacht Probleme bei der Indizierung

  • Falsche Wartung oder fehlgeschlagene Wartung wie Revisionsbereinigung, Workflow-Bereinigung, Auditbereinigung, Versionsbereinigung usw.
  • Beschädigte oder fehlende Segmente im TAR-Speicher
  • Revisionsbeschädigung in einer Cluster-Umgebung (DocumentNodeStore - Mongo oder Datenbank)
  • Ein Problem mit der Cluster-Topologie in einer Cluster-Umgebung

Wie kann ich analysieren, was Indizierungsprobleme verursacht

  • Siehe diesen Artikel zur Analyse und Behebung von Indizierungsproblemen

Replikationsprobleme

Symptome von Replikationsproblemen

  • Veröffentlichungsanfragen werden in die Warteschlange des Replikationsagenten gestellt
  • Veröffentlichte Inhalte werden nicht auf dem Veröffentlichungsserver angezeigt
  • Auswirkungen auf die Systemleistung

Was verursacht Replikationsprobleme:

  • Der Replikationsagent ist falsch konfiguriert und kann keine Verbindung zum Veröffentlichungsagenten herstellen
  • Zum Zeitpunkt der Replikation ist ein Fehler aufgetreten, wodurch die Replikationswarteschlange blockiert wird
  • Das System ist langsam, und die Replikationen werden langsam verarbeitet
  • Die Replikation erfolgt im Rahmen eines benutzerdefinierten Workflows, und das Problem ist die Workflow-Verarbeitung.

So analysieren Sie Replikationsprobleme:

  1. Überprüfen Sie die Replikationswarteschlange Status:

    Aktiv: wenn Elemente verarbeitet werden.

    Leerlauf: wenn die Warteschlange leer ist.

    Blockiert: wenn sich Elemente in der Warteschlange befinden, aber nicht verarbeitet werden können, z. B. wenn der Agent auf einen Host verweist, der ausgefallen ist oder nicht existiert.

  2. Überprüfen Sie die Replikationskonfigurationen, wenn Ihr Server geklont wurde oder der Agent kürzlich konfiguriert wurde. Weitere Informationen finden Sie hier.

  3. Überprüfen Sie die Replikationsagenten-Protokolle unter http://host:port/etc/replication/agents.author/AgentName.log.html#end. Wenn Sie keine Elemente identifizieren können, erfassen Sie dieses Protokoll und stellen Sie es dem AEM-Support vor.

  4. Überprüfen Sie die Datei error.log des Servers unter AEMinstall/crx-quickstart/logs; Wenn Sie keine Elemente identifizieren können, erfassen Sie dieses Protokoll und senden Sie es an den AEM-Support.

  5. Wenn sich die Replikations-Warteschlange im Status „Idle“ befindet und keiner der oben genannten Punkte zutrifft, wird das Problem in diesem Fall wahrscheinlich durch die Workflows verursacht. Wenn die Workflows nicht verarbeitet werden, gelangt das Replikationselement nie in die Replikationswarteschlange. Um den Status Ihrer Workflows zu überwachen, können Sie das Workflow-Dashboard überprüfen, um die Anzahl der laufenden Workflow-Instanzen zu überprüfen. Informationen zur Verwaltung von Workflows finden Sie hier.

  6. Die Replikation verlangsamt sich, wenn das System stark ausgelastet ist oder andere Leistungsprobleme auftreten.

Lösung für häufige Replikationsprobleme:

  1. Überprüfen Sie die Probleme mit der Replikationswarteschlange.
  2. Wenn das Problem darauf zurückzuführen ist, dass die Workflows nicht effizient ausgeführt werden, können Sie die „Tipps zur ".

TarMK-Beschädigungsprobleme

Symptome einer TarMK-Beschädigung

  • Die Instanz ist nach der Offline-Komprimierung nicht funktionsfähig.
  • Instanz steckt im Status Start läuft fest.
  • Protokolldateien oder Bericht der Ausgabe des Komprimierungsbefehls SegmentNotFoundException.

Was verursacht Korruptionsprobleme

  • Das Segment wird durch manuelles Eingreifen entfernt (z. B. rm -rf ).
  • Das Segment wird durch die Revisionsdatenbereinigung entfernt oder das Segment kann aufgrund eines Fehlers im Code nicht gefunden werden.
  • Das Segment kann aufgrund eines Fehlers im Code nicht gefunden werden.
  • Verschiedene Wartungsaufgaben werden nicht rechtzeitig durchgeführt, was zu Repository-Wachstum und geringem Speicherplatz führt.
  • Erzwungenes Anhalten von AEM durch Beenden des Java-Prozesses.

Diagnose von Repository-Beschädigungsproblemen:

  • Überprüfen Sie die Datei error.log und überprüfen Sie, ob SegmentNotFoundException oder IllegalArgument Exception vorliegt.
  • Um festzustellen, ob ein Segment durch die Revisionsdatenbereinigung entfernt wurde, überprüfen Sie die Ausgabe des Loggers org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (Debug-Protokoll aktivieren). Dieser Logger protokolliert die Segment-IDs aller Segmente, die durch die Bereinigungsphase entfernt wurden. Nur wenn die fehlerhafte Segment-ID in der Ausgabe dieses Loggers angezeigt wird, ist die Revisionsbereinigung der Grund für die Ausnahme.
  • Im Falle einer Beschädigung des externen Datenspeichers die Protokolldatei nach allen Fehlervorfällen durchsuchen Fehler beim Abrufen von InputStream für blobId. Dieser Fehler bedeutet, dass in Ihrem AEM-Datenspeicherverzeichnis Dateien fehlen.

Lösung zur Behebung von Korruptionsproblemen:

  • Ermitteln Sie die letzte zweifelsfrei funktionierende Revision des Segmentspeichers mithilfe des Ausführungsmodus Überprüfen von oak-run. Setzen Sie den beschädigten Segmentspeicher manuell auf die letzte zweifelsfrei funktionierende Revision zurück. Durch diesen Vorgang wird das Oak-Repository auf einen früheren Status zurückgesetzt. Sie sollten das Repository vollständig sichern, bevor Sie diesen Vorgang ausführen.

    • Um eine Überprüfung und Wiederherstellung durchzuführen, führen Sie die in diesem Artikel beschriebenen Schritte aus.
    • Wenn die Prüfung mit ConsistencyChecker - Keine guten Revisionen gefunden fehlschlägt, implementieren Sie die Schritte in Teil B diesen.

  • Wenn Sie keinen Datenspeicher verwenden, verwenden Sie eine externe Datei, nämlich S3- oder Azure-Datenspeicher, anstelle des standardmäßigen Segmentspeichers.

    • Die Verwendung eines Datenspeichers bietet eine bessere Leistung.
    • Migrieren Sie die -Instanz mithilfe von crx2oak zu einer Instanz mit einem Datenspeicher.

  • Wenden Sie das neueste Service Pack und Cumulative Fix Pack und Oak Cumulative Fix Pack an.

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