目的

この記事では、最も一般的な AEM の重大な問題とその分析方法について説明します。

AEM Sites のパフォーマンスの問題

パフォーマンスの問題の症状

  1. ページの読み込みが遅い
  2. ページの作成または編集が遅い
  3. AEM の応答時間が遅い
  4. 一部のリクエストに対して AEM が応答していない
  5. AEM に対する request.log で応答時間の遅延が示される

パフォーマンスの問題の原因

  1. スレッドの競合 - 遅い検索、重いバックグラウンドジョブの書き込み、サイトコンテンツの分岐全体の移動など、長く実行されるリクエスト。
  2. 高い CPU 使用率
  3. コストの高い検索、非効率的なアプリケーションコードやコンポーネントなど、コストの高いリクエスト。
  4. 適切なメンテナンスの不足
  5. 不十分なディスパッチャーのキャッシュ
  6. CDN の不足
  7. ブラウザーキャッシュの不足
  8. ページで読み込まれるスクリプトおよびページの最初に読み込まれるスクリプトが多すぎる
  9. HTML ヘッドではなく、ページ全体にわたって CSS が読み込まれる
  10. 不十分なサーバーのサイズ設定または誤ったアーキテクチャ
  11. メモリの問題(以下を参照

パフォーマンスの問題の分析方法

1. 一連のスレッドダンプをキャプチャしてそれらを分析する

2. AEM Java プロセスがCPU 使用率を高めていないか、OS レベルで確認する

    Linux:top コマンドを使用して CPU 使用率を確認します。

    Windows:Windows タスクマネージャーを使用します。

    AEM が高い CPU 使用率の原因の場合は、そのまま使用できるプロファイリングツールを数分間実行して、結果を分析します。

3. すべての遅いリクエストについて request.log ファイルを分析する

4. システムメンテナンス手順を確認して、以下を含め、AEM に対して適切なメンテナンスをおこなっていることを確認する

  • リビジョンのクリーンアップ(MongoMK および Database DocumentNodeStore のみ)- 毎日またはより頻繁に
  • オフライン Tar 圧縮(TarMK のみ)- 隔週
  • データストアのガベージコレクション(FileDataStore または S3 DataStore を含むシステムのみ)- 毎週
  • ワークフローのパージ - 毎週
  • バージョンのパージ - 毎週
  • 監査ログのパージ - 毎週

AEM のメンテナンスについて詳しくは、この記事を参照してください。

5. AEM Dispatcher レベルで実装されたキャッシュ戦略を確認する。 開始に最適な場所は、Dispatcher がファイルをキャッシュする方法とタイミングおよびキャッシュしたファイルを無効にする方法とタイミングを理解することでわかります。

6. サイトのキャッシュを確認する。

7. Google Chrome ブラウザーの Developer Tools(デベロッパーツール)パネルにある Audits(監査)機能などの、クライアントサイドのサイト分析ツールを使用する。 これらのツールにより、クライアント側のパフォーマンスの向上に関する推奨情報が得られます。

一般的なパフォーマンスの問題の解決策

AEM Assets のパフォーマンスの問題

Assets のパフォーマンスの問題の症状

  • /assets.html や /damadmin UI へのファイルのアップロードが遅い
  • サムネールが長すぎて生成できない
  • 移動、削除、編集、メタデータの更新などの Assets の操作に時間がかかり過ぎる

Assets のパフォーマンスの問題の原因

  • 適切なメンテナンスの不足
  • 最新の Fix Pack が適用されていない
  • 最適化が適用されていない
  • ユーザー負荷に対して不十分なサーバーのサイズ設定

Assets のパフォーマンスの問題の分析方法

一般的な Assets のパフォーマンスの問題の解決策

メモリの問題

メモリの問題の症状

  • AEM がランダムにキャッシュし、ログには OutOfMemoryError が確認される
  • AEM が時間の経過と共に遅くなり、最終的にクラッシュする
  • AEM が応答しない

メモリの問題の診断

  • ログファイルで OutOfMemoryError を検索し、見つかった場合はメモリの問題が発生している
  • http://aem-host:port/system/console/memoryusage screen
    を確認する。「Old Generation」(JDK 7 以前)または「Tenured Generation」(JDK8 以降)の使用率が高い場合、ヒープメモリ使用率の問題の兆候である可能性があります。 「ガベージコレクターを実行」をクリックして、JVM に完全なヒープのガベージコレクションをリクエストします。 GC のリクエスト後もヒープ使用率が高いままの場合、問題が発生している可能性があります。 Oak Tar ストレージを備えた AEM インスタンスで、調整された使用率が 3 GB を超える場合、問題が発生している可能性があります。 Mongo ストレージを備えたシステムでの高いヒープ使用率は、メモリ内キャッシュ設定が原因である可能性があります。
  • スレッドダンプおよび top の出力を取得して、スレッド分析を実行する。 高い CPU 使用率の原因となっているスレッドが、ネイティブ JVM Garbage Collection スレッドであるかどうかを確認します。 ほとんどの CPU 時間を使用しているスレッドが「VM スレッド」または任意のガベージコレクションスレッドである場合、メモリの問題である可能性があります。

メモリの問題の原因

  • Java アプリケーションのメモリリーク
  • カスタムコードでのファイナライズの間違った使用による Java Finalizer の停滞
  • 不十分な最大ヒープ設定

メモリの問題の原因分析方法

ヒープダンプのキャプチャ方法について詳しくは、この記事を参照してください。

メモリの問題の原因を特定する最善の方法は、ヒープダンプを分析することです。 

ヒープダンプファイルをキャプチャしたら、Eclipse MAT または IBM Memory Analyzer ツールで開きます。 Eclipse MAT で、Leak Suspects レポートを実行し、「Thread Details」ビューを開いて、メモリの問題の潜在的な原因を確認します。

一般的なメモリの問題の解決策

  • ガベージコレクションの長時間の一時停止に気付いたら、メモリ使用率を減らすようにアプリケーションコードを最適化します。 ほとんどのガベージコレクションの問題は、JVM を調整するよりもアプリケーションを最適化することで、適切に解決できます。
  • 既にアプリケーションを最適化しているのに GC の長い一時停止が発生する場合は、JVM の調整に注力します。

AEM インデックス作成の問題

インデックス作成の問題の症状

以下は、AEM/Oak インデックス作成に問題があることの兆候です。

  • 検索結果に 10 分以上かかって期限切れになる
  • 検索結果に不足がある
  • サイト UI を使用した検索、Query Builder 検索、JCR クエリ実行の間に、UI またはログにエラーが返される
インデックス作成の問題の診断
  • 非同期インデックス作成が遅いまたは失敗していることを確認するには、以下の手順を実行します。

1. AEM インスタンスで以下の URL を開いて、非同期インデクサーの状態を表示する

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats  - この URL は AEM6.2 以降にのみ適用されます

2. これらの各ページで、以下のフィールドを確認する

FailingSince - これは、インデックス作成が最初に失敗し始めた時間を示します。

LastError - これは、インデックス作成に失敗した原因を示すスタックトレースです。 これが空の場合、インデックス作成は失敗していません。

LastErrorTime - これは、インデックス作成で最後にエラーがスローされた時間を示します。

LastIndexedTime - このフィールドの日時が 5 分以上古い場合、インデックス作成は遅くなり始めています。

インデックス作成の問題の原因

  • 不適切なメンテナンスや、リビジョンガベージコレクション、ワークフローのパージ、監査のパージ、バージョンのパージなどの、メンテナンスの実行の失敗
  • Tar ストレージでのセグメントの破損または不足
  • クラスター環境でのリビジョンの破損(DocumentNodeStore - Mongo または Database)
  • クラスター環境のクラスタートポロジの問題

インデックス作成の問題の原因分析方法

  • インデックス作成の問題の分析および修正については、この記事を参照してください。

レプリケーションの問題

レプリケーションの問題の症状

  • 公開リクエストがレプリケーションエージェントキューに格納されている
  • 公開されたコンテンツが公開サーバー上で表示されない
  • システムパフォーマンスへの影響

レプリケーションの問題の原因:

  • レプリケーションエージェントが正しく設定されていないので、公開エージェントに接続できない。
  • レプリケーション時にエラーが発生した結果、レプリケーションキューの動作が停止した。
  • システムの動作が遅いので、レプリケーションの処理に時間がかかっている。
  • レプリケーションがカスタムワークフローの一部として実行されており、ワークフロー処理に問題がある。

レプリケーションの問題の分析方法:

1. レプリケーションキューのステータスを確認します。

        アクティブ:項目が処理されている状態。
        アイドル:キューが空の状態。
        ブロック:項目がキューにあるけれども処理できない状態。例えば、ダウンしているホストや存在しないホストをエージェントが指しているとき。

2. サーバーがコピーされているか、エージェントが最近設定されている場合は、レプリケーション設定を確認します。詳しくは、こちらを参照してください。 
     
3. レプリケーションエージェントのログを確認します(http://host:port/etc/replication/agents.author/AgentName.log.html#end)。  項目を特定できない場合は、このログを収集して AEM サポートに提出してください。

4. サーバーの error.log を確認します(AEMinstall/crx-quickstart/logs)。項目を特定できない場合は、このログを収集して AEM サポートに提出してください。

5. レプリケーションキューが「アイドル」状態で、上記のいずれも該当しない場合、この問題の原因として最も可能性が高いのはワークフローです。ワークフローが処理されないと、レプリケーション項目はレプリケーションキューに到達しません。ワークフローのステータスを監視するには、ワークフローダッシュボードで、実行中のワークフローインスタンスの数を確認します。ワークフローの管理については、こちらを参照してください。

6. システムが高負荷状態になっているときやその他のパフォーマンスの問題が発生していると、レプリケーションに時間がかかります。

一般的なレプリケーションの問題の解決策:

1)レプリケーションキューの問題を確認します
2)ワークフローが効率的に実行されていないことが原因で問題が発生している場合は、同時ワークフロー処理に関するヒントを確認してください
3)全体的な AEM のパフォーマンス低下およびレプリケーションに関連する問題については、AEM のパフォーマンスの問題を参照してください

TarMK の破損の問題

TarMK の破損の症状

  • インスタンスがオフライン圧縮後に動作不能になる。
  • インスタンスが起動中状態のままになる。
  • ログファイルまたは圧縮コマンドの出力に SegmentNotFoundException が報告される。

破損の問題の原因

  • セグメントが手動操作(例えば、rm -rf)によって削除された。   
  • セグメントがリビジョンガベージコレクションによって削除されたか、コードのバグが原因でセグメントが見つからない。   
  • コードのバグが原因でセグメントが見つからない。
  • 各種のメンテナンスタスクが予定どおりに実行されていないことが原因でリポジトリが肥大化し、ディスク領域が少なくなっている。
  • java プロセスを終了して AEM を強制的に停止している。

リポジトリの破損の問題の診断:

  • error.log ファイルを調べて、SegmentNotFoundException または IllegalArgumentException が発生しているかどうかを確認します。
  • セグメントがリビジョンガベージコレクションによって削除されたかどうかを調べるには、org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC(デバッグログを有効にする)ロガーの出力を確認します。このロガーは、クリーンアップフェーズで削除されたすべてのセグメントのセグメント ID を記録します。問題のあるセグメント ID がこのロガーの出力に表示されている場合にのみ、リビジョンガベージコレクションが例外の原因です。    
  • 外部データストアが破損している場合は、ログファイル内でエラー「Error occurred while obtaining InputStream for blobId」の出現箇所をすべて検索します。このエラーは、AEM データストアディレクトリのファイルが見つからないことを意味します。

修復の破損の問題の解決策:

  • oak-run の check run-mode を使用して、セグメントストアの整合性のある最も新しいリビジョンを確認します。  破損しているセグメントストアを手動で整合性のある最も新しいリビジョンに戻します。この操作により、Oak リポジトリが以前の状態に戻ります。  この操作を実行する前に、リポジトリを完全にバックアップする必要があります。
    • To performcheckと復元を実行するには、この記事に説明されている手順を実行してください。
    • check が「ConsistencyChecker - 整合性のあるリビジョンが見つかりません」で失敗する場合は、この記事のパート B の手順を実装します。
  • 既にデータストアを使用していて、エラー「Error occurred while obtaining InputStream for blobId」が発生する場合、データストアにファイルが不足していることが原因としてはじめに考えられます。 この記事に従って問題を解決してください。
  • データストアを使用していない場合は、外部ファイルの S3 または Azure データストアを、デフォルトのセグメントストアの代わりに使用します。.
    • データストアを使用すると、パフォーマンスが向上します。
    • crx2oak を使用して、データストアを使用するインスタンスに移行します。
  • 最新のサービスパック、Cumulative Fix Pack および Oak Cumulative Fix Pack を適用します。

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

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