CRX/CQ プロセスは CPU の100%を使用し、システムは応答せず、またはシステムの速度が低下します

FAQ

高 CPU 消費を引き起こす一般的な条件は何ですか?

特定のメンテナンス作業では、通常より高い CPU 使用を引き起こす可能性があります:タールコンパクション、データストアのガーベージコレクタ、オンラインバックアップ、ツリーアクティベーション、キャッシュをクリアにするアプリケーションの更新の展開

0%CPU 消費量の理由にはどのようなものがありますか?

Java のデッドロックのレベルによってこのような状況が発生する可能性があります。この場合は、いくつかのスレッドダンプを使用してサポートチケットを増やし、AEM インスタンスを再起動します。

使用できるパフォーマンスのチューニングヒントはありますか?

解決策

ビデオジェム - テクニカルは深いダイブセッション

ビデオジェムセッションは以下のサイトで入手可能です http://dev.day.com/content/ddc/en/gems/cq-aem-5-6-troubleshooting.html

Adobe Experience Manager 5.6 以降および CRX2.3 以降

高 CPU 使用あるいは遅延が起こっている間、http://localhost:4502/system/console/profiler を最低数分間の間使用する出力は、どの JVM スレッドが最も多く CPU サイクル、そしてその関連パッケージおよびクラスを使用しているかの決定に役立ちます。

CRX2.2まで

CRX 2.0.x に含まれるシンプルな CPU プロファイリングツール使用それを開始し、開く

http://localhost:7402/crx/diagnostic/prof.jsp

CRX 1.x

問題を分析するに、スレッドダンプを作成します。それらのスレッドダンプは分析できます。Full Tread Dumps の作成

プロセス ID を取得

Java プロセスのプロセス ID を取得するには、使用する

jps -l

もしこれで解決しない場合(パスが設定されず、JDK がインストールされていない、Java のバージョンが古い)、これを使用

ps -el | grep java

Full Thread Dumps

パフォーマンスの問題またはブロックされているプロセスを分析するには、約1秒間ほどの遅延で、完全なスレッドダンプを約10個作成します。問題がクラスタリングに関連する可能性がある場合、各クラスターノードに少なくとも 10 個の完全なスレッドダンプを作成します。可能であれば、スレッドダンプがおおよそ同時に(完全に同時である必要はありません)に作成されます。

完全なスレッドダンプは、例えば次の情報から開始されます:

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

スレッドダンプが上記のようでない場合は、適切な検索を実行することはできません。

ページに記載されている手順に従って、パッケージシェアに記載されている「tool」を使用することもできます。Thread ダンプを提供します。これを使用すると、複数のスレッドダンプを取ることができ、上記の形式でダンプされます。

または、インストールされている場合は jstack を使用します。次のコマンドはスレッドダンプをプリントして、システムに出力します。

jstack <pid>

次のコマンドでは、完全なスレッドダンプをファイルに追加します。

jstack <pid> >> threadDumpNode1.txt

いくつかのシステムで以下を使用する必要がある場合があります: sudo -u aem jstack -J-d64 -l <pid>

これがうまくいかない場合は、kill-QUIT を使用します。次のコマンドではスレッドダンプをログファイルに出力します。

kill -QUIT <pid>
最後のコマンドによって、おそらくこれが java パラメーターに追加される:標準出力にスレッドダンプがない場合
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log
注意スレッドダンプを取得するための手順から次の手順が環境で正しく機能していない場合は、次の記事を参照注意:してください.

CPU 使用率の確認

問題を分析するには、CRX/CQ が実行中のループで実行されているか、あるいは単にスリープ状態なのかを知ることが重要です。これを検索するには、タイプする

top

このコマンドで、CPU 使用率でソートされたプロセスのリストを取得します。トッププロセスが Java プロセスで、PID が CRX/CQ に一致する場合、プロセスはフルスピードで稼動しています。

結果を解釈する方法が不明な場合は、次のステートメントを実行して、問題レポートに top.txt ファイルを含めます:

top -l5 -s5 > top.txt

セッション数を確認

多くの場合、問題はオープンセッションの数が大きすぎることです。ある地点で、処理が遅くなります。これが該当するかどうかを調べるには、稼動します

jps -l (Java プロセスを取得するためには)

jmap -histo <pid> | grep こ CRXSession (オープンセッションの数を得るため)

これはが、実際に問題(セッション数が数百セッションより多い) であり、分析する必要がある場合セッションプールが使用され (CRX / CQ のバージョンに応じて、特定の問題を解決するホットフィックスがある)、または内部 (おそらくアプリケーションレベル) のキャッシュがセッションを参照することが可能です。あれらのセッションがオープンされている場所を分析するには、「Analyze Unclosed Sessions」ページを参照してください。

プロセスを終了させない

CRX プロセスは決して終了させないでください。また、停止時間が長すぎる場合も終了させないてください。応答がないプロセスを終了させる必要がある場合は、完全なスレッドスタンプを作成し、バグを記録します。

CRX プロセスを終了させる場合、次にプロセスを起動したときに Tar PM 上での backup_.tar ファイルを作成することもできます

サポートツール

Thread Dump Collection and Analysis tool を使用して、以下のトラブルシューティングのために稼働中の CQ インスタンスからスレッドダンプを取得:
- パフォーマンス

- ロック競合

- デッドロック

- その他のスレッド関連の問題

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー