Ziel

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

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, ob Sie ein CDN verwenden.

7. Überprüfen Sie, ob Sie die Browserzwischenspeicherung verwenden – suchen Sie nach der Überschrift „Cache-Control“.

8. Verwenden Sie clientseitige Site-Analysetools, beispielsweise die Funktion „Audits“ im Bereich „Chrome DevTools“ 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.

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