ドキュメントExperience Cloud KCS

AEMの一般的な重大な問題の分析方法

最終更新日： 2026年6月24日

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

説明 description

環境

Adobe Experience Manager（AEM）

問題/症状

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

  • AEM Sites Performance
  • AEM Assets Performance
  • メモリの問題
  • インデックス作成の問題
  • レプリケーションの問題
  • 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を使用するシステムのみ） – 毎週
    • ワークフローのパージ – 週単位
    • バージョンのパージ – 毎週
    • AuditLog Purge – 毎週

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

  6. サイトの​ キャッシュ ​を確認してください。

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

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

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 ストレージを備えたシステムでのヒープ使用率が高い原因は、メモリ内キャッシュ設定が原因である可能性があります。

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

メモリの問題の原因

  • Java アプリケーションのメモリリーク
  • カスタムコードでのファイナライズの誤った使用によるJava ファイナライザーの積み重ね
  • 不十分な最大ヒープ設定

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

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

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

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

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

  • ガベージコレクションが長い場合は、アプリケーションコードを最適化してメモリの使用量を減らします。 ほとんどのガベージコレクションの問題は、アプリケーションの最適化とJVMのチューニングによって解決できます。
  • 既にアプリケーションを最適化しており、引き続きGCの一時停止が長い場合は、JVMの調整に集中してください。

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

インデックス作成に関する問題の症状

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

  • 検索結果が10分以上古くなっている
  • 検索結果がありません
  • エラーは、サイト UI、クエリビルダー検索、またはJCR クエリ実行を介した検索時に、UIまたはログで返されます

インデックス作成の問題を診断しています

非同期インデックス作成が遅いか、失敗しているかを確認するには、次の操作を行います。

  1. AEM インスタンスで次のURLを開いて、非同期インデクサーに関する統計を表示します。http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%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またはデータベース）
  • クラスター環境でのクラスタトポロジの問題

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

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

レプリケーションの問題

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

  • パブリッシュ要求は、レプリケーションエージェントキューでキューに登録されています
  • 公開されたコンテンツが公開サーバーに表示されない
  • システムパフォーマンスへの影響

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

  • レプリケーションエージェントが正しく設定されておらず、パブリッシュエージェントに接続できません
  • レプリケーション時にエラーが発生し、レプリケーションキューが停止する
  • システムの処理速度が遅く、レプリケーションの処理が遅い
  • レプリケーションはカスタムワークフローの一部として実行されており、ワークフロー処理に問題があります。

レプリケーションの問題を分析する方法：

  1. レプリケーションキューstatusを確認します。

    アクティブ：項目が処理中です。

    キューが空の場合、 アイドル：。

    ブロックされました：。アイテムがキュー内にあるが、処理できません。例えば、エージェントがダウンしているホストまたは存在しないホストを指している場合などです。

  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実行モードを使用して、セグメントストアの最後の既知の正常なリビジョンを決定します。 破損したセグメントストアを手動で最新の適切なリビジョンに戻します。 この操作を実行すると、Oak リポジトリが時間内に以前の状態に戻ります。 この操作を実行する前に、リポジトリを完全にバックアップする必要があります。

recommendation-more-help
experience-cloud-kcs-help-kbarticles