目標

本文將說明最常見的嚴重 AEM 問題,以及如何加以分析。

AEM 站點效能問題

效能問題的症狀

  1. 頁面載入緩慢
  2. 頁面建立或編輯緩慢
  3. AEM 回應時間緩慢
  4. AEM 對於部分請求沒有回應
  5. AEM 的 request.log 顯示回應時間緩慢

效能問題起因

  1. 執行緒爭用 – 長時間執行的請求,例如搜尋緩慢、頻繁寫入的背景工作,以及站點內容的整體分支移動等
  2. 高 CPU 使用率
  3. 耗時的請求,例如耗時的搜尋,或效率低落的應用程式碼、元件等。
  4. 缺乏適當維護
  5. 派送程式快取不足
  6. 缺乏 CDN
  7. 缺乏瀏覽器快取
  8. 頁面載入過多指令碼,且皆在頁面頂端載入
  9. CSS 載入整個頁面,而非在 HTML 頁首
  10. 伺服器大小調整不足,或架構不正確
  11. 記憶體問題 (如下所示)

如何分析效能問題

1. 擷取一系列的執行緒傾印加以分析

2. 檢查作業系統層級,瞭解 AEM Java 處理程序是否造成高 CPU 使用率

    Linux: 使用 top 命令檢查 CPU 使用率

    Windows: 使用 Windows 工作管理員

    如果 AEM 造成高 CPU 使用率,請執行內建剖析工具並等待數分鐘,接著分析結果。

3. 針對任何緩慢請求的 request.log 檔案進行分析

4. 檢閱您的系統維護程序,並確認您對 AEM 進行適當維護,其中包括下列項目:

  • 修訂清除 (僅限 MongoMK 與資料庫 DocumentNodeStore) – 每日或更頻繁
  • 離線 Tar 壓縮 (僅限 TarMK) – 每兩週
  • 資料存放區記憶體回收 (僅限擁有 FileDataStore 或 S3 DataStore 的系統) – 每週
  • 工作流程清除 – 每週
  • 版本清除 – 每週
  • 稽核記錄清除 – 每週

如需有關 AEM 維護的詳細資訊,請參閱這篇文章

5. 查看在 AEM 派送程式層級實作的快取策略。 最佳著手方式為瞭解派送程式快取檔案及讓快取檔案失效的時間與方式

6. 查看網站的快取

7. 使用用戶端網站分析工具,例如 Google Chrome 瀏覽器「開發人員工具」面板中的「稽核」功能。 這些工具會針對用戶端效能改善方面提供建議。

常見效能問題的解決方法

AEM 資產效能問題

資產效能問題的症狀

  • 檔案上傳至 /assets.html 或 /damadmin 使用者介面的速度緩慢
  • 產生縮圖的時間太長
  • 資產作業 (例如移動、刪除、編輯及中繼資料更新) 花的時間太長

資產效能問題起因

  • 缺乏適當維護
  • 未套用最新的修正套件
  • 未套用最佳化
  • 使用者負載的伺服器大小調整不足

如何分析資產效能問題

常見資產效能問題的解決方法

記憶體問題

記憶體問題的症狀

  • AEM 隨機性當機,且記錄中出現 OutOfMemoryError
  • AEM 速度逐漸變慢,最後發生當機
  • AEM 沒有回應

診斷記憶體問題

  • 搜尋 OutOfMemoryError 的記錄檔,若您找到任何符合的檔案,則表示記憶體出現問題。
  • 檢閱 http://aem-host:port/system/console/memoryusage 畫面
    如果「Old Generation」(JDK 7 及更早版本) 或「Tenured Generation」(JDK 8 或更新版本) 的使用率過高,這可能是堆積記憶體使用率出現問題的象徵。 按一下「執行記憶體回收器」,以請求 JVM 執行完整堆積記憶體回收。 如果高堆積使用率在請求 GC (記憶體回收) 後仍居高不下,則表示可能出現問題。 在使用 Oak Tar 儲存空間的 AEM 例項中,如果年長 (tenured) 區域使用量大於 3GB,則表示可能出現問題。 如果使用 Mongo 儲存空間的系統出現高堆積使用率,則問題可能出自於記憶體內部快取設定。
  • 收集執行緒傾印與頂端的輸出,並進行執行緒分析。 檢查造成高 CPU 使用率的執行緒是否為原生 JVM Garbage Collection 執行緒。 如果使用大部分 CPU 時間的執行緒為「VM Thread」或任何記憶體回收執行緒,則表示記憶體可能出現問題。

記憶體問題起因

  • Java 應用程式記憶體流失
  • 由於自訂程式碼中結束的使用方式不正確,因此 Java Finalizer 發生堆疊
  • 最大堆積設定不足

如何分析您的記憶體問題起因

如需有關如何擷取堆積傾印的詳細資訊,請參閱本文

找出記憶體問題起因的最佳方式為分析堆積傾印。 

擷取堆積傾印檔案後,接著在 Eclipse MATIBM Memory Analyzer 工具中開啟。 在 Eclipse MAT 中,執行 Leak Suspects 報告並開啟「執行緒詳細資訊」檢視,以瞭解造成記憶體問題的潛在原因。

常見記憶體問題的解決方法

  • 如果您發現長時間出現記憶體回收暫停的情形,請最佳化應用程式碼以減少記憶體使用量。 大多數的記憶體回收問題可透過最佳化應用程式或調整 JVM 有效解決。
  • 如果您已最佳化應用程式,但仍遇到長時間 GC 暫停問題,請著手調整 JVM

AEM 索引問題

索引問題的症狀

下列為發生 AEM/Oak 索引問題的象徵:

  • 搜尋結果過時超過 10 分鐘
  • 搜尋結果遺失
  • 透過站點使用者介面、查詢生產器搜尋或 JCR 查詢執行搜尋期間,使用者介面或記錄中傳回錯誤訊息
診斷索引問題
  • 若要判斷非同步處理索引為緩慢或失敗,請執行下列步驟:

1. 在 AEM 例項中開啟以下 URL,以檢視有關「非同步處理索引子」的統計資料

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats

http://aemhost:port/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dfulltext-async%2Ctype%3DIndexStats  –  此 URL 僅適用於 AEM 6.2 及更新版本

2. 在上述各頁面中,檢查以下欄位:

FailingSince – 此欄位會指出索引首次開始失敗的時間。

LastError – 此欄位會顯示索引失敗起因的堆疊追蹤。 如果此欄位空白,則表示索引沒有失敗。

LastErrorTime – 此欄位會指出上次索引擲回錯誤訊息的時間。

LastIndexedTime – 如果此欄位的日期與時間晚於 5 分鐘,則表示索引執行過慢。

索引問題的起因

  • 未適當維護或無法執行維護,例如「修訂記憶體回收」、「工作流程清除」、「稽核清除」及「版本清除」等。
  • Tar 儲存空間的區段損毀或遺失
  • 叢集環境中的修訂損毀 (DocumentNodeStore – Mongo 或資料庫)
  • 叢集環境中的叢集拓撲問題

如何分析索引問題的起因

  • 如需有關分析與修正索引問題的詳細資訊,請參閱本文

複寫問題

複寫問題的症狀

  • 發佈請求在複寫代理程式佇列中排入佇列
  • 發佈內容未顯示在發佈伺服器上
  • 對系統效能的影響

複寫問題起因:

  • 複寫代理程式設定錯誤,無法連線到發佈代理程式
  • 複寫時發生錯誤,導致複寫佇列卡住
  • 系統速度緩慢,複寫的處理速度也跟著緩慢
  • 複寫發生於自訂工作流程的過程中,且問題與工作流程處理有關。

如何分析複寫問題:

1. 檢查複寫佇列狀態:

        「作用中」:正在處理項目的時候。
        「空閒」: 佇列為空的時候。
        「已封鎖」: 當項目位於佇列中但無法處理的時候,例如代理程式指向故障或不存在的主機時。

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) 如果問題是因為工作流程執行效率不彰所導致,您可查看並行工作流程處理提示
3) 若為整體 AEM 效能低落及複寫相關問題,您可查看 AEM 效能問題  

TarMK 損毀問題

TarMK 損毀的症狀

  • 執行個體在離線壓縮後無法運作。
  • 執行個體卡在「正在啟動」狀態。
  • 記錄檔或壓縮命令輸出回報 SegmentNotFoundException

損毀問題起因

  • 區段遭手動移除 (例如 rm -rf)。   
  • 區段遭修訂記憶體回收移除,或因為程式碼中有錯誤而找不到區段。   
  • 因為程式碼中有錯誤而找不到區段。
  • 未準時執行各項維護任務,導致存放庫增長且磁碟空間不足。
  • 終止 Java 程序以強制停止 AEM。

診斷存放庫損毀問題:

  • 查看 error.log 檔案並檢查是否有 SegmentNotFoundExceptionIllegalArgument Exception
  • 若要判斷區段是否遭修訂記憶體回收移除,請檢查 org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC (啟用偵錯記錄) 記錄器的輸出。該記錄器會記錄清理階段移除的所有區段的區段 ID。只有在該記錄器的輸出顯示違規區段 ID 的情況下,修訂記憶體回收才是導致例外狀況的原因。    
  • 萬一外部資料存放區發生損毀,請在記錄檔中搜尋所有出現的「Error occurred while obtaining InputStream for blobId」(取得 blobId 的 InputStream 時發生錯誤) 錯誤。此錯誤表示您的 AEM 資料存放區目錄遺失檔案。

修復損毀問題的解決方法:

  • 使用 oak-run 的 check 執行模式,判斷區段儲存區的上一個已知良好修訂版本。將損毀的區段儲存區手動還原為最新良好修訂版。此作業會將 Oak 存放庫還原為先前時間點的狀態。執行此作業之前,您應將存放庫完全備份。
    • 若要檢查及還原,請執行這篇文章所述的步驟。
    • 如果檢查失敗並出現錯誤:「ConsistencyChecker - No good revisions found」(ConsistencyChecker - 找不到良好修訂版本),請執行這篇文章 B 部分的步驟。
  • 如果您是使用資料存放區且發生「Error occurred while obtaining InputStream for blobId」(取得 blobId 的 InputStream 時發生錯誤) 錯誤,資料存放區很可能遺失檔案。請依照這篇文章解決此問題。
  • 如果您沒有使用資料存放區,則請使用外部檔案、S3 或 Azure 資料存放區,而不是預設的區段儲存區
    • 使用資料存放區能夠提供更好的效能。
    • 使用 crx2oak 將執行個體移轉到具有資料存放區的執行個體。
  • 套用最新 Service Pack 以及 Cumulative Fix Pack 和 Oak Cumulative Fix Pack。

此産品由 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 授權  Creative Commons 條款未涵蓋 Twitter™ 與 Facebook 文章。

法律說明   |   線上隱私權政策