文件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 Author例項在一般編寫工作負荷下會遇到週期性不穩定，包括下列一或多個：

  • 製作UI中嚴重延遲，標準編輯器、殼層和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與這些週期的相關性通常會顯示在健康狀態檢查、編輯器、脈衝和CSRF權杖端點同時完成30秒到幾分鐘後完成的請求叢集。 此模式表示JVM範圍延遲，而非單一緩慢請求。

原因

AEM的TarMK存放庫儲存在/mnt/crx下，會針對區段存放區寫入、建立查核點、Lucene索引更新和壓縮頻繁地執行循序和隨機I/O作業。 這些存放庫工作負載需要一致的儲存延遲和足夠的IOPS。

標準磁性EBS磁碟區可能無法為這些工作負載提供足夠的效能特性。 當儲存輸送量受到限制時，作業系統可能會經歷持續的I/O等待，導致多個JVM執行緒集區同時停頓，並導致不相關的要求發生廣泛的應用程式延遲。

此問題最常出現於非生產AMS環境中，這些環境最初布建有磁性EBS磁碟區，然後gp3 EBS磁碟區才成為標準存放庫儲存選項。 生產環境通常不受影響，因為它們已布建在或稍後移轉至gp3儲存空間。

解決方法 resolution

若要識別並解決反複出現的AEM作者不穩定、嚴重延遲和存放庫效能問題，請按照以下步驟操作：

  1. 驗證受影響之作者執行個體上支援/mnt/crx的Amazon EBS磁碟區型別。 請聯絡您的客戶成功工程師(CSE)以確認磁碟區設定，並判斷存放庫是否託管於gp3 EBS磁碟區。
  2. 如果存放庫託管於標準磁碟區，請評估移轉至gp3 EBS磁碟區的情形。 根據您的AMS合約，與您的CSE一起檢閱任何服務或成本考量事項。
  3. 請透過您的CSE要求儲存遷移。 與AMS基礎架構團隊協調以建立移轉計畫，並根據存放庫大小和工作負載需求確認目標IOPS和輸送量設定。
  4. 將存放庫磁碟區移轉至gp3 EBS磁碟區。 AMS基礎結構團隊通常會透過停止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