Unclosed セッションの分析

現象

次の条件を満たす場合は、CRX のセッションが原因で問題が発生する可能性があります。

• システムがますます低速になる
• 時々、システムは重症度によりメモリ不足（数時間後、数時間または数週間など）になります。
• CRX の以前のバージョン：ログファイルの「CacheManager : resizeAll」エントリの多くがログファイルに含まれています（size = size sessions はキャッシュ数が少ないため、いくつかキャッシュを開けます）。

原因

アプリケーションが CRXSessions explicitely を開いた場合は、これらのセッションの適切なクローズを確保するために開発者が必要となります。そうでない場合、このようなセッションはガベージコレクションの対象外であり、メモリ内に保持されます。各 CRXSession は、リソースの消費に追加される独自のキャッシュセットを作成および維持します。

分析

閉じていないセッションでの実際の問題を正確に表示するには、メモリ内に保持される期間が現在の CRXSessions の全体的な数字を判別続行コマンドを実行します。

• jmap -histo:live <pid> | grep CRXSessionImpl

出力の 2 番目の列はインスタンス数です。つまり、多くのセッションは閉じられず、実際にメモリが解放されます。この数値が100よりも大きい場合、アプリケーションの CRXSessions に問題があります。

ガベージコレクションの待機を待機しているメモリ不足オブジェクトの数を確認するには、次のコマンドを実行します。

• jmap -histo <pid> | grep CRXSessionImpl

前のコマンドと同様に、2 番目の列はインスタンス数です。  これにより、メモリ内にあるオブジェクト数、またはまだガベージコレクションされていないメモリオブジェクトの数がわかります。  この数は、前の数に対し、アプリケーションで CRX セッションを開いて終了しているかどうかをユーザーが確認するかどうかを示すものです。

CRX2.3を実行している場合は、CQ5.5http://<host>:<port>/system/console/memoryusage に移動して jvm の完全なガベージコレクションを強制することができます。ガベージコレクターおよび「実行」ボタンをクリックします。  これを実行した後は、上記のコマンドを数回実行して、セッションオブジェクトの数がどのくらい速くなるかを確認できます。  これにより、アプリケーションが開かれている場合や、アプリケーションが多数のセッションを開いたり、gc 設定を調整したりする場合に役立ちます。  通常、これが問題である場合は、実際には大きい jvm ガベージコレクションがリポジトリに保存操作中に時間がかかるパフォーマンスを一時的に停止することがわかります。

注意：jmap コマンドラインアプリケーションには java JDK が付属しており、jdk ホーム bin の bin ディレクトリがあります。

解決策

この問題を解決するには、実際に CRXSessions を開いて最適なパフォーマンスを得るために、さらに分析を行う必要があります。1.4.1以降、CRX は不具合から情報を取得できるビルトインデバッグモードが用意されています。この debug-mode は、basically が openend されるたびに standard-out を完全に logfile するための dump です。また、CRXSession が再度閉じられるたびにエントリもログに記録されます。

セッションの debug-mode を有効にするには、CRX の起動時に次の JVM パラメーターを追加します。

• -Dcrx.debug.sessions=true

注意：システムの使用により、ログファイルは非常に高速になる可能性があります。

Quickstart を使用する場合、- nofork オプションを使用してシステムプロパティが使用されるようにする必要があります。

十分な stacktraces で少なくとも1000つのセッションが閉じられていない(解析が容易雑誌)を収集したら、インスタンスを停止し JVM パラメーターをもう一度削除してください。使用しているバージョンに応じてログファイル（システムのログアウトログまたは error.log）には次のメッセージが含まれます。

• com.day.crx.core.CRXSessionImpl session# 193 opened

次に、次のコマンドを使用してタグ付けされた JAR ファイルを実行します。

• java -jar session_analyzer.jar <log_file> | sort > output.txt

これにより、セッションが閉じてスタックトレースを含むスタックトレース Content で分類された新しいファイル output.txt という名前のプロパティが生成されます。各スタックトレースは 1 行で、「圧縮」のビット（繰り返しプレフィックスが削除されます）。セッション ID は行の末尾にあります。

次に例を示します。

com.day.crx.j2ee.JCRExplorerServlet.login(JCRExplorerServlet.java:521) ResourceServlet.spoolResource(ResourceServlet.java:148) java.lang.Thread.run(Thread.java:595): session# 10023

この例では、セッション#10023が閉じられていない状態で、セッションを開いたときに、スタックトレースが特定の行が含まれていたことを意味します。

この出力に基づいて、defect の場所を見つけて問題を修正することができます。製品コアコードの欠陥が発見された場合は、上記の情報とともに Daycare チケットを送信してください。

適用

CRX 1.3.x（問題を分析する必要がある場合は、パッチを確認してください）
CRX 1.4.x（添付の hotfix をインストールする必要があります）
次の CRX2.x