So analysieren Sie häufige kritische AEM
Erfahren Sie mehr über die häufigsten kritischen AEM und deren Analyse.
Beschreibung description
Umgebung
Adobe Experience Manager (AEM)
Problem
In diesem Artikel werden die häufigsten kritischen AEM und deren Analyse beschrieben.
- AEM Sites-Leistung
- AEM Assets-Leistung
- Speicherprobleme
- Indizierungsprobleme
- Replikationsprobleme
- TarMK-Korruptionsprobleme
Auflösung resolution
AEM Sites-Leistungsprobleme
Symptome eines Leistungsproblems
- Langsames Laden von Seiten
- Langsame Erstellung oder Bearbeitung von Seiten
- AEM Reaktionszeiten sind langsam
- AEM reagiert für einige Anforderungen nicht
- Die AEM request.log zeigt langsame Antwortzeiten an
Ursachen für Leistungsprobleme
- Thread-Konflikt - lange laufende Anforderungen wie langsame Suchvorgänge, schreibintensive Hintergrundaufträge, Verschieben ganzer Verzweigungen von Site-Inhalten usw.
- Hohe CPU-Auslastung
- Kostspielige Anforderungen wie kostspielige Suchvorgänge oder ineffizienter Anwendungscode, Komponenten usw.
- Mangelnde Instandhaltung
- Nicht genügend Dispatcher-Caching
- Fehlende CDN
- Fehlende Browser-Zwischenspeicherung
- Zu viele Skripte, die auf der Seite geladen und oben auf der Seite geladen werden
- CSS wird auf der gesamten Seite geladen anstatt im HTML-Head
- Unzureichende Servergröße oder falsche Architektur
- Speicherprobleme (siehe unten)
Analysieren des Leistungsproblems
-
Erfassen einer Reihe von Thread-Sicherheitskopien und analysieren.
-
Ü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 vordefinierte Profiling-Tool für einige Minuten aus und analysieren Sie das Ergebnis.
- Linux: Verwenden Sie den obersten Befehl, um die CPU-Auslastung zu überprüfen.
- Fenster: Verwenden Sie den Windows Task Manager.
-
Analysieren Sie die Datei request.log für langsame Anforderungen..
-
Überprüfen Sie die Systemwartungsverfahren. Siehe dies Artikel für Details zur AEM Wartung und stellen sicher, dass Sie eine ordnungsgemäße Wartung der AEM durchführen, einschließlich:
- Revisionsbereinigung (nur MongoMK und Database DocumentNodeStore) - täglich oder häufiger
- Offline-Tar-Verdichtung (nur TarMK) - zweimal wöchentlich
- Datenspeicherbereinigung (nur Systeme mit FileDataStore oder S3 DataStore) - wöchentlich
- Workflow-Bereinigung - wöchentlich
- Versionsbereinigung - wöchentlich
- AuditLog Purge - weekly
-
Überprüfen Sie die auf der AEM Dispatcher-Ebene.
-
Überprüfen Sie die Zwischenspeicherung.
-
Verwenden Sie clientseitige Site-Analyse-Tools wie die Prüfungen Funktion im Google Chrome-Browser Entwicklertools Bedienfeld. Mit diesen Tools erhalten Sie Empfehlungen zu clientseitigen Leistungsverbesserungen.
Lösungen für häufige Leistungsprobleme
- Siehe Abschnitt diesem Artikel für detaillierte Schritte zur Leistungsoptimierung.
- Überprüfen Sie die Tipps zur Leistungsoptimierung
Asset-Leistungsprobleme
Symptome eines Assets-Leistungsproblems
- Langsame Datei-Uploads auf /assets.html oder /damadmin UI
- Die Erstellung von Miniaturansichten dauert zu lange
- Asset-Vorgänge wie Verschieben, Löschen, Bearbeiten und Aktualisieren von Metadaten benötigen zu lange
Ursachen von Problemen mit der Assets-Leistung
- Mangelnde Instandhaltung
- Neueste Fixpacks werden nicht angewendet
- Nicht angewendete Optimierungen
- Unzureichende Servergröße für das Laden des Benutzers
Analysieren des Leistungsproblems bei Assets
Lösungen für häufige Asset-Leistungsprobleme
- Überprüfen Sie die Handbuch zur Leistungsoptimierung von AEM Assets.
- Lösungen für einige Problemszenarien und ihre Lösungen finden Sie here.
- Steigern der Leistung bei der Asset-Verarbeitung, siehe diesem Artikel.
Speicherprobleme
Symptome eines Speicherproblems
- AEM Abstürze werden zufällig beobachtet und in den Protokollen "OutOfMemoryError"
- AEM wird mit der Zeit langsamer und stürzt schließlich ab
- AEM reagiert nicht
Speicherproblem diagnostizieren
-
Suchen Sie die Protokolldateien nach OutOfMemoryError, wenn Sie Übereinstimmungen finden, haben Sie ein Speicherproblem.
-
Überprüfen Sie die http://aem-host:port/system/console/memoryusage screen
Wenn die Verwendung der "alten Generation"(JDK 7 und früher) oder "Tenured Generation"(JDK 8 oder höher) hoch ist, könnte dies ein Anzeichen für ein Problem mit der Heap-Speicherauslastung sein. Klicken Sie auf "Garbage Collector ausführen", um die 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. Bei einer AEM-Instanz mit Oak Tar-Speicher kann es bei einer höheren Nutzung als 3 GB zu Problemen kommen. Eine hohe Heap-Auslastung auf einem System mit Mongo-Speicher kann auf die Cache-Konfiguration im Arbeitsspeicher zurückzuführen sein.
-
Thread-Sicherheitskopien und Top-Ausgaben verwenden und führen Thread-Analyse. Überprüfen Sie, ob die Threads, die eine hohe CPU-Auslastung verursachen, native JVM-Speicherbereinigungs-Threads sind. Wenn der Thread, der die höchste CPU-Zeit verwendet, die "VM Thread"oder ein Speicherbereinigungs-Thread ist, liegt wahrscheinlich ein Speicherproblem vor.
Ursachen für Speicherprobleme
- Speicherleck der Java-Anwendung
- Java Finalizer wird aufgrund einer falschen Verwendung der Fertigstellung im benutzerdefinierten Code bereitgestellt
- Ungenügende maximale Heap-Konfiguration
Analysieren der Ursache Ihres Speicherproblems
Siehe diesem Artikel für Details zum Erfassen eines Heap-Dump.
Die beste Möglichkeit, die Ursache eines Speicherproblems zu identifizieren, besteht darin, einen Heap-Dump zu analysieren.
Nachdem Sie eine Heap Dump-Datei erfasst haben, öffnen Sie sie in Eclipse MAT oder IBM Memory Analyzer -Tool. Führen Sie in Eclipse MAT den Bericht "Leak Suspects"aus und öffnen Sie die Ansicht "Thread Details", um potenzielle Ursachen für das Speicherproblem anzuzeigen.
Lösungen für häufige Speicherprobleme
- Optimieren Sie Ihren Anwendungs-Code, um weniger Speicher zu verwenden, wenn Sie lange Speicherabfälle bemerken. Die meisten Probleme mit der automatischen Speicherbereinigung lassen sich am besten lösen, indem die Anwendung im Vergleich zur JVM-Optimierung optimiert wird.
- Wenn Sie Ihre Anwendung bereits optimiert haben und dennoch lange GC-Pausen auftreten, Konzentration auf die Optimierung der JVM.
AEM Indizierungsproblem
Indizierungsprobleme
Die folgenden Anzeichen zeigen ein Problem mit AEM/Oak-Indizierung:
- 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
Indizierungsproblem diagnostizieren
Gehen Sie wie folgt vor, um festzustellen, ob die asynchrone Indizierung langsam ist oder fehlschlägt:
-
Öffnen Sie diese URLs in 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 - This URL gilt nur für AEM6.2 und höher
-
Aktivieren Sie auf jeder dieser Seiten die folgenden Felder:
FailingSince - Dies gibt an, wenn die Indizierung zum ersten Mal fehlschlägt.
LastError - Dies ist der Stacktrace, der anzeigt, was dazu führt, dass die Indizierung fehlschlägt. Wenn dies leer ist, schlägt die Indizierung nicht fehl.
LastErrorTime - Dies zeigt an, wann der Fehler bei der letzten Indizierung aufgetreten ist.
LastIndexedTime - Wenn Datum und Uhrzeit dieses Felds über 5 Minuten alt sind, wird die Indizierung zu langsam ausgeführt.
Ursachen für Probleme bei der Indizierung
- Unsachgemäße Wartung oder Fehler bei der Wartung, z. B. Bereinigung der Revision, Bereinigung des Workflows, Bereinigung der Verfolgung, Versionsbereinigung usw.
- Beschädigte oder fehlende Segmente im Tar-Speicher
- Revisionsbeschädigung in einer Clusterumgebung (DocumentNodeStore - Mongo oder Datenbank)
- Problem mit der Cluster-Topologie in einer Clusterumgebung
Analysieren, was Indizierungsprobleme verursacht
- Siehe diesem Artikel zur Analyse und Behebung von Indizierungsproblemen
Replikationsprobleme
Symptome von Replikationsproblemen
- Veröffentlichungsanforderungen befinden sich in der Warteschlange des Replikationsagenten
- Veröffentlichte Inhalte werden nicht auf dem Veröffentlichungsserver angezeigt
- Auswirkung auf die Systemleistung
Ursachen für Replikationsprobleme:
- Der Replikationsagent ist falsch konfiguriert und kann keine Verbindung zum Veröffentlichungsagenten herstellen
- Zum Zeitpunkt der Replikation tritt ein Fehler auf, der dazu führt, dass die Replikationswarteschlange blockiert wird
- Das System ist langsam und die Replikationen werden langsam verarbeitet
- Die Replikation erfolgt im Rahmen eines benutzerdefinierten Workflows. Das Problem liegt in der Workflow-Verarbeitung.
So analysieren Sie Replikationsprobleme:
-
Überprüfen der Replikationswarteschlange status:
Aktiv: wenn Elemente verarbeitet werden.
Idle: 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 ausfällt oder nicht vorhanden ist.
-
Überprüfen Sie die Replikationskonfigurationen, wenn Ihr Server geklont ist oder der Agent kürzlich konfiguriert wurde. Weitere Informationen finden Sie unter here.
-
Ü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 AEM Support zur Verfügung.
-
Überprüfen Sie die Datei "server error.log"von AEMinstall/crx-quickstart/logs; Wenn Sie keine Elemente identifizieren können, erfassen Sie dieses Protokoll und stellen Sie AEM Support zur Verfügung.
-
Wenn die Replikationswarteschlange im Status "inaktiv"ist und keiner der oben genannten Punkte zutrifft, wird in diesem Fall das 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 laufenden Workflow-Instanzen überprüfen. Informationen zur Verwaltung von Workflows here.
-
Die Replikation verlangsamt sich, wenn das System unter hoher Auslastung steht oder andere Leistungsprobleme auftreten.
Lösung für häufige Replikationsprobleme:
- Überprüfen der Probleme mit der Replikationswarteschlange.
- Wenn das Problem darauf zurückzuführen ist, dass Workflows nicht effizient ausgeführt werden, können Sie die gleichzeitige Tipps zur Workflow-Verarbeitung.
TarMK-Korruptionsprobleme
Symptome der TarMK-Korruption
- Die Instanz funktioniert nach der Offline-Verdichtung nicht.
- Instanz hängt an Wird gestartet state.
- Ausgabebericht von Protokolldateien oder Komprimierungsbefehlen SegmentNotFoundException.
Ursachen von Korruptionsproblemen
- Das Segment wird durch manuelles Eingreifen entfernt (z. B. rm -rf ).
- Das Segment wird durch die Revisionsbereinigung 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 Repository-Wachstum und zu wenig Festplattenspeicher führt.
- Erzwungenes Beenden der AEM durch Töten des Java-Prozesses.
Repository-Beschädigungsprobleme diagnostizieren:
- Überprüfen Sie die Datei error.log und überprüfen Sie, ob SegmentNotFoundException oder IllegalArgument Exception.
- Um festzustellen, ob ein Segment durch die Revisionsbereinigung entfernt wurde, überprüfen Sie die Ausgabe des Protokollers 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 erscheint, ist die Revisionsbereinigung die Ursache für die Ausnahme.
- Bei Beschädigung des externen Datenspeichers suchen Sie die Protokolldatei auf alle Vorkommnisse von Fehlern Fehler beim Abrufen von InputStream für blobId. Dieser Fehler bedeutet, dass Dateien aus dem Datenspeicherverzeichnis AEM fehlen.
Lösung zur Behebung von Korruptionsproblemen:
-
Bestimmen Sie die letzte zweifelsfrei funktionierende Revision des Segmentspeichers mithilfe der check Ausführungsmodus von oak-run. Setzen Sie den beschädigten Segmentspeicher manuell auf die neueste gute 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 durchführen.
- Führen Sie zum Durchführen der Überprüfung und Wiederherstellung die unter diesem Artikel.
- Wenn die Prüfung mit ConsistencyChecker - Keine guten Revisionen gefunden dann die Schritte in Teil B von diesem Artikel.
-
Wenn Sie keinen Datenspeicher verwenden, verwenden Sie anstelle des standardmäßigen Segmentspeichers eine externe Datei, einen S3- oder einen Azure-Datenspeicher.
- Die Verwendung eines Datenspeichers bietet eine bessere Leistung.
- Migrieren Sie die Instanz zu einer Instanz mit einem Datenspeicher mithilfe von crx2oak.
-
Wenden Sie das neueste Service Pack und das Cumulative Fix Pack und das Oak Cumulative Fix Pack an.