Zielsetzung

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

AEM-Sites-Leistungsprobleme

Symptome eines Leistungsproblems

  1. Langsames Laden von Seiten  
  2. Langsames Erstellen oder Bearbeiten von Seiten
  3. Langsame AEM-Antwortzeiten
  4. AEM antwortet auf einige Anfragen nicht
  5. In „request.log“ für AEM werden langsame Antwortzeiten angezeigt.

Ursachen für Leistungsprobleme

  1. Thread-Konflikt: lang ausgeführte Anfragen, beispielsweise langsame Suchvorgänge, schreibintensive Hintergrundaufträge, das Verschieben ganzer Zweige von Site-Inhalten usw.
  2. Hohe CPU-Auslastung
  3. Intensive Anfragen, beispielsweise intensive Suchvorgänge oder ineffizienter Anwendungscode, Komponenten usw.
  4. Keine angemessene Wartung
  5. Nicht ausreichende Dispatcher-Zwischenspeicherung
  6. Kein CDN
  7. Keine Browserzwischenspeicherung
  8. Zu viele auf der Seite und oben auf der Seite geladene Skripts
  9. CSS auf der gesamten Seite geladen, anstatt in der HTML-Kopfzeile
  10. Nicht ausreichende Servergröße oder falsche Architektur
  11. Arbeitsspeicherprobleme (siehe unten)

Analysieren des Leistungsproblems

1. Erfassen Sie eine Reihe der Thread-Sicherungskopien und analysieren Sie sie.

2. Überprüfen Sie auf Betriebssystemebene, ob der AEM-Java-Prozess eine hohe CPU-Auslastung verursacht.

    Linux: Verwenden Sie den Befehl „top“, um die CPU-Auslastung zu überprüfen.

    Windows: Verwenden Sie den Windows-Task-Manager.

    Wenn AEM eine hohe CPU-Auslastung verursacht, sollten Sie das standardmäßig einsatzbereite Profiling-Tool für ein paar Minuten ausführen und das Ergebnis analysieren.

3. Analysieren Sie die Datei „request.log“ zwecks langsamer Anfragen.

4. Überprüfen Sie Ihre Systemwartungsprozeduren und stellen Sie sicher, dass Sie eine entsprechende Wartung für AEM vornehmen, einschließlich:

  • täglicher oder häufigerer Revisionsbereinigung (nur MongoMK und DocumentNodeStore der Datenbank)
  • Offline-TAR-Verdichtung (nur TarMK) – 14-tägig
  • Data Store-Abfallsammlung (nur Systeme mit FileDataStore oder S3 DataStore) – wöchentlich
  • Workflow-Bereinigung – wöchentlich
  • Versionsbereinigung – wöchentlich
  • AuditLog-Bereinigung – wöchentlich

Weitere Details zur AEM-Wartung finden Sie in diesem Artikel.

5. Überprüfen Sie auf der AEM-Dispatcher-Ebene implementierte Zwischenspeicherungsstrategien.  Es empfiehlt sich zunächst, sich damit vertraut zu machen, wann und wie der Dispatcher Dateien zwischenspeichert und die Gültigkeit von zwischengespeicherten Dateien aufhebt.

6. Überprüfen Sie das Caching Ihrer Website.

7. Verwenden Sie clientseitige Site-Analysetools, beispielsweise die Funktion Audits im Bereich Developer Tools des Google Chrome-Browsers.  Diese Tools geben Ihnen Empfehlungen zu clientseitigen Leistungsverbesserungen an die Hand.

Lösungen zu allgemeinen Leistungsproblemen

AEM Assets-Leistungsprobleme

Symptome eines Assets-Leistungsproblems

  • Langsame Datei-Uploads zur „/assets.html“- oder „/damadmin“-Benutzeroberfläche
  • Generieren der Miniaturansichten dauert zu lange
  • Asset-Vorgänge, beispielsweise das Verschieben, Löschen, Bearbeiten und Aktualisieren von Metadaten, dauern zu lange.

Was verursacht Probleme mit der Assets-Leistung?

  • Keine angemessene Wartung
  • Neueste Korrekturpakete nicht angewendet
  • Optimierungen nicht angewendet
  • Unangemessene Servergröße für die Benutzerauslastung

Analysieren des Assets-Leistungsproblems

Lösungen zu allgemeinen Assets-Leistungsproblemen

Arbeitsspeicherprobleme

Symptome eines Arbeitsspeicherproblems

  • AEM stürzt zufällig ab und in den Protokollen wird „OutOfMemoryError“ beobachtet.
  • AEM wird mit der Zeit langsamer und stürzt schließlich ab.
  • AEM antwortet nicht.

Diagnostizieren eines Arbeitsspeicherproblems

  • Durchsuchen Sie die Protokolldateien nach „OutOfMemoryError“. Wenn Sie Treffer finden, liegt ein Arbeitsspeicherproblem vor.
  • Überprüfen Sie den Bildschirm „http://aem-host:port/system/console/memoryusage“
    Wenn die „Old Generation“- (JDK 7 und früher) oder „Tenured Generation“-Auslastung (JDK 8 und höher) hoch ist, kann dies auf ein Problem mit der Heap-Arbeitsspeicherauslastung hindeuten.  Klicken Sie auf die Option zum Ausführen des Garbage Collectors, um von der JVM anzufordern, dass sie eine vollständige Heap-Garbage-Sammlung ausführt.  Wenn die hohe Heap-Auslastung nach dem Anfordern der Garbage Collection hoch bleibt, liegt wahrscheinlich ein Problem vor.  Wenn in einer AEM-Instanz mit Oak-TAR-Speicher die Tenured-Auslastung höher als 3 GB ist, liegt ggf. ein Problem vor.  Eine hohe Heap-Auslastung auf einem System mit Mongo-Speicher kann auf eine arbeitsspeicherinterne Cache-Konfiguration zurückzuführen sein.
  • Verwenden Sie Thread-Sicherungskopien und die Top-Ausgabe und führen Sie eine Thread-Analyse durch.  Überprüfen Sie, ob es sich bei den Threads, die die hohe CPU-Auslastung verursachen, um native JVM-Garbage-Collection-Threads handelt.  Wenn es sich beim Thread, der die meiste CPU-Zeit in Anspruch nimmt, um den „VM Thread“ oder um Garbage-Collection-Threads handelt, liegt wahrscheinlich ein Arbeitsspeicherproblem vor.

Ursachen für Arbeitsspeicherprobleme

  • Java-Anwendungsspeicherleck
  • Pile-up von Java Finalizer aufgrund der falschen Verwendung von „finalize“ in benutzerdefiniertem Code
  • Nicht ausreichende maximale Heap-Konfiguration

Analysieren der Ursache Ihres Arbeitsspeicherproblems

Details zum Erfassen einer Heap-Sicherheitskopie finden Sie in diesem Artikel.

Die beste Möglichkeit zum Ermitteln der Ursache eines Arbeitsspeicherproblems besteht darin, eine Heap-Sicherheitskopie zu analysieren.  

Öffnen Sie, nachdem Sie eine Heap-Sicherheitskopie-Datei erfasst haben, diese in Eclipse MAT oder im IBM Memory Analyzer-Tool.  Führen Sie in Eclipse MAT den „Leak Suspects“-Bericht aus und öffnen Sie die Ansicht „Thread Details“, um potenzielle Ursachen für das Arbeitsspeicherproblem anzuzeigen.

Lösungen zu allgemeinen Arbeitsspeicherproblemen

  • Optimieren Sie Ihren Anwendungscode dahingehend, damit weniger Arbeitsspeicher verwendet wird, wenn Sie lange Garbage-Collection-Pausen feststellen.  Die meisten Garbage-Collection-Probleme lassen sich am besten durch das Optimieren der Anwendung und gleichzeitigem Anpassen der JVM beheben.
  • Wenn Sie Ihre Anwendung bereits optimiert haben und weiterhin lange GC-Pausen feststellen, sollten Sie sich auf das Anpassen der JVM konzentrieren.

AEM-Indizierungsprobleme

Symptome von Indizierungsproblemen

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

  • Die Suchergebnisse sind seit mehr als 10 Minuten abgelaufen.
  • Es fehlen Suchergebnisse.
  • Fehler werden auf der Benutzeroberfläche oder in Protokollen während der Suche über die Site-Benutzeroberfläche, die Query Builder-Suche oder die JCR-Abfrageausführung zurückgegeben.
Diagnostizieren eines Indizierungsproblems
  • So können Sie überprüfen, ob die asynchrone Indizierung langsam ist oder fehlschlägt:

1. Öffnen Sie diese URLs auf Ihrer AEM-Instanz, um Statistiken zum Async-Indizierungsprogramm 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 AEM 6.2 und höher.

2. Überprüfen Sie für jedes dieser Pakete die folgenden Felder:

FailingSince: Gibt an, wann die Indizierung erstmals begann fehlzuschlagen.

LastError: Dies ist der Stacktrace, der die Ursache für das Fehlschlagen der Indizierung anzeigt.  Wenn dieser leer ist, schlägt die Indizierung nicht fehl.

LastErrorTime: Gibt die letzte Uhrzeit an, zu der die Indizierung den Fehler ausgegeben hat.

LastIndexedTime: Wenn das Datum und die Uhrzeit dieses Felds älter als 5 Minuten sind, erfolgt die Indizierung zu langsam.

Ursachen für Indizierungsprobleme

  • Falsche Wartung oder Fehler beim Ausführen der Wartung, beispielsweise Revision-Garbage-Collection, Workflow-Bereinigung, Audit-Bereinigung, Versions-Bereinigung usw.
  • Beschädigte oder fehlende Segmente im TAR-Speicher
  • Revisionsbeschädigung in einer Umgebung mit Clustern (DocumentNodeStore – Mongo oder Datenbank)
  • Ein Problem mit der Clustertopologie in einer Umgebung mit Cluster

Analysieren der Ursachen für Indizierungsprobleme

  • Informationen zum Analysieren und Beheben von Indizierungsproblemen finden Sie in diesem Artikel.

Replikationsprobleme

Anzeichen von Replikationsproblemen

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

Ursachen für Replikationsprobleme:

  • Der Replikationsagent ist falsch konfiguriert und kann keine Verbindung zum Veröffentlichungsagent herstellen
  • Zum Zeitpunkt der Replikation ist ein Fehler aufgetreten, der dazu führt, dass die Replikationswarteschlange stecken bleibt
  • Das System ist langsam und die Replikationen werden langsam verarbeitet
  • Die Replikation findet im Rahmen eines benutzerdefinierten Workflows statt und das Problem liegt in der Workflow-Verarbeitung.

So analysieren Sie Replikationsprobleme:

1. Überprüfen Sie den Status der Replikationswarteschlange:

        Aktiv: wenn Elemente verarbeitet werden.
        Leerlauf: wenn die Warteschlange leer ist.
        Gesperrt: wenn sich Elemente in der Warteschlange befinden, aber nicht verarbeitet werden können, z. B. wenn der Agent auf einen Host zeigt, der ausgefallen oder nicht vorhanden ist.

2. Überprüfen Sie die Replikationskonfigurationen, wenn Ihr Server geklont ist oder der Agent kürzlich konfiguriert wurde. Weitere Informationen finden Sie hier
     
3. Überprüfen Sie die Protokolle des Replikationsagenten 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 zur Verfügung.

4. Überprüfen Sie die Server error.log von AEM-Installation/crx-quickstart/logs; Wenn Sie keine Elemente identifizieren können, erfassen Sie dieses Protokoll und stellen Sie es dem AEM-Support zur Verfügung.

5. Befindet sich die Replikationswarteschlange im Status „Leerlauf“ („idle“) und nichts des Obengenannten trifft zu, wird in diesemFalldas Problem höchstwahrscheinlich 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 im Workflow-Dashboard die Anzahl der ausgeführten Workflow-Instanzen überprüfen. Wie Sie Workflows verwalten können, erfahren Sie hier.

6. Replikationen verlangsamen sich, wenn das System unter hoher Last steht oder andere Leistungsprobleme auftreten.

Lösungen zu allgemeinen Replikationsproblemen:

1) Überprüfen Sie die Probleme mit der Replikationswarteschlange
2) Wenn das Problem darauf zurückzuführen ist, dass die Arbeitsabläufe nicht effizient vor sich gehen, können Sie die Tipps zur gleichzeitigen Verarbeitung von Workflows lesen
3) Bezüglich Problemen im Zusammenhang mit der insgesamt langsamen Leistung des AEM und derReplikationkönnen Sich sich über AEM-Leistungsprobleme informieren

TarMK-Korruptionsprobleme

Anzeichen der TarMK-Korruption

  • Instanzist nach der Offline-Verdichtung nicht funktionsfähig.
  • Die Instanz blieb im Status Startup in progress stecken.
  • Protokolldateien oder Bericht über die Ausgabe des Verdichtungsbefehls SegmentNotFoundException.

Ursachen für Korruptionsprobleme

  • Das Segment wird durch manuelles Eingreifen (z. B. rm-rf) entfernt.   
  • Das Segment wird durch die Revision Garbage Collection 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 ausgeführt, was zu einem Wachstum des Repositorys und geringem Festplattenspeicher führt.
  • Erzwungenes Stoppen von AEM durch Beenden des Java-Prozesses.

Repository-Beschädigungsprobleme diagnostizieren:

  • Überprüfen Sie die error.log-Datei und prüfen Sie, ob SegmentNotFoundException oder IllegalArgument Exception vorliegen.
  • Um festzustellen, ob ein Segment durch die Garbage Collection Revision entfernt wurde, überprüfen Sie die Ausgabe der Datei org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC-Logger (Debug-Log aktivieren). Dieser Logger protokolliert die Segment-IDs aller Segmente, die durch die Bereinigungsphase entfernt wurden. Nur wenn die problematische Segment-ID in der Ausgabe dieses Loggers erscheint, ist die Revision Garbage Collection die Ursache für die Ausnahme.    
  • Im Falle einer Beschädigung des externen Datenspeichers wird die Protokolldatei nach allen Fehlerereignissen Beim Abrufen von InputStream for blobId ist ein Fehler aufgetreten durchsucht. Dieser Fehler bedeutet, dass Dateien in Ihrem AEM-Datenspeicherverzeichnis fehlen.

Lösung zur Behebung von Korruptionsproblemen:

  • Bestimmen Sie die letzte bekannte funktionierende Revision des Segmentspeichers, indem Sie den Check-Run-Modus von oak-run verwenden.  Setzen Sie den beschädigten Segmentspeicher manuell auf die neueste funktionsfähige Version zurück. Durch diesen Vorgang wird das Oak-Repository rechtzeitig auf einen vorherigen Status zurückgesetzt.  Sie sollten das Repository vollständig sichern, bevor Sie diesen Vorgang ausführen.
    • Um diesen Vorgang durchzuführen,prüfen Sieund befolgen Sie zum Wiederherstellen die in diesem Artikel genannten Schritte.
    • Wenn die Prüfung fehlschlägt (ConsistencyChecker - Keine guten Revisionen gefunden), implementieren Sie die Schritte in Teil B dieses Artikels.
  • Wenn Sie bereits einen Datenspeicher verwenden und auf den Fehler „Fehler beim Abrufen von InputStream für blobId“ stoßen, dann fehlen wahrscheinlich Dateien im Datenspeicher. Befolgen Sie diesen Artikel, um das Problem zu beheben.
  • Wenn Sie keinen Datenspeicher verwenden, verwenden Sie eine externe Datei, S3 oder einen Azure-Datenspeicher, anstelle des standardmäßigenSegmentspeichers.
    • Die Verwendung eines Datenspeichers bietet eine bessere Leistung.
    • Migrieren Sie die Instanz mit crx2oak zu einer Instanz mit einem Datenspeicher.
  • Übernehmen Sie das neueste Service Pack und Cumulative Fix Pack und Oak Cumulative Fix Pack.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie