このページは、AEM 6.x のリポジトリの異なるメンテナンス操作のための、統合された関連する詳細を提供することを目的としています。

目的

この記事では、AEM 6.x の様々なメンテナンスクティビティに関する詳細を提供します。AEM Oak リポジトリメンテナンスは、効率なシステムを保存するために非常に重要です。メンテナンス不足により、不安定さ、パフォーマンスの問題、およびディスク容量不足が生じます。

Oak Tar SegmentNodeStore のメンテナンス

Oak Mongo ストレージメンテナンス

バイナリファイル (BLOB ストア、またはデータストア) メンテナンス

ワークフローパージメンテナンス

バージョンパージメンテナンス

Lucene バイナリクリーンアップ

オーディットログパージメンテナンス

AEM 6.x インスタンスのメンテナンスアクティビティ

Oak Tar SegmentNodeStore のメンテナンス

 SegmentNodeStore は、AEM に付属するデフォルトの Oak ストレージ機構です。この保持層は、データを、crx-quickstart/repository/segmentstore の下にある tar ファイルへ書き込みます。ストレージは append-only 形式なので、コンテンツが作成、更新または削除されると、segmentstore フォルダーのファイルのみが大きくなります。これにより、時間の経過とともに、AEM のパフォーマンスと安定性に影響する可能性があります。ディスク容量を再要求し、パフォーマンスを改善するには、tar 圧縮のメンテナンス(「Revision Cleanup」)を実行する必要があります。  リビジョンクリーンアップは、オフライン(AEM が停止中)とオンライン(AEM が実行中)のどちらでも実行されます。ただし、オンラインクリーンアップは、AEM 6.3 以降のバージョンによる使用のみ問題はありません。AEM バージョンの関連マニュアルを参照してください。

圧縮オンラインとオフラインの比較

次の表に、オンラインとオフラインのリビジョンクリーンアップの相違点を簡単に示します。

オフラインの圧縮 オンライン圧縮
AEM 6.0 ~ 6.3 6.3 以降のバージョン
必要なダウンタイム ダウンタイム無し
古いリビジョンをすべてクリーンアップ 前回のオンライン圧縮実行
より前のリビジョンをクリーンアップする
完了するには実行する必要があります メンテナンスウィンドウ中に実行する
高速で実行する システムのアクティビティによってパフォーマンスが制限される
2 週間に 1 回実行することを推奨します 毎日実行する(デフォルト:午前 2 時~午前 5 時)

AEM のバージョン 6.0 から 6.2 では、オンラインリビジョンクリーンアップを無効にする必要があります。無効にするための手順については、この記事を参照してください。さらに、オフラインクリーンアップが失敗するという既知のシナリオがあります。こうした問題を回避し、オフラインの圧縮のパフォーマンスを向上させるためには、この記事を参照してください。

推奨スケジュール

AEM6.0 から AEM6.2 では、オフライン圧縮を隔週で実行することをお勧めします。  AEM6.3 では、オフラインの圧縮は必要ありません。  代わりに、毎日午前 2 時から午前 5 時に実行(デフォルト)することをスケジュールされたオンライン圧縮を監視することをお勧めします。

サンプルログ出力

ここでは、リビジョンクリーンアップの正常な実行のサンプルログメッセージを示します。

 

AEM6.2/Oak のオフラインリビジョンクリーンアップ:

Apache Jackrabbit Oak 1.4.13​
Compacting crx-quickstart/repository/segmentstore​
    before ​
        Fri Oct 14 12:19:30 EDT 2016, data00000a.tar​
        Wed May 17 10:37:46 EDT 2017, data00001b.tar​
        Fri Oct 14 12:20:22 EDT 2016, data00002a.tar​
............​
        Wed May 17 10:37:45 EDT 2017, data00011b.tar​
        Sun Jul 16 16:12:39 EDT 2017, journal.log​
        Fri Oct 14 12:19:24 EDT 2016, repo.lock​
    size 7.7 GB (7712731491 bytes)​
    -> compacting​
    -> cleaning up​
    -> removed old file data00074a.tar​
    -> removed old file data00073a.tar​
    -> removed old file data00072a.tar​
….…​
    -> removed old file data00018b.tar​
    -> writing new journal.log: a838c3e9-613f-4095-abba-939c437882e7:59384 root​
..
..
after ​
        Fri Oct 14 12:19:30 EDT 2016, data00000a.tar​
        Wed May 17 10:37:46 EDT 2017, data00001b.tar​
        .............​
        Wed May 17 10:37:46 EDT 2017, data00003b.tar​
        Wed May 17 10:37:45 EDT 2017, data00004b.tar​
       Mon Jul 17 11:11:28 EDT 2017, journal.log​
        Fri Oct 14 12:19:24 EDT 2016, repo.lock​
    size 6.4 GB (6385295920 bytes)​
    removed files [data00057a.tar, data00065a.tar, data00020b.tar, data00018b.tar, data00050b.tar, data00073a.tar, data00058a.tar, data00069a.tar, data00060a.tar, data00063a.tar, data00074a.tar, data00066a.tar, data00055a.tar, data00062a.tar, data00036b.tar, data00070a.tar, data00068a.tar, data00072a.tar, data00067a.tar, data00049b.tar, data00061a.tar, data00056a.tar, data00064a.tar, data00059a.tar]​
    added files [data00050c.tar, data00065b.tar, data00073b.tar, data00056b.tar, data00072b.tar, data00066b.tar, data00069b.tar, data00063b.tar, data00018c.tar, data00058b.tar, data00060b.tar, data00074b.tar, data00020c.tar, data00059b.tar, data00070b.tar, data00062b.tar, data00061b.tar, data00036c.tar, data00075a.tar, data00057b.tar, data00049c.tar]​
Compaction succeeded in 21.76 s (21s).​

 

AEM6.3 のオンラインリビジョンクリーンアップ:

TarMK GC #2: started​
TarMK GC #2: …..​
TarMK GC #2: estimation started
​TarMK GC #2: estimation completed in 6.373 ms (6 ms). Segmentstore size has increased since the last garbage collection from 417.9 MB (417905664 bytes) to 844.2 MB (844169728 bytes), an increase of 426.3 MB (426264064 bytes) or 102%. This is greater than sizeDeltaEstimation=100.0 MB (100000000 bytes), so running garbage collection​
TarMK GC #2: compaction started, …​
TarMK GC #2: estimated number of nodes to compact is 442708, based on 442307 nodes compacted to 417905664 bytes on disk in previous compaction and current size of 418285056 bytes on disk.​
TarMK GC #2: compaction cycle 0 completed in 52.96 s (52956 ms). Compacted ff940e56-3a69-4721-ab80-74210b7beae9.00000034 to 8ddf7c10-1af6-41f8-aa99-6b750e09e00b.00000533​
​TarMK GC #2: ……​
TarMK GC #2: compaction succeeded in 53.07 s (53072 ms), after 1 cycles​
TarMK GC #2: cleanup started.​
TarMK GC #2: current repository size is 530.8 MB (530752512 bytes)​
….​
cleanup marking files for deletion: …….​
cleanup completed in 1.584 s (1584 ms). Post cleanup size is 223.9 MB (223906816 bytes) and space reclaimed 306.8 MB (306845696 bytes).​
Removed files: ……​
TarMK closed: …….​

Oak Mongo ストレージメンテナンス

一部のクライアントは、デフォルトの Tar SegmentNodeStore を使用する代わりに、ストレージプットフォームとして、MongoDB (DocumentNodeStore) を使用することを選択しました。このストレージプラットフォームは、AEM インスタンスのクラスタリングを通じて高可用性を提供します。Tar ストレージと同様に、削除を含むすべての書き込みでは、書き込まれるデータの量が増加します。古い不要なリビジョンをクリーンアップするには、DocumentNodeStore リビジョンガーベッジコレクション(「リビジョンクリーンアップ」とも呼ばれます)を実行します。このメンテナンスがすべての AEM バージョンで、毎日午前 2時に、自動的に開始される設定です。  これを設定するメンテナンスタスクは、Tar オンラインリビジョンクリーンアップと同じです。

メンテナンスタスクは、MongoDB クラスターの主要なレプリカに対して、リーダー AEM クラスターノードでのみ実行されます。それは次のように動作します。

  1. 24 時間より古いチェックポイントが存在するかどうかを確認します。
  2. 最大リビジョン年より古い、削除されたドキュメントの MongoDB をクエリ
  3. バッチでのドキュメントの削除
  4. 最大リビジョン年よりも古い「分割」リビジョンドキュメントの MongoDB をクエリ
  5. バッチでのドキュメントの削除

推奨スケジュール

このメンテナンスは、少なくとも毎日実行する必要があります。  デフォルトでは午前2時に開始を実行し、完了します。  ただし、実行頻度が多いほど、実行速度は速くなります。  また、実行頻度が多いほど、Oak の書き込みパフォーマンスが全体的に向上します。  実行中は、MongoDB のパフォーマンスに影響することに注意してください。  最小限のユーザーがシステム上にいる場合にのみ、実行する必要があります。

サンプルログ出力

次のサンプルログ出力は、Revision Garbage Collection の正常な実行の開始ログと終了ログメッセージを示しています。

16.08.2017 23:38:26.521 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Starting revision garbage collection. Revisions older than [2017-08-15 23:38:26.516] will be removed
16.08.2017 23:38:26.727 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [2620] documents
16.08.2017 23:38:27.265 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Proceeding to delete [0] previous documents
16.08.2017 23:38:27.279 *INFO* [sling-oak-observation-173] org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector Revision garbage collection finished in 766.2 ms. VersionGCStats{ignoredGCDueToCheckPoint=false, deletedDocGCCount=2620, splitDocGCCount=3, intermediateSplitDocGCCount=0, timeToCollectDeletedDocs=170.4 ms, timeTakenToDeleteDeletedDocs=561.3 ms, timeTakenToCollectAndDeleteSplitDocs=10.52 ms}

Oak バイナリファイル (BLOB) のメンテナンス

AEM 6.3 では、デフォルトの Oak リポジトリのストレージ設定は、バイナリファイルの格納用に設定される FileDataStore を使用した Tar SegmentStore です。  デフォルトでは、データストアは、4KB 以上のバイナリファイルを格納します。  デフォルトのインストールでは、データストアはサーバーのファイルシステムの crx-quickstart/repositor/datastore の下にあります。  これらのファイルには、jar ファイル、画像、javascript、css、パッケージ、lucene インデックスファイル、その他 AEM にアップロードされたバイナリファイルなどが含まれます。  これらのファイルは、NodeStore のバイナリノードプロパティのリビジョン内で参照されます。

データストアは、独自にファイルを保存するように設計されています。つまり、同じファイルが Oak の 2 つの異なる場所にアップロードされている場合は、1 つのファイルのみが保存されます。  このため、DataStore Garbage Collection が実行されるまで、ファイルはデータストアから絶対に削除されません。

BLOB GC(「DataStore Garbage Collection」として知られる)メンテナンスは Oak のファイル、S3、Mongo BLOB バイナリストアに適用されます。  このトピックについて詳しくは、次の公式ドキュメントを参照してください。

推奨スケジュール

デフォルトでは、これは土曜日の午前 2 時から実行する毎週のメンテナンスタスクで、完了するまで実行します。  ディスク容量不足を避けるため、このメンテナンスタスクを毎週実行することをお勧めします。  ストレージボリュームに十分なスペースがある場合は、少ない頻度で安全に実行できます。  このメンテナンスを行わないと、ディスク容量が無駄に使われる危険があります。

サンプルログ出力

次のサンプルログ出力は、DataStore Garbage Collection を正常に実行した場合の開始と流量ログメッセージをいかに示しています。

Starting Blob garbage collection with markOnly [false]​
Collected (1024) blob references ​
….​
Deleted blobs [……….]​
….​
Blob garbage collection completed in 4.569 s (4568 ms). Number of blobs deleted [6341] with max modification time of [2017-07-16 22:03:55.295]









ワークフローパージメンテナンス

ワークフローが AEM で開始されると、Oak リポジトリの //etc/workflow/instances の下にワークフロー履歴が作成されます。  時間が経過すると、ワークフローの履歴ノードが蓄積され、システムのパフォーマンスに影響を与える可能性があります。  この問題を回避するには、ワークフローパージメンテナンスを実行する必要があります。

このメンテナンスタスクを設定して実行する方法の詳細については、このドキュメントを参照してください。

推奨スケジュール

このメンテナンスタスクを毎週実行する必要があります。

サンプルログ出力

以下のログメッセージは、ワークフローパージメンテナンスの正常な実行を示しています。

*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Begin workflow purge with the following parameters:​
dry run: false​
days old: 0​
states: {COMPLETED, ABORTED}​
models: {/etc/workflow/models/dam/update_asset/jcr:content/model ,/etc/workflow/models/dam-xmp-writeback/jcr:content/model} purge save threshold: {20} purge query count: {1000}​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Cleaned up 1006 instances​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.WorkflowOperationsImpl Finished running Workflow Purge. Purged: 1006 items.  Elapsed time (seconds): 0​
*INFO* [Workflow Purge: 'DAM Workflows'] com.adobe.granite.workflow.core.mbean.PurgeScheduler Finished running  Workflow Purge Configuration: DAM Workflows.  Purged: 1006 items.  Elapsed time (seconds): 0​

バージョンパージメンテナンス

デフォルトの AEM インストールでは、ページやアセットを公開または非公開するか、アセットをアップロードするか置き換えるかの際にバージョンが作成されます。  Oak レポジトリの/jcr:system/jcr:versionStorage の下のノードとして、バージョンが保存されます。  これらのノードでは、データストア内のバイナリファイルへの参照が保持されます。  バージョンが集積したときに、システムのパフォーマンスやディスク使用に影響します。  検索インデックス、Tar または Mongo ストレージと DataStore は、古いバージョン履歴からの追加データで膨張します。ディスク容量を再要求してシステムのパフォーマンスを取り戻すには、バージョンパージを実行する必要があります。

  • バージョンパージを設定して実行する方法についてはこのドキュメントを参照してください。
  • バージョンパージによる既知の問題を回避する方法については、この記事を参照してください。

推奨スケジュール

このメンテナンスタスクは、毎月実行する必要があります。

サンプルログ出力

バージョンのパージは、バージョンを正常にパージした場合にのみ、ログにメッセージを出力します。一部のバージョンをパージできない場合は、エラーが出て、他のバージョンのパージが続行されます。

次のログメッセージは、バージョンのパージが正常にパージされた場合の例です。

INFO [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Purged version 1.0 of /content/geometrixx/en/jcr:content

以下のエラーは、失敗したバージョンのパージの例です。

ERROR [pool-11-thread-10-Maintenance Queue(com/adobe/granite/maintenance/job/VersionPurgeTask)] com.day.cq.wcm.core.impl.VersionManagerImpl Unable to purge version 1.1 for /content/geometrixx/en/jcr:content : OakIntegrity0001: Unable to delete referenced node
javax.jcr.ReferentialIntegrityException: OakIntegrity0001: Unable to delete referenced node
at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:235)
at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at org.apache.jackrabbit.oak.jcr.version.ReadWriteVersionManager.removeVersion(ReadWriteVersionManager.java

Lucene バイナリクリーンアップ

Lucene バイナリクリーンアップタスクを使用することで、Lucene バイナリをパージして、実行中のデータストアのサイズ要件を減らすことができます。これは、以前はデータストアのガベージコレクションの正常な実行に依存していましたが、Lucene のバイナリチャーンが毎日再要求されるようになったからです。

メンテナンスタスクは Lucene に関連したリビジョンガベージを減らすために開発されましたが、このタスクを実行すると、次のように全般的に効率が向上します。

  • データストアのガベージコレクションタスクの毎週の実行は、より迅速に完了します。
  • AEM の全体的なパフォーマンスがわずかに向上することもあります。

Lucene バイナリクリーンアップタスクには、AEM/ツール/運営/メンテナンス/日別メンテナンスウィンドウ/Lucene バイナリクリーンアップからアクセスできます。

監査ログパージメンテナンス

デフォルトの AEM インストールでは、ページまたはアセットの作成/アップロード、変更、削除、あるいは(非)公開されると、監査ログが作成されます。  監査ログは、Oak レポジトリの/var/audit の下にあるノードとして保存されます。  徐々に、これらのノードは集積し、システムパフォーマンスに影響します。  そのシチュエーションを回避するために、Audit Log Maintenance を実行する必要があります。

監査ログのパージメンテナンスを設定して実行する方法の詳細については、このドキュメントを参照してください。

推奨スケジュール

このメンテナンスタスクは、月ごとに実行する必要があります。

サンプルログ出力

次のログメッセージは、AuditLog メンテナンスの正常な実行を示しています。

16.08.2017 23:19:48.765 *INFO* [pool-81-thread-1] com.day.cq.audit.impl.AuditLogPurgeScheduler {name = test, type = [PageVersion Created, PageRestored, PageValid, PageMoved, PageDeleted, PageModified, PageCreated, PageInvalid, PageRolled Out], contentPath = /content, minimumAge = 5} activated
16.08.2017 23:19:48.799 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge starting execution
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - Node /var/audit/com.day.cq.wcm.core.page/content does not exist in the repository, skipping current rule execution.
16.08.2017 23:19:48.800 *INFO* [sling-threadpool-d679d698-60cf-4039-9702-55136a780492-(apache-sling-job-thread-pool)-1-Maintenance Queue(com/adobe/granite/maintenance/job/AuditLogMaintenanceTask)] com.day.cq.audit.impl.AuditLogPurgeScheduler test - AuditLog purge execution is over

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

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