CRX-/CQ-Prozess verwendet 100 % der CPU, das System reagiert nicht oder das System ist langsam
Häufig gestellte Fragen (Alle Artikel in englischer Sprache)
Was sind die typischen Situationen, die hohen CPU-Verbrauch verursachen?
Bestimmte Wartungsaufgaben können zu einer höheren CPU-Auslastung als gewöhnlich führen: tar compaction, datastore garbage collection, Online-Backup, Tree-Aktivierung, Bereitstellung einer Anwendungsaktualisierung, die zum Löschen des Cache führen usw.
Was kann ein Grund für einen CPU-Verbrauch von 0 % sein?
Ein Deadlock der Java-Ebene kann eine solche Situation verursachen. Legen Sie in diesem Fall einige Thread-Sicherheitskopien an, generieren Sie ein Support-Ticket und starten Sie die AEM-Instanz neu.
Gibt es Tipps zur Leistungsoptimierung?
Lösungen
Video-Gem – detaillierte Technik-Sitzung
Die Video-Gem-Session ist auf http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html verfügbar
Adobe Experience Manager 5.6 oder höher und CRX 2.3 oder höher
Verwenden Sie http://localhost:4502/system/console/profiler mindestens ein paar Minuten lang während einer Langsamkeitsphase oder einer Phase mit hohem CPU-Verbrauch. Mithilfe der Ausgabe können Sie bestimmen, welche JVM-Threads die meisten CPU-Zyklen verbrauchen und die zugehörigen Pakete und Klassen.
Bis zu CRX 2.2
Verwenden Sie das einfache Profiling-Tool, das in CRX 2.0.x enthalten ist. Zum Starten öffnen Sie
http://localhost:7402/crx/diagnostic/prof.jsp
CRX 1.x
Um das Problem zu analysieren, erstellen Sie einige vollständige Thread-Sicherheitskopien. Diese Thread-Sicherheitskopien können dann analysiert werden. Erstellen von vollständigen Thread-Sicherheitskopien
Rufen Sie die Prozess-ID ab
Um die Prozess-ID Ihres Java-Prozesses abzurufen, verwenden Sie
jps -l
Wenn dies nicht funktioniert (Pfad nicht festgelegt, JDK nicht installiert oder ältere Java-Version), verwenden Sie
ps -el | grep java
Vollständige Thread-Sicherheitskopien
Um ein Leistungsproblem oder einen deaktivierten Prozess zu analysieren, erstellen Sie ungefähr zehn vollständige Thread-Sicherheitskopien mit ca. einer Sekunde Verzögerung. Wenn das Problem mit dem Clustering zu tun haben könnte, erstellen Sie mindestens zehn vollständige Thread-Sicherheitskopien auf jedem Clusterknoten. Wenn möglich, sollten die Thread-Sicherheitskopien in etwa zur gleichen Zeit erstellt werden (muss nicht genau sein).
Eine vollständige Thread-Sicherheitskopie beginnt z. B. mit diesen Informationen:
2015-07-22 10:26:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.65-b04):
"Thread-76273" daemon prio=3 tid=0x111061 nid=0x111061 running [0x111061]
... stack and locked object MUST be present
Wenn Ihre Thread-Sicherheitskopie nicht wie oben dargestellt wird, ist es nicht möglich, korrekte Untersuchungen durchzuführen.
Sie können das „Tool“ verwenden, das in der Paketfreigabe enthalten ist, wie auf der Seite beschrieben. Es bietet ein Tool für Thread-Sicherheitskopien, mit dem Sie mehrere Thread-Sicherheitskopien anlegen können. Sie werden im oben erwähnten Format bereitgestellt.
Ansonsten verwenden Sie jstack, wenn dies installiert ist. Mit diesem Befehl werden die Thread-Sicherheitskopien auf das System gedruckt:
jstack <pid>
Mit diesem Befehl wird eine vollständige Thread-Sicherheitskopie an eine Datei angehängt:
jstack <pid> >> threadDumpNode1.txt
Bei einigen Systemen müssen Sie möglicherweise folgendes verwenden: sudo -u aem jstack -J-d64 -l <pid>
Wenn dies nicht funktioniert, verwenden Sie kill -QUIT. Mit diesem Befehl werden die Thread-Sicherheitskopien in die Protokolldatei gedruckt:
kill -QUIT <pid>
Wenn keine Thread-Sicherheitskopien in der Standardausgabe des letzten Befehls vorhanden sind, können Sie dies vielleicht den Java-Parametern hinzufügen:
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log
Hinweis: Wenn die obigen Schritte zum Erhalten von Thread-Sicherheitskopien in Ihrer Umgebung nicht funktionieren, lesen Sie bitte diesen Artikel.
CPU-Auslastung überprüfen
Um das Problem zu analysieren, müssen Sie wissen, ob CRX /CQ in einer Endlosschleife ausgeführt wird oder ob es nur im Ruhemodus ist. Um dies herauszufinden, geben Sie
top
Dieser Befehl ruft die Liste der Prozesse ab, sortiert nach der CPU-Auslastung. Wenn der obere Prozess ein „Java“-Prozess ist und wenn die PID mit CRX/CQ übereinstimmt, wird der Prozess mit voller Geschwindigkeit ausgeführt.
Wenn Sie nicht sicher sind, wie Sie die Ergebnisse interpretieren sollten, führen Sie die folgende Anweisung aus und fügen Sie dann die Datei top.txt in Ihren Problembericht ein:
top -l5 -s5 > top.txt
Sitzungsanzahl überprüfen
In vielen Fällen ist das Problem die zu große Anzahl an offenen Sitzungen. Irgendwann wird die Verarbeitung langsamer. Um festzustellen, ob dies der Fall ist, führen Sie
jps -l aus (um die Prozess-ID des Java-Prozesses zu erhalten)
jmap -histo <pid> | grep CRXSession (um die Anzahl der geöffneten Sitzungen zu erhalten)
Wenn dies tatsächlich das Problem ist (die Anzahl also höher als einige hundert Sitzungen ist), muss dies analysiert werden. Möglicherweise wird ein Sitzungspool verwendet (je nach Version der CRX / CQ kann es einen Hotfix für das Problem geben) oder ein interner (möglicherweise auf Anwendungsebene) Cache verweist auf die Sitzungen. Um zu analysieren, wo diese Sitzungen geöffnet sind, siehe die Seite „Ungeöffnete Sitzungen analysieren“.
Vorgang nicht abbrechen
Der CRX-Prozess sollte nie abgebrochen werden, auch nicht dann, wenn die Beendigung zu lange dauert. Wenn Sie einen nicht reagierenden Prozess abbrechen müssen, erstellen Sie zuerst eine vollständige Thread-Sicherheitskopie und protokollieren Sie einen Fehler.
Wenn Sie den CRX-Prozess abbrechen, kann das Tar PM beim nächsten Starten backup_.tar Dateien erstellen.
Support-Tools
Verwenden Sie das Sammel- und Analysetool für Thread-Sicherheitskopien, um Thread-Sicherheitskopien von einer laufenden CQ-Instanz zur Fehlerbehebung folgender Merkmale zu erstellen:
- Leistung
- Sperrkonflikte
- Deadlock
- andere Probleme im Zusammenhang mit Threads
Bei Ihrem Konto anmelden