修订版清理 revision-cleanup

问题

答案

升级到AEM 6.5时应该了解什么？

TarMK的持久性格式随AEM 6.5而变化。 这些更改不需要主动迁移步骤。 现有存储库会经历滚动迁移，这对于用户是透明的。 首次访问AEM 6.5（或相关工具）存储库时，将启动迁移过程。

迁移到AEM 6.5持久性格式后，存储库无法恢复为之前的AEM 6.3持久性格式。

在AEM 6.3中，需要对存储格式进行更改，尤其是为了提高在线修订清理的性能和效率。 这些更改无法向后兼容，必须迁移使用旧的Oak区段（AEM 6.2及更低版本）创建的存储库。

更改存储格式的其他好处：

• 更好的可扩展性（优化的区段大小）。
• 更快的数据存储垃圾收集.
• 为未来的增强功能做基础工作。

AEM 6.3或更高版本仅支持新的Oak区段Tar。

是。 除非从新的实例开始，否则将始终需要迁移内容。

否，如上所述，内容迁移是强制性的。

不行。 这是一次性工作，无法在正在运行的实例上完成。

如果您尝试对oak-segment-tar存储库运行oak-segment模块（或反之），启动将失败，并出现 IllegalStateException 消息和“区段格式无效”。 没有发生数据损坏。

不行。 从oak-segment迁移到oak-segment-tar会引入容器格式的更改。 包含的数据不受影响，也不会被修改。

迁移等同于以新格式重新创建区段存储。 这可用于估计迁移期间所需的额外磁盘空间。 迁移后，可以删除旧区段存储以回收空间。

Migration performance can be greatly improved if offline revision cleanup is executed prior to the migration. All customers are advised to execute it as a pre-requisite of the upgrade process. In general, the duration of the migration should be similar to the duration of the offline revision cleanup task, assuming that the offline revision cleanup task has been executed before the migration.

Once per day. This is the default configuration in the Operations Dashboard.

See the How to run Online Revision Cleanup section.

It is recommended to run Online Revision Cleanup once per day, as configured by default.

There is no need to determine the frequency as Online Revision Cleanup is configured as a maintenance task and it automatically runs each day.

Online Revision Cleanup reclaims old revisions by generations. A fresh generation is generated every time revision cleanup runs. Only the content that is at least two generations old will be reclaimed, which means that on a first run there is nothing to reclaim.

Offline Revision Cleanup is reclaiming everything but the latest generation compared to latest two generations for Online Revision Cleanup. If there is a fresh repository, Online Revision Cleanup will not reclaim any space when executed for the first time after the Offline Revision Cleanup because there is no generation old enough to be reclaimed.

Also, read the "Running Online Revision Cleanup after Offline Revision Cleanup" section of this chapter.

This depends on office hours and the traffic patterns of the customer online presence. The maintenance windows should be configured outside of the main production times to allow for the best cleanup efficacy. For multiple AEM Publish instances (TarMK Farm), maintenance windows for Online Revision Cleanup should be staggered.

Online Revision Cleanup is available only with AEM 6.3 and higher releases. Also, if you are using an older version of AEM, you must migrate to the new Oak Segment Tar.

The factors are:

• Repository size
• Load on the system (requests per minute, specifically write operations)
• Activity pattern (reads versus writes)
• Hardware specifications (CPU performance, Memory, IOPS)

Yes, Online Revision Cleanup can cope with concurrent writes. However, Online Revision Cleanup works faster and more efficiently without concurrent write transactions. Adobe recommends scheduling the Online Revision Cleanup maintenance task to a relatively quiet time without a lot traffic.

Disk space is continuously monitored during Online Revision Cleanup. 如果可用磁盘空间低于临界值，整理过程将被取消。 临界值为存储库当前磁盘占用量的 25%，且不可配置。

Adobe recommends you size the disk at least two or three times larger than the initially estimated repository size.

Free heap space is continuously monitored during the cleanup process. Should the free heap space drop below a critical value, the process is canceled. The critical value is configured through org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. The default value is 15%.

Recommendations for minimum compaction heap sizing are not separated from the AEM memory sizing recommendations. Generally: If an AEM instance is sized enough to cope with the use cases and expected payload thereon, the cleanup process obtains enough memory.

Online Revision Cleanup is a background process that reads from and writes to the repository concurrently to normal system operations. In particular, it might need to acquire exclusive access to the repository for a short time period, preventing other threads from writing into the repository.

根据Adobe内部执行的最新性能测试，运行时间不应超过两个小时。

• 确保每天执行该操作。
• 通过相应地配置操作仪表板中的维护窗口，确保在最小的存储库活动期间执行该操作。
• 扩展系统资源（CPU、内存、I/O）。

确保其他维护任务不会延迟执行。 如果在同一维护窗口中执行比“联机修订清理”更多的维护任务，则可能会出现这种情况。 维护任务按顺序运行，没有可配置的顺序。

修订清理依赖估计阶段来确定是否有足够的垃圾要清理。 估算器将当前大小与上次压缩后的存储库大小进行比较。 如果大小超过配置的增量，则运行清理。 大小增量设置为1 GB。 这实际上意味着，如果自上次清理运行以来，存储库大小没有增加1 GB，则会跳过新的修订版清理迭代。

以下为估计阶段的相关日志条目：

• 修订GC运行： 大小增量为N%或N/N （N/N字节），因此正在运行压缩
• 修订GC 未运行： 大小增量为N%或N/N （N/N字节），因此现在将跳过压缩

是。 自AEM 6.3起，可通过“操作功能板”中的“维护任务窗口”或通过JMX安全地停止它。

修订清理被中断，存储库将安全关闭。

在这种情况下，不存在数据损坏的风险。 Garbage leftovers are cleaned up by a subsequent run.

Performance degradation over time.

By default, the Online Revision Cleanup only collects revisions that are at least 24 hours old.

If there's write concurrency on the system, online revision cleanup might require exclusive write access to be able to commit the changes at the end of a compaction cycle. The system goes into forceCompact mode, as explained in more detail in the Oak documentation. During force compact, an exclusive write lock is acquired to finally commit the changes without any concurrent writes interfering. To limit the impact on response times, a time-out value can be defined. This value is set to one minute by default, which means that if force compact does not complete within one minute, the compaction process is aborted in favor of concurrent commits.

The duration of force compact depends on the following factors:

• hardware: specifically IOPS. The duration decreases with more IOPS.
• segment store size: duration increases with the size of the segment store.

In a cold standby setup, only the primary instance must be configured to run Online Revision Cleanup. On the standby instance, Online Revision Cleanup does not need to be scheduled specifically.

The corresponding operation on a standby instance is the Automatic Cleanup - this corresponds to the cleanup phase of the Online Revision Cleanup. The Automatic Cleanup is run on the standby instance after the execution of the Online Revision Cleanup on the primary instance.

Estimation and compaction phases will not be run on a standby instance.

Offline Revision Cleanup can immediately remove old revisions while Online Revision Cleanup must account for old revisions still being referenced by the application stack. The former can thus remove garbage more aggressively than the latter where the effect is amortized over the course of a few garbage collection cycles.

Also, read the "Running Online Revision Cleanup after Offline Revision Cleanup" section of this chapter.

Any considerations about memory mapped file operations?

• On Windows environments, regular file access is always enforced so memory mapped access is not used. As a general advice, all the available RAM should be allocated to the heap and the segmentCache size should be increased. You increase the segmentCache by adding the segmentCache.size option to the org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (for example, segmentCache.size=20480). Remember to leave out some RAM for the operating system and other processes.
• On non-Windows environments, increase the size of the physical memory to improve the memory mapping of the repository.

• Disk space should be monitored when Online Revision Cleanup is enabled. The cleanup does not run or it terminates preemptively when there is insufficient disk space.
• Check the logs for the completion time of the Online Revision Cleanup. It should not take longer than 2 hours.
• Number of checkpoints. If there are more than 3 checkpoints when compaction runs it is recommended to clean up the checkpoints.

You can check if the Online Revision Cleanup has completed successfully by checking the logs.

For example, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" means the compaction step completed successfully unless preceded by the message "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", which means there was too much concurrent load.

Correspondingly there is a message "TarMK GC #{}: cleanup completed in {} ({} ms" for the successful completion of the cleanup step.

Status, progress, and statistics are exposed via JMX (SegmentRevisionGarbageCollection MBean). For more details about the SegmentRevisionGarbageCollection MBean, read the following paragraph.

Progress can be tracked via the EstimatedRevisionGCCompletion attribute of the SegmentRevisionGarbageCollection MBean.

You can obtain a reference of the MBean using the ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

统计信息仅在上次系统启动后可用。 外部监视工具可用于将数据保留在AEM正常运行时间之外。

• 联机修订清理已启动/停止
  • 在线修订清理由三个阶段组成：估算、压缩和清理。 如果存储库未包含足够的垃圾，则估算可能会强制跳过压缩和清理。 在最新版本的AEM中，消息“TarMK GC #{}: estimation started”标记估算的开头，“TarMK GC #{}: compaction started, strategy={}”标记压缩的开头，“TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes”标记清理的开头。
• 通过修订清理获得的磁盘空间
  • 仅在清理阶段完成时才回收空间。 清理阶段的结束用日志消息“TarMK GC #{}: cleanup completed in {} ({} ms”标记。 后清理大小为{} （{}字节），已回收空间{} （{}字节）。 压缩映射权重/深度为{}/{} （{}字节/{}）。
• 修订清理期间出现问题
  • 有许多故障情况，它们都标有WARN或ERROR日志消息，以“TarMK GC”开头。

另请参阅下面的基于错误消息的故障排除部分。

清理周期结束时的日志中有一条消息：“TarMK GC #3: cleanup completed”，其中包含存储库的大小和回收的垃圾量。

联机修订清理后不需要存储库完整性检查。

但是，您可以执行以下操作来检查清理后的存储库状态：

• 存储库遍历检查
• 在清理过程完成后使用oak-run工具检查是否存在不一致。 有关如何执行此操作的更多信息，请查看Apache文档。 您无需关闭AEM即可运行该工具。

故障情况由以“TarMK GC”开头的WARN或ERROR日志消息标记。 另请参阅下面的基于错误消息的故障排除部分。

修订清理运行状况检查是操作仪表板.
的一部分

如果联机修订清理维护任务的最后一次执行已成功完成，则状态为绿色。

如果联机修订清理维护任务被取消一次，则为黄色。

如果连续三次取消联机修订清理维护任务，则为红色。 在这种情况下，需要手动交互，否则联机修订清理可能会再次失败。 有关详细信息，请阅读下面的疑难解答部分。

此外，系统重新启动后，运行状况检查状态也会重置。 因此，新重新启动的实例在修订清理运行状况检查中显示绿色状态。 外部监视工具可用于将数据保留在AEM正常运行时间之外。

使用SegmentRevisionGarbageCollection MBean通过JMX公开状态、进度和统计信息。 另请参阅以下Oak文档。

您可以使用ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection"获取MBean的引用。

统计信息仅自上次系统启动后可用。 外部监视工具可用于将数据保留在AEM正常运行时间之外。

日志文件还可用于检查自动清理的状态、进度和统计信息。

• 运行自动清理时应监视磁盘空间。
• 完成时间（通过日志）以确保不超过2小时。
• 运行自动清理后的区段存储大小。 备用实例上的段存储大小应该与主实例上的段存储大小大致相同。

AEM实例的磁盘空间不足，这将导致生产中断。

用户流量过高会影响压缩阶段是否能够成功完成。

您可以采取几个步骤来查找并修复问题：

• 首先，检查日志条目

• 根据日志中的信息，采取适当措施：

  • 如果日志显示错过了五个压缩周期并在forceCompact周期超时，请将维护时段安排在存储库写入量较少时的安静时间。 您可以在 https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html 上的存储库量度监视工具中检查存储库写入
  • 如果清理在维护时段结束时停止，请确保维护任务用户界面中维护时段的配置足够大
  • 如果可用的栈内存不足，请确保实例有足够的内存。
  • 如果反应较晚，则区段存储可能会增长太多，以致于线上修订清理无法在较长的维护时段内完成。 例如，如果上周未成功完成在线修订清理，则建议计划离线维护，并运行离线修订清理，以将区段存储恢复到可管理的大小。

请参阅上一点。

在线修订版清理已取消，剩余的修订版将被删除。 下次安排维护时段时，它将再次启动。

TarMK在尝试访问其无法找到的存储单元（区段）时记录SegmentNotFoundException。 There are three scenarios that could cause this issue:

1. An application that circumvents the recommended access mechanisms (like Sling and the JCR API) and uses a lower-level API/SPI to access the repository and then exceeds the retention time of a segment. That is, it keeps a reference to an entity longer than the retention time allowed by the Online Revision Cleanup (24 hours by default). This case is transient and does not lead to data corruption. To recover, the oak-run tool should be used to confirm the transient nature of the exception (the oak-run check should not report any errors). To do this, the instance must be taken offline and restarted afterwards.
2. An external event caused the corruption of the data on the disk. This can be a disk failure, out of disk space or an accidental modification of the required data files. In this case, the instance must be taken offline and repaired using the oak-run check. For more details on how to perform the oak-run check, read the following Apache documentation.
3. Address all other occurrences through the Adobe Customer Care.

存储库大小和必须清理的修订版本数决定了清理的持续时间。

• Oak修订版： Oak在包含节点和属性的大型树层次结构中组织所有内容。 此内容树的每个快照或修订版本都是不可变的，对树所做的更改以一系列新修订版本表示。 通常，每次内容修改都会触发新的修订。 另请参阅关注链接。
• 页面版本：版本控制可在特定时间点创建页面的“快照”。 通常，在激活页面时会创建新版本。 有关详细信息，请参阅使用页面版本。

如果修订任务未在8小时内完成，并且线程转储显示主热点为InMemoryCompactionMap.findEntry，请将oak-run工具版本1.4 或更高版本使用以下参数： -Dtar.PersistCompactionMap=true。 -Dtar.PersistCompactionMap参数已在Oak版本1.6中删除。