目的

* 次の情報は、Oak バージョン 1.6 以降および AEM 6.3 以降に当てはまります。

問題
利用可能なメモリ(オフヒープおよびオンヒープ)には限りがあるので、インスタンスのリポジトリが一定量に達すると、キャッシュがオーバーロード状態になります。
その結果、大部分のリポジトリアクセスでディスクから直接データを読み取るので、非常に時間がかかり、エンドユーザーのエクスペリエンスが悪化します。

症状
全体的にインスタンスの動作が遅くなります。応答が遅くなってオンラインのリビジョンクリーンアップの所要時間が大幅に長くなり、割り当てられているメンテナンス期間を超過することもあります。
システムレベルでは、IO アクティビティの負荷が持続的に高くなります。

手順

トラブルシューティング

システムが IO バウンドの状態になった場合に、監視対象となるエンドポイントは複数あります。
以降では、利用可能なエンドポイントと主な指標について解説します。

エンドポイントの監視

AEM、JVM、OS で IO 関連の指標を監視する際のエンドポイントには、様々なものがあります。 

それぞれのエンドポイントは、TarMK でコミットする JCR セッションや TarMK のディスク IO など、様々なレイヤーで、システム内の全体的なスループットに関する異なる情報を提供します。

これらの情報を、JVM および OS レベルのツールを使用して収集した情報と組み合わせることで、システムの状態を多角的に分析して問題点を突き止めることができます。

rtaImage
  • 各セッションでは、セッションでの読み取りおよび書き込みの回数と速度などのカウンターを含む SessionMBean インスタンスが公開されます。
  • RepositoryStatsMBean は、オープンなセッション数、セッションのログイン率、すべてのセッションでの全体的な読み取りおよび書き込み負荷、すべてのセッションでの全体的な読み取りおよび書き込みタイミング、クエリおよび観測の全体的な負荷とタイミングを監視するためのエンドポイントを公開します。
  • SegmentNodeStoreStatsMBean は、コミット(コミットの回数および割合、待機中のコミット数、待機時間)を監視するためのエンドポイントを公開します。
  • FileStoreStatsMBean は、ディスクに書き込まれたデータ量、ディスク上の tar ファイルの数、ディスク上の合計フットプリント数を示すエンドポイントを公開します。

これらのエンドポイント以外にも、次のように、システムがビジー状態になっている原因に関する詳細なインサイトを確認できる JVM や OS 固有のツールが多数あります。

  • Java Mission Control(jmc)は、JVM の実行に関するあらゆるパフォーマンスデータを収集できる便利なツールです。Java プロセスごとの IO を記録できる機能が非常に有用なケースもあります。
  • コマンドラインツールの jstat、jstack および jmap は、それぞれ JVM のガベージコレクター、JVM のスレッドおよび JVM のヒープの詳細を確認する際に便利です。
  • OS レベルのツールの vmstatiostat を利用すると、オペレーティングシステムレベルで IO および CPU 使用量を確認できます。

ディスク IO の監視

説明:時間単位(秒)あたりのディスク処理(読み取り/書き込み)の回数

方法:OS レベルのツール(UNIX の vmstat、iostat など)

通常:ディスクの読み取りレベルが低く(ゼロに近い)、常に書き込み回数が少ない(画像を参照)。リビジョンのクリーンアップ時にピークに達します。

警告:ディスクの読み取りのレベルが高くなり、上昇を続けていると、メモリのアンダーサイジングが疑われます(画像を参照)。

例外:ディスク IO のボリュームが大きくなるのは、AEM で実行中の他の処理(アセットの統合など)や、別のプロセス(ウイルススキャンなど)が原因です。そのため、その他の原因は除外してからセグメント Tar を原因として診断を実行します。一般的に、数日間にわたる傾向の方が局所的なピークよりも重要です。

rtaImage

注意:

この場合、絶対値は重要ではなく、インスタンスのサイズ、トラフィック、基盤となるハードウェアによって変わります。

CPU の監視

  • 説明:IO の待機をはじめとする様々な処理に CPU が費やした時間。
  • 方法:OS レベルのツール(UNIX の vmstat など)。このデータを確認できないツールもあります(top など)。
  • 通常:CPU はほとんどの場合、ユーザーレベルでアプリケーションによって使用され、IO 待機の割合は低くなります。
  • 警告:CPU のサイクルの大部分が IO 待機に費やされており、それが増加傾向にあり、ユーザーアプリケーションに悪影響が生じている場合です。
  • 例外:CPU のディスク IO 待機の割合が大きくなるのは、AEM で実行中の他の処理(アセットの統合など)や、別のプロセス(ウイルススキャンなど)が原因です。そのため、その他の原因は除外してからセグメント Tar を原因として診断を実行します。一般的に、数日間にわたる傾向の方が局所的なピークよりも重要です。
rtaimage_1_

コミットキューの監視

  • 説明:コミットキューは、コミットの受信ボリュームが処理速度を上回ったときに、セグメント Tar によって使用されるバッファーメカニズムです。
  • 方法:リアルタイムのコミットキューのサイズは、JMX MBean の org.apache.jackrabbit.oak の COMMIT_QUEUE_SIZE(指標)によって公開されます(/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUE_SIZE%2Ctype%3DMetrics)。システムコンソールから http を介してアクセスするか、JMX クライアントを使用してアクセスします。
  • 通常:キューが空(サイズがゼロ)の場合はシステムが正常な状態で、受信後に待機時間なしですべてのコミットを処理できます。局所的なピークが高速で処理される場合も通常の状態です。
  • 警告:キューが常にゼロ以外で増加傾向にある場合は、セグメント Tar が受信後に待機時間なしでコミットを処理できていません。キューの空き容量がなくなり、新しいコミットが拒否される恐れがあります。
  • 例外:キューの使用率が一時的に高く(ピークに)なるのは、負荷の高い処理(レプリケーションやロールアウトなど)が実行されているか、トラフィックが多いことが原因です。そのため、その他の原因は除外してからセグメント Tar を原因として診断を実行します。一般的に、傾向の方が局所的なピークよりも重要です。
rtaImage

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

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