Symptome
Wenn folgende Bedingungen erfüllt sind, kann das Problem aufgrund von nicht geschlossenen Sitzungen in CRX auftreten:
- Das System wird langsamer und langsamer.
- Von Zeit zu Zeit hat das System nicht mehr genügend Arbeitsspeicher (nach einigen Stunden, Tagen oder Wochen - je nach Schweregrad)
- Ältere Version von CRX: Sie haben viele „CacheManager: resizeAll“-Einträge in der Protokolldatei (die Zahl hinter „size=...“ ist die Anzahl der Caches; jede Sitzung öffnet ein paar Caches)
Ursache
Wenn eine Anwendung explizit CRXSessions öffnet, muss der Entwickler sicherstellen, dass die Sitzungen korrekt geschlossen werden. Andernfalls werden solche Sitzungen bei der Speicherbereinigung nicht entfernt. Sie bleiben im Speicher und führen zu den aufgelisteten Symptomen. Jede CRXSession erstellt und verwaltet einen eigenen Satz von Caches, was zum allgemeinen Ressourcenverbrauch beiträgt.
Analyse
Um ein vorliegendes Problem mit nicht geschlossenen Sitzungen genauer zu bestimmen, führen Sie die folgenden Befehle aus, um die Gesamtanzahl aktueller CRX-Sessions im Speicher zu bestimmen:
jmap -histo:live <pid> | grep CRXSessionImpl
Die zweite Spalte der Ausgabe ist der Instanzzähler, der angibt, dass viele Sessions nicht geschlossen sind (und sich tatsächlich immer noch im Speicher befinden). Ist diese Zahl wesentlich höher als 100, dann liegt bei Ihrer Anwendung ein Problem mit CRX-Sessions vor.
Führen Sie den folgenden Befehl aus, um zu sehen, wie viele CRX-Sessionobjekte sich im Speicher befinden, einschließlich derjenigen, die darauf warten, bei der Speicherbereinigung entfernt zu werden:
- jmap -histo <pid> | grep CRXSessionImpl
Wie beim vorherigen Befehl ist die zweite Spalte der Instanz-Zähler. Auf diese Weise erfahren Sie, wie viele Session-Objekte im Speicher vorhanden sind und noch aktiv sind oder noch nicht im Zuge der Speicherbereinigung entfernt wurden. Mit dieser Zahl (im Vergleich zu einer früheren) können Sie feststellen, ob Sie zu viele CRX-Sessions in Ihrer Anwendung öffnen und schließen.
Wenn Sie CRX2.3 oder CQ5.5 ausführen, können Sie eine vollständige jvm-Speicherbereinigung erzwingen, indem Sie zu http://<host>:<port>/system/console/memoryusage gehen und auf die Taste „Run Garbage Collector“ klicken. Danach können Sie den oben genannten Befehl mehrmals ausführen, um zu sehen, wie schnell sich die Anzahl der Sitzungsobjekte erhöht. So finden Sie heraus, ob Ihre Anwendung zu viele Sitzungen öffnet und schließt, oder ob Sie Ihre GC-Einstellungen anpassen müssen. Wenn dies tatsächlich ein Problem ist, werden Sie normalerweise feststellen, dass es zu langen Pausen bei der jvm-Speicherbereinigung und langsamen Speicherungen in dem Repository kommt.
Hinweis: Die jmap-Befehlszeilen-Anwendung wird mit der Java JDK geliefert und kann im jdk-Home-Bin-Verzeichnis gefunden werden.
Lösung
Um dieses Problem zu beheben, ist eine weitere Analyse erforderlich, um herauszufinden, wer die CRXSessions eigentlich öffnet und noch wichtiger ist es herauszufinden, wer sie nicht schließt. Ab 1.4.1 hat CRX einen integrierten Debug-Modus, der es Ihnen ermöglicht, den defekten Code zurück zu verfolgen. Dieser Debug-Modus gibt im Grunde jedes Mal einen vollständigen Stack-Trace in die Standard-Out-Protokolldatei aus, wenn eine CRXSession geöffnet wird. Außerdem wird ein Eintrag protokolliert, wenn ein CRXSession erneut geschlossen wird.
Um den Debug-Modus zu aktivieren, fügen Sie beim Starten von CRX den folgenden JVM-Parameter hinzu:
-Dcrx.debug.sessions=true
HINWEIS: Abhängig von der Verwendung des Systems kann die Protokolldatei ziemlich schnell wachsen.
Bei Verwendung des Schnellstarts muss die -nofork-Option verwendet werden, um sicherzustellen, dass die Systemeigenschaft verwendet wird.
Sobald Sie ausreichend Stack-Traces gesammelt haben (es ist einfacher, das Problem zu analysieren, wenn Sie mindestens 1000 nicht geschlossene Sitzungen haben), halten Sie die Instanz an und entfernen Sie den JVM-Parameter wieder. Die Protokolldatei (System-Out-Log oder error.log, je nach verwendeter Version) enthält die folgenden Meldungen, sowie die Stack-Traces:
- com.day.crx.core.CRXSessionImpl session# 193 opened
Führen Sie anschließend die angehängte JAR-Datei mit folgendem Befehl aus:
java -jar session_analyzer.jar <log_file> | sort > output.txt
Dadurch wird eine neue output.txt -Datei erstellt, die den Stack-Trace von nicht geschlossenen Sitzungen, sortiert nach Stack-Trace-Inhalten, enthält. Jede Stack-Trace ist eine Zeile und etwas komprimiert (wiederholte Präfixe werden entfernt). Die Sitzungs-ID befindet sich am Ende der Zeile.
Beispiel:
com.day.crx.j2ee.JCRExplorerServlet.login(JCRExplorerServlet.java:521) ResourceServlet.spoolResource(ResourceServlet.java:148) java.lang.Thread.run(Thread.java:595): session# 10023
Dieses Beispiel bedeutet, dass die Sitzung #10023 nicht geschlossen wurde und der Stack-Trace die angegebenen Zeilen enthielt, als die Sitzung geöffnet war.
Basierend auf dieser Ausgabe sollten Sie den Ort des defekten Codes finden und das Problem beheben. Falls Sie einen Fehler in unserem Productcorecode gefunden haben, senden Sie uns bitte ein Daycare-Ticket zusammen mit den oben angegebenen Informationen.
Gilt für
CRX 1.3.x- (bitten Sie um einen Patch, wenn Sie das Problem analysieren möchten)
CRX 1.4.x (für 1.4.0 müssen Sie den Hotfix im Anhang installieren)
CRX 2.x
Herunterladen
Herunterladen
Herunterladen