文档Experience Cloud KCS

由于EBS存储性能不足(AMS)，导致AEM创作不稳定和严重滞后

最近更新： 2026年7月24日

本文介绍了托管在Adobe Managed Services (AMS)上的AEM Author实例反复出现的性能下降和不稳定情况，这些实例的基础EBS卷类型不符合AEM TarMK存储库的I/O要求。

描述 description

环境

Adobe Experience Manager部署使用Adobe Managed Services (AMS)上的TarMK存储库，并受Amazon EBS存储支持。

问题/症状

AEM创作实例在正常创作工作负载下遇到反复出现的不稳定性，包括以下一项或多项内容：

  • 创作UI中严重滞后，标准编辑器、Shell和CSRF令牌请求的响应时间为一分钟或更长时间。
  • 作者报告了504个网关超时和404个错误。
  • 发布操作失败或严重延迟。
  • 远程DAM事件处理落后且被阻止。

在降级期间或降级之后，error.log中可能会出现以下警告和错误：

*WARN* [ sling-oak-N-org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate-async]
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler
Failed to create checkpoint <uuid> in 10 seconds.

*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory
Couldn't compute safe timestamp to delete files from NIOFSDirectory@/mnt/crx/.../index/.../data

*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
File <segment> doesn't exist in /mnt/crx/.../repository/index/.../data

*WARN* [ sling-default-N-Registered Service.NNNNN]
com.adobe.cq.remotedam.internal.lifecycle.event.consumer.impl.LifecycleEventConsumerImpl
This sites instance is lagging far too behind Remote DAM. Pulling events is blocked

request.log与这些周期的相关性通常会显示同时跨运行状况检查、编辑器、Pulse和CSRF令牌端点在30秒到几分钟后完成的请求群集。 此模式表示JVM范围停滞，而不是单个慢速请求。

原因

AEM的TarMK存储库存储在/mnt/crx下，对区段存储写入、检查点创建、Lucene索引更新和压缩执行频繁的顺序和随机I/O操作。 这些存储库工作负载需要一致的存储延迟和足够的IOPS。

标准磁性EBS卷可能无法为这些工作负载提供足够的性能特征。 当存储吞吐量受到限制时，操作系统可能会经历持续的I/O等待，从而导致多个JVM线程池同时停止运行，并导致跨不相关的请求的广泛应用程序延迟。

在gp3 EBS卷成为标准存储库存储选项之前，最初使用磁EBS卷预配的非生产AMS环境中最常出现此问题。 生产环境通常不受影响，因为它们是在gp3存储上配置的，或以后迁移到gp3存储。

解决方法 resolution

要识别和解决循环出现的AEM创作不稳定、严重延迟和存储库性能问题，请执行以下步骤：

  1. 验证受影响的Author实例上支持/mnt/crx的Amazon EBS卷类型。 联系您的客户成功工程师(CSE)以确认卷配置并确定存储库是否托管在gp3 EBS卷上。
  2. 如果存储库托管在标准磁性存储上，则评估到gp3 EBS卷的迁移。 根据您的AMS协议，与您的CSE一起查看任何服务或成本注意事项。
  3. 通过您的CSE请求存储迁移。 与AMS基础架构团队协调以创建迁移计划，并根据存储库大小和工作负载要求确认目标IOPS和吞吐量设置。
  4. 将存储库卷迁移到gp3 EBS卷。 AMS Infrastructure团队通常通过停止AEM实例、创建现有卷的快照、迁移存储并重新启动实例来执行此过程。
  5. 如果受影响的发布服务器实例使用相同的存储配置，请在迁移计划中包括这些实例。
  6. 测量迁移后的系统性能。 验证在典型的创作活动中，I/O等待、交换使用和平均负载是否已减少。
  7. 查看request.log并确认编辑器和实用程序端点不再显示多秒或一分钟长的响应时间。
  8. 查看error.log并验证检查点失败消息和Lucene索引警告是否不再出现。
  9. 验证作者页面编辑器是否正常加载，发布操作是否成功完成，异步索引是否保持最新状态，以及远程DAM事件过程是否无延迟。
  10. 将循环性能下降与存储库密集型活动（如大型复制突发、MSM转出、包部署或大规模资产摄取）相关联（如果迁移后不稳定仍然存在）。
  11. 当存储库需求峰值继续影响性能时，调整高影响力工作负载的调度或限制。
recommendation-more-help
experience-cloud-kcs-help-kbarticles