ドキュメント

AEMに関する一般的な重大な問題の分析方法

Last update: Tue Oct 14 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

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

説明 description

環境

Adobe Experience Manager（AEM）

問題/症状

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

  • AEM Sitesパフォーマンス
  • AEM Assetsパフォーマンス
  • メモリの問題
  • インデックス作成の問題
  • レプリケーションの問題
  • TarMK 破損の問題

解決策 resolution

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

パフォーマンス上の問題の兆候

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

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

  1. スレッド競合：検索が遅い、大量の書き込みを行うバックグラウンドジョブがある、サイトコンテンツのブランチ全体が移動しているなど、長時間実行されるリクエスト。
  2. CPUの使用率が高い
  3. 高価な検索や非効率的なアプリケーションコード、コンポーネントなどの高価なリクエスト。
  4. 適切なメンテナンスの欠如
  5. 不十分な Dispatcher キャッシュ
  6. CDN の欠如
  7. ブラウザーのキャッシュがない
  8. ページに読み込まれ、ページの先頭に読み込まれたスクリプトが多すぎます
  9. HTMLの先頭ではなくページ全体に読み込まれる CSS
  10. サーバーのサイズが不十分であるか、アーキテクチャが正しくありません
  11. メモリの問題（後述）

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

  1. ​ 一連のスレッドダンプをキャプチャ ​ し ​ 分析します ​。

  2. AEM Java プロセスによってCPUの使用率が高くなっているかどうかを OS レベルで確認する：AEMによってCPUの使用率が高くなっている場合は、標準のプロファイリングツールを数分間実行して結果を分析します。

    • Linux:top コマンドを使用して、CPUの使用率を確認します。
    • ウィンドウ：Windows タスク マネージャを使用します

  3. ​ 処理に時間のかかる要求がないか request.log ファイルを分析します ​。

  4. システムメンテナンス手順を確認します。 AEMのメンテナンスの詳細と、AEMで次のような適切なメンテナンスを実行していることを確認するには、この ​ 記事 ​ を参照してください。

    • リビジョンのクリーンアップ（MongoMK とデータベース DocumentNodeStore のみ） – 日単位または高頻度
    • オフライン Tar 圧縮（TarMK のみ） – 隔週
    • データストアのガベージコレクション（FileDataStore または S3 DataStore を使用するシステムのみ） – 毎週
    • ワークフローのパージ – 毎週
    • バージョンのパージ – 毎週
    • 監査ログのパージ – 毎週

  5. AEM Dispatcher レベル ​ で実装されたキャッシュ戦略を確認します。

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

  7. Google Chrome ブラウザーの 開発者ツール パネルの Audits 機能などの、クライアントサイドのサイト分析ツールを使用します。 これらのツールは、クライアントサイドのパフォーマンスの向上に関する推奨事項を提供します。

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

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

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

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

Assetsのパフォーマンスに関する問題の原因

  • 適切なメンテナンスの欠如
  • 最新の修正パックが適用されていません
  • 最適化が適用されていません
  • ユーザー負荷に対するサーバーのサイズが不適切です

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

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

メモリの問題

メモリの問題の症状

  • AEMがランダムにクラッシュし、ログに OutOfMemoryError が記録されます
  • AEMは時間の経過と共に速度が低下し、最終的にはクラッシュします
  • AEMが応答しない

メモリの問題の診断

  • OutOfMemoryError のログ ファイルを検索します。一致するファイルが見つかった場合は、メモリの問題があります

  • http://aem-host:port/system/console/memoryusage 画面を確認します。

    「旧世代」（JDK 7 以前）または「テニュアード世代」（JDK8 以降）の使用率が高い場合、これはヒープメモリ使用率の問題の兆候である可能性があります。 「ガベージコレクターを実行」をクリックして、フルヒープガベージコレクションを実行するように JVM にリクエストします。 GC をリクエストした後も高いヒープ使用率が高いままの場合、問題が発生する可能性が高くなります。 Oak Tar ストレージを使用しているAEM インスタンスで、使用時間が 3 GB を超えている場合は、問題が発生している可能性があります。 Mongo ストレージを持つシステムのヒープ使用率が高い原因は、メモリ内キャッシュ設定が原因である可能性があります。

  • ​ スレッドダンプと top 出力を取得し ​ ​ スレッド分析 ​ を実行します。 CPUの高使用率を引き起こしているスレッドが、ネイティブの JVM ガベージコレクションスレッドであるかどうかを確認します。 最もCPU時間を使用しているスレッドが「VM スレッド」または任意のガベージコレクションスレッドの場合、メモリの問題が発生している可能性があります。

メモリの問題の原因

  • Java アプリケーションのメモリリーク
  • カスタムコードで最終処理が間違って使用されているため、Java Finalizer が累積する
  • 最大ヒープ設定が不十分です

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

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

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

ヒープダンプファイルをキャプチャしたら、Eclipse MAT または IBM Memory Analyzer ツールで開きます。 Eclipse MAT で「Leak Suskes」レポートを実行し、「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. AEMinstall/crx-quickstart/logs で公開されているサーバー error.log を確認します。特定できない場合は、このログを収集し、AEM サポートに提供します。

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

  6. システムに高い負荷がかかっている場合や、他のパフォーマンス上の問題が発生している場合は、レプリケーションの速度が低下します。

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

  1. ​ レプリケーションキューの問題を確認 ​。
  2. ワークフローが効率的に実行されていないことが原因で問題が発生している場合は、同時実行の ​ ワークフロー処理のヒント ​ を確認してください。

TarMK 破損の問題

TarMK 破損の症状

  • オフライン圧縮の後、インスタンスは操作できません。
  • インスタンスが 起動中 状態でスタックしました。
  • ログファイルまたはコンパクションコマンドの出力レポート SegmentNotFoundException。

破損の問題の原因

  • セグメントは手動操作（rm -rf など）によって削除されます。
  • リビジョンのガベージコレクションによってセグメントが削除されたか、コードのバグが原因でセグメントが見つからない。
  • コードのバグが原因でセグメントが見つからない。
  • リポジトリの増加やディスク領域の減少につながる様々なメンテナンスタスクが時間通りに実行されない。
  • Java プロセスを強制終了して、AEMを強制的に停止しています。

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

  • error.log ファイルを確認し、SegmentNotFoundException または IllegalArgument Exception があるかどうかを確認します。
  • セグメントがリビジョンガベージコレクションによって削除されているかどうかを判断するには、org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC （デバッグログを有効にする）ロガーの出力を確認します。 このロガーは、クリーンアップフェーズで削除されたすべてのセグメントのセグメント ID をログに記録します。 問題のセグメント ID がそのロガーの出力に表示される場合にのみ、そのロガーはリビジョンのガベージコレクションであり、例外の原因となります。
  • 外部データストアが破損している場合は、すべてのエラー blobId の InputStream の取得中にエラーが発生しました をログファイルで検索します。 このエラーは、AEM データストアディレクトリにファイルがないことを意味します。

破損の問題を修復するソリューション：

  • oak-run の check run-mode を使用して、セグメントストアの整合性のある最も新しいリビジョンを確認します。 破損しているセグメントストアを整合性のある最も新しいリビジョンに手動で戻します。 この操作を実行すると、Oak リポジトリが以前の状態に戻ります。 この操作を実行する前に、リポジトリを完全にバックアップする必要があります。

  • データストアを使用していない場合は、デフォルトのセグメントストアの代わりに、外部ファイル（S3 または Azure データストア）を使用します。

    • データストアを使用すると、パフォーマンスが向上します。
    • crx2oak を使用してインスタンスをデータストアを持つインスタンスに移行します。

  • 最新のサービスパックおよび累積修正パックとOak累積修正パックを適用します。

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f