修訂清除

簡介

每個對儲存庫的更新都會建立新的內容修訂。 因此,每次更新時,存放庫的大小都會增加。 為避免儲存庫增長失控,需要清理舊修訂版本以釋放磁碟資源。 此維護功能稱為修訂清除。 自AEM 6.0起,已可作為離線常式使用。

AEM 6.3導入了名為「線上修訂清除」的線上版本。 與必須關閉AEM例項的離線修訂清除相比,當AEM例項上線時,可執行線上修訂清除。 「線上修訂清除」預設為開啟,這是執行修訂清除的建議方式。

注意: 如需簡 介及如何使用線上修訂清除,請參閱影片。

修訂清除程式包含三個階段:estimationcompaction​和​clean up。 估計會根據可收集的垃圾量,決定是否要執行下一階段(壓縮)。 壓縮階段期間,會重寫區段和tar檔案,留下任何未使用的內容。 清理階段隨後移除了舊段,包括它們可能包含的任何垃圾。 離線模式通常可節省更多空間,因為線上模式需要考慮AEM工作集,而這會保留其他區段無法收集。

如需「修訂清除」的詳細資訊,請參閱下列連結:

此外,您也可以閱讀官方Oak檔案。

何時使用「線上修訂清除」而非「離線修訂清除」?

執行修訂清除的建議方式是「線上修訂清除」。 離線修訂清除應僅在例外情況下使用,例如,在遷移至新儲存格式之前,或如果Adobe客戶服務要求您執行此操作,則應先使用。

如何運行線上修訂清除

依預設,「線上修訂清除」會設定為在AEM製作和發佈執行個體上每天自動執行一次。 您只需在使用者活動最少的期間內定義維護期間即可。 您可以依照下列方式設定「線上修訂清除」任務:

  1. 在主AEM視窗中,前往​工具 — 作業 — 控制面板 — 維護,或將瀏覽器指向:https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. 暫留在​每日維護窗口​上,然後按一下​設定​表徵圖。

    chlimage_1-91

  3. 輸入所需值(重複、開始時間、結束時間),然後按一下​Save

    chlimage_1-92

或者,如果要手動運行修訂清除任務,可以:

  1. 轉至​工具 — 操作 — 儀表板 — 維護,或直接瀏覽至https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. 按一下​每日維護窗口

  3. 將游標暫留在​修訂清除​圖示上。

  4. 按一下​運行

    chlimage_1-93

離線修訂清除後執行線上修訂清除

修訂清除程式會逐代回收舊修訂。 這表示每次執行修訂清除時,都會建立新的一代並保留在磁碟上。 不過,兩種修訂清除類型之間有差異:離線修訂清除會保留一代,而線上修訂清除會保留兩代。 因此,當您在​離線修訂清除後執行線上修訂清除​時,會發生下列情況:

  1. 執行第一個線上修訂清除後,存放庫的大小會加倍。 之所以會發生這種情況,是因為現在有兩代人保留在磁碟上。
  2. 在後續運行中,儲存庫將在建立新一代時臨時增長,然後穩定到首次運行後的大小,因為線上修訂清理過程將重新整理上一代。

另外,請記住,根據提交的類型和數量,每代的大小都可能與前一代不同,因此最終大小可能因一次運行而異。

因此,建議將磁碟的大小至少比最初估計的儲存庫大小大兩三倍。

完整和尾部壓實模式

AEM 6.5 為「線上 修訂 清除」程 ​式的compaction階段導入了兩種新模式:

  • 完全壓縮​模式會重寫整個儲存庫中的所有區段和tar檔案。 因此,後續的清理階段可以在整個儲存庫中刪除最大的垃圾量。 由於完全壓縮會影響整個儲存庫,因此需要大量的系統資源和時間才能完成。 完全壓實與AEM 6.3中的壓實階段相對應。
  • 尾部壓縮​模式只會重寫儲存庫中最近的區段和tar檔案。 最近的區段和tar檔案是自上次完全或尾部壓縮執行後新增的區段和tar檔案。 因此,後續的清理階段只能移除存放庫最近部分所包含的垃圾。 由於尾部壓縮只影響儲存庫的一部分,因此完成所需的系統資源和時間比完全壓縮要少得多。

這些壓縮模式構成了效率和資源消耗之間的權衡:尾部壓實效果差,對系統正常運行影響小。 相比之下,全壓實效果更好,但對系統正常運行影響較大。

AEM 6.5也導入了壓縮期間更有效的內容重複資料刪除機制,進一步減少存放庫的磁碟空間。

下面的兩張圖表呈現了內部實驗室測試的結果,這些測試說明與AEM 6.3相比,AEM 6.5中磁碟的平均執行時間和平均佔用空間減少了:

onrc-duration-6_4vs63 segmentstore-6_4vs63

如何配置完整和尾部壓縮

預設設定會在周天執行尾部壓縮,並在週日執行完全壓縮。 使用RevisionCleanupTask 維護任務的新配置值full.gc.days可以更改預設配置。

當您設定full.gc.days值時,請注意,完全壓縮會在值中定義的日期期間執行,而尾部壓縮則會在未定義值的日期期間執行。 例如,如果您設定完全壓縮以在星期日執行,則尾部壓縮將在星期一至星期六執行。 例如,如果您設定完全壓縮以每週的每天執行,則尾部壓縮完全不會執行。

此外,請考量:

  • 尾部緊 縮效果較差,對正常系統運行影響較小。因此,它打算在工作日期間運行。
  • 完全 緊湊更有效,但對正常系統操作的影響也更大。因此,本計畫在工作日使用。
  • 尾部壓實和完全壓實都應安排在非高峰時段運行。

疑難排解

使用新的壓縮模式時,請記住以下事項:

  • 您可以監控輸入/輸出(I/O)活動,例如:I/O操作、等待IO的CPU、提交隊列大小。 這有助於確定系統是否正在綁定I/O,並需要更新大小。
  • RevisionCleanupTaskHealthCheck表示「線上修訂清除」的總體運行狀況。 其運作方式與AEM 6.3相同,不區分完整壓實與尾部壓實。
  • 記錄訊息包含關於壓縮模式的相關資訊。 例如,當「線上修訂清除」啟動時,對應的記錄訊息會指出壓縮模式。 此外,在某些角落情況下,當計畫運行尾部壓縮時,系統將恢復為完全壓縮,日誌消息將指示此更改。 以下的日誌樣本指示壓實模式以及從尾部到完全壓實的變化:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

已知限制

在某些情況下,尾部和完全壓實模式之間的交替會延遲清理過程。 更準確地說,完整壓縮後,存放庫將會增加(其大小會翻倍)。 當存放庫將降至預先完全壓縮大小以下時,額外的空間將會在後續的尾部壓縮中回收。 還應避免並行維護任務執行。

建議將磁碟的大小至少比最初估計的儲存庫大小大兩三倍。

線上修訂清除常見問題

AEM 6.5升級考量事項

問題 答案
升級至AEM 6.5時,應注意什麼?

AEM 6.5會變更TarMK的持續性格式。這些變更不需要主動移轉步驟。 現有存放庫會執行滾動式移轉,對使用者而言是透明的。 AEM 6.5(或相關工具)首次存取存放庫時,就會啟動移轉程式。

一旦開始移轉至AEM 6.5永續性格式,存放庫就無法還原回先前的AEM 6.3永續性格式。

移轉至Oak區段Tar

問題 答案
為何需要遷移儲存庫?

在AEM 6.3中,需要更改儲存格式,特別是為了改進線上修訂清理的效能和效果。 這些變更不向後相容,且以舊Oak區段(AEM 6.2和舊版)建立的存放庫必須移轉。

更改儲存格式的其他好處:

  • 更佳的可擴充性(最佳化區段大小)。
  • 更快的資料儲存垃圾收集
  • 未來增強功能的基礎工作。
仍支援舊版Tar格式嗎? AEM 6.3僅支援新的Oak Segment Tar。
內容移轉一律為強制項目嗎? 是. 除非您從最新的例項開始,否則您永遠必須移轉內容。
我可以升級至6.3,稍後再進行移轉(例如,使用其他維護視窗)嗎? 否,如上所述,內容移轉是強制性的。
遷移時可以避免停機嗎? 否. 這是一次性作業,無法在執行中的執行個體上完成。
如果不小心執行錯誤的存放庫格式,會發生什麼事? 如果您嘗試對oak-segment-tar存放庫執行oak-segment模組(反之亦然),啟動會失敗並出現IllegalStateException訊息「無效區段格式」。 不會發生資料損壞。
是否需要重新索引搜索索引? 否. 從oak-segment移轉至oak-segment-tar會導致容器格式的變更。 包含的資料不受影響,不會修改。
如何最佳地計算遷移期間和遷移後所需的預期磁碟空間? 移轉等同於以新格式重新建立區段存放區。 這可用於估計遷移期間所需的額外磁碟空間。 遷移後,可以刪除舊的段儲存以回收空間。
如何最佳估計移轉的持續時間? 如果在移轉前執行離線修訂清除,移轉效能可大幅改善。 建議所有客戶在升級程式前先執行此作業。 一般而言,移轉的持續時間應與離線修訂清除任務的持續時間類似,假設離線修訂清除任務已在移轉前執行。

運行線上修訂清除

問題 答案
執行「線上修訂清除」的頻率為何? 一天一次. 這是「操作控制面板」中的預設配置。
如何配置線上修訂清除維護任務的開始時間? 請參閱如何執行線上修訂清除一節。
線上修訂清除是否有不應超過的最大頻率? 建議每天運行一次線上修訂清除,預設配置。
決定線上修訂清除執行頻率的關鍵指標為何? 無需確定頻率,因為「線上修訂清除」已設定為維護任務,且每天會自動執行。
為什麼「線上修訂清除」第一次運行時沒有回收任何空間? 線上修訂清除會按代回收舊修訂。 每次執行修訂清除時,都會產生新的層代。 只有至少兩代的內容才會被回收,這意味著在第一次運行中,沒有什麼可回收的。
在離線修訂清除後執行時,第一個線上修訂清除為何不會回收任何空間?

離線修訂清除將回收除最新一代之外的所有內容,而線上修訂清除則需回收最新兩代。 若是新的存放庫,線上修訂清除在離線修訂清除後首次執行時,不會回收任何空間,因為沒有足夠可回收的代數。

此外,請閱讀本章的「離線修訂清除後執行線上修訂清除」一節。

製作和發佈通常會有不同的「線上修訂清除」視窗嗎? 這取決於客戶的上班時間和線上狀態的流量模式。 維護窗口應配置在主生產時間之外,以獲得最佳的清理效果。 若為多個AEM發佈執行個體(TarMK伺服器陣列),「線上修訂清除」的維護視窗應交錯開來。
執行線上修訂清除之前是否有任何先決條件?

「線上修訂清除」僅適用於AEM 6.3和更新版本。 此外,如果您使用的是舊版AEM,則需要移轉至新的Oak Segment Tar

決定線上修訂清除持續時間的因素有哪些? 因素為:
  • 存放庫大小
  • 在系統上載入(每分鐘請求數,特別是寫入操作)
  • 活動模式(讀取與寫入)
  • 硬體規格(CPU效能、記憶體、IOPS)
執行線上修訂清除時,作者仍可工作嗎? 是的,線上修訂清除可以處理併發寫入。 但是,「線上修訂清除」可以更快、更高效地運行,而無需同時執行寫入事務。 建議將「線上修訂清除」維護任務安排到相對安靜的時間,而不需要大量流量。
運行「聯機修訂清除」時,磁碟空間和堆記憶體的最低要求是什麼?

線上修訂清除期間會持續監控磁碟空間。 如果可用磁碟空間降至關鍵值以下,該過程將被取消。 關鍵值是儲存庫當前磁碟佔用量的25%,且不可配置。

建議將磁碟的大小至少比最初估計的儲存庫大小大兩三倍。

清除過程中會持續監視空閒堆空間。 如果空閒堆空間降至關鍵值以下,則取消該進程。 關鍵值是透過org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD設定。 預設值為15%。

Recommendations的最小壓縮堆大小調整不會與AEM記憶體大小調整建議分開。 一般規則是:如果AEM實例的大小足夠滿足使用案例和其上預期的有效負載,則清除過程將獲得足夠的記憶體。

運行線上修訂清除時預期的效能影響是什麼? 「線上修訂清除」是一個後台進程,它從儲存庫中讀取資料,並將資料寫入正常的系統操作。 尤其是,它可能需要在短時間內獲得對儲存庫的獨佔訪問權,從而阻止其他線程寫入儲存庫。
線上修訂清除預計會執行多久? 根據我們內部執行的最新效能測試,執行時間不應超過2小時。
如果「線上修訂清除」需要更長時間,該怎麼辦?
  • 確保每天執行。
  • 請在Operations Dashboard中相應地配置維護窗口,以確保它在最少的儲存庫活動期間執行。
  • 擴展系統資源(CPU、記憶體、I/O)。
如果「線上修訂清除」超過配置的維護窗口,會發生什麼情況? 確保其他維護任務不會延遲其執行。 如果在同一維護窗口中執行的維護任務比「線上修訂清除」更多,則可能會是這種情況。 請注意,維護任務是按順序執行的,不具有可配置的順序。
為什麼跳過修訂垃圾收集?

「修訂清理」依賴於估計階段來確定是否有足夠的垃圾可清理。 估算程式會比較目前的大小與上次壓縮後的存放庫大小。 如果大小超過設定的增量,則清除將運行。 大小增量設定為1 GB。 這實際上表示,如果儲存庫大小自上次清除執行以來未增加1 GB,則會略過新的修訂清除迭代。

以下是估計階段的相關日誌條目:

  • 修訂GC將運行:大小增量為N%或N/N(N/N位元組),因此運行compaction
  • 修訂GC將not運行:大小增量為N%或N/N(N/N位元組),因此現在跳過壓縮
如果效能影響太大,是否可以安全地中止自動壓縮? 是. 自AEM 6.3起,它可通過Operations Dashboard中的Maintenance Task Window或JMX安全地停止。
如果AEM執行個體在排程的清除任務期間關閉,程式是否會安全中止,或是在壓縮完成前關閉會遭到封鎖? 修訂清除將中斷,存放庫將安全關閉。
線上修訂清除期間系統當機時會發生什麼事? 在此類情況下,資料不會損壞。 垃圾剩料將被後續運行清理。
未運行線上修訂清除會產生什麼影響? 效能隨時間而降低。
正在收集哪些修訂版本? 依預設,「線上修訂清除」只會收集至少24小時以前的修訂。
如果同時寫入存放庫時受到的干擾過多,會發生什麼情況?

如果系統上存在寫併發,線上修訂清除可能需要獨佔的寫訪問權才能在壓縮週期結束時提交更改。 如oak檔案中詳細說明,系統會進入forceCompact模式。 在強制緊縮期間,獲取獨佔寫鎖,以便最終提交更改而不會任何併發寫入干擾。 若要限制對回應時間的影響,可以定義逾時值。 此值預設為1分鐘,這表示如果強制壓縮未在1分鐘內完成,壓縮過程將中止,以支援併發提交。

力緊的持續時間取決於以下因素:

  • 硬體:特別是IOPS。 持續時間會隨著IOPS的增加而減少。
  • 區段存放區大小:持續時間會隨著區段存放區的大小而增加。

如何在備用執行個體上執行線上修訂清除?

在冷備用設定中,只需將主實例配置為運行聯機修訂清除。 在備用執行個體上,不需要特別排程線上修訂清除。

備用執行個體上的對應操作是「自動清除」 ,這對應於「線上修訂清除」的清除階段。 在主實例上執行「線上修訂清除」後,在備用實例上運行「自動清除」。

估計階段和壓縮階段不會在備用執行個體上執行。

離線修訂清除是否能釋放比線上修訂清除更多的磁碟空間?

離線修訂清除可以立即移除舊修訂,而線上修訂清除需要考慮應用程式堆疊仍在參照的舊修訂。 因此,前者比後者更積極地去除垃圾,在幾個垃圾收集週期中,效果被攤銷。

此外,請閱讀本章的「離線修訂清除後執行線上修訂清除」一節。

有關記憶體映射檔案操作的注意事項嗎?
  • 在Windows環境中,一律會強制執行一般檔案存取,因此不會使用記憶體對應存取。作為一般建議,應將所有可用RAM分配給堆,並增加segmentCache大小。 將segmentCache.size選項新增至org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config(例如segmentCache.size=20480),以增加segmentCache。 切記為作業系統和其他進程保留一些RAM。
  • 在非Windows環境中,增加物理記憶體的大小以改進儲存庫的記憶體映射。

監控線上修訂清除

線上修訂清除期間需要監控哪些項目?
  • 啟用「線上修訂清除」時,應監視磁碟空間。 清理將不運行,或在磁碟空間不足時搶先終止。
  • 檢查記錄檔中的線上修訂清除完成時間。 不應超過2小時。
  • 查核點數。 如果壓縮執行時有超過3個查核點,建議清除查核點。
如何檢查線上修訂清除是否成功完成?

您可以檢查記錄檔,以檢查「線上修訂清除」是否已成功完成。

例如,「TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles」表示壓縮步驟成功完成,除非前面有消息「TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles」,這表示併發負載過多。

相應地,清理步驟成功完成時會顯示訊息「TarMK GC #{}: cleanup completed in {} ({} ms」。

我們可以在哪裡找到上次線上修訂清除執行的統計資料?

狀態、進度和統計資訊通過JMX(SegmentRevisionGarbageCollection MBean)公開。 有關SegmentRevisionGarbageCollection MBean的詳細資訊,請閱讀後面的段落

可透過EstimatedRevisionGCCompletion SegmentRevisionGarbageCollection MBean.

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

請注意,統計資料僅自上次系統啟動後可用。 可運用外部監控工具,讓資料超出AEM正常運作時間。 請參閱將健康狀態檢查附加至Nagios的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」標籤。 清理後大小為{}({}位元組),空間回收了{}({}位元組)。 壓縮映射權重/深度為{}/{}({} bytes/{})。」
  • 修訂清除期間發生問題
    • 故障情況很多,所有情況都標籤有「TarMK GC」開頭的「WARN」或「ERROR」日誌消息。

另請參閱下方的根據錯誤訊息進行疑難排解一節。

如何檢查線上修訂清除完成後回收了多少空間? 清理週期結束時,日誌中會顯示一條消息:"TarMK GC #3: cleanup completed",其中包括儲存庫的大小和回收的垃圾量。
線上修訂清除完成後,如何檢查存放庫的完整性?

線上修訂清除後,不需要存放庫完整性檢查。

不過,您可以執行下列動作,在清除後檢查存放庫狀態:

  • 儲存庫遍歷檢查
  • 清理程式完成後,請使用oak-run工具來檢查不一致之處。 有關如何執行此操作的詳細資訊,請查看Apache文檔。 您不需要關閉AEM即可執行工具。
如何檢測聯機修訂清除是否失敗,以及要恢復的步驟是什麼? 失敗條件會以「TarMK GC」開頭的「WARN」或「ERROR」記錄訊息標示。 另請參閱下方的根據錯誤訊息進行疑難排解一節。
修訂清除運行狀況檢查中公開了哪些資訊? 它們對色彩編碼狀態層級有何貢獻?

修訂清除運行狀況檢查是操作儀表板的一部分。

如果「線上修訂清除」維護任務的上次執行成功完成,則狀態將為GREEN

如果「線上修訂清理」維護任務取消一次,則該任務將為YELLOW

如果「線上修訂清理」維護任務連續取消三次,則該任務將為RED在此情況下,需要手動 互動,否則線上修訂清除可能會再次失敗。有關詳細資訊,請閱讀下面的疑難解答部分。

另請注意,系統重新啟動後,運行狀況檢查狀態將重置。 因此,新重新啟動的執行個體在修訂清除健康檢查中會顯示綠色狀態。 可運用外部監控工具,讓資料超出AEM正常運作時間。 請參閱將健康狀態檢查附加至Nagios的AEM檔案,作為外部監控工具的範例。

如何監視待機實例的自動清除?

狀態、進度和統計資訊通過JMX使用SegmentRevisionGarbageCollection MBean公開。 另請參閱下列Oak檔案

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

請注意,統計資料僅自上次系統啟動後才可用。 可運用外部監控工具,讓資料超出AEM正常運作時間。 另請參閱將健康狀態檢查附加至Nagios的AEM檔案,作為外部監控工具的範例。

日誌檔案還可用於檢查「自動清理」的狀態、進度和統計資訊。

在備用實例的自動清理期間需要監控哪些內容?

  • 運行「自動清理」時應監視磁碟空間。
  • 完成時間(透過記錄檔),以確保不會超過2小時。
  • 執行「自動清除」後,Segmentstore大小。 備用執行個體上的segmentstore大小應與主執行個體上的大小大致相同。

線上修訂清除疑難排解

如果不運行「線上修訂清除」,最糟糕的情況是什麼? AEM執行個體將耗盡磁碟空間,導致生產中斷。
在發佈執行個體上執行線上修訂清除會造成高使用者流量問題嗎? 高用戶流量會影響壓縮階段是否能成功完成。
根據運行狀況檢查和日誌條目,聯機修訂清除未連續成功完成三次。 成功完成線上修訂清除需要什麼? 您可以執行數個步驟來尋找並修正問題:
  • 首先,檢查日誌條目
  • 視記錄檔中的資訊而定,採取適當動作:
    • 如果日誌在forceCompact週期中顯示五個缺少的緊湊週期和超時,則當儲存庫寫入量較低時,將維護窗口安排為安靜時間。 您可以在位於https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html的存放庫量度監控工具中檢查存放庫寫入
    • 如果清理在維護窗口的末尾停止,請確保維護任務用戶介面中維護窗口的配置足夠大
    • 如果可用的堆記憶體不足,請確保實例具有足夠的記憶體。
    • 如果出現延遲反應,區段存放區可能會成長得太多,以致「線上修訂清除」無法在較長的維護期間內完成。 例如,如果上週未完成成功的線上修訂清除,則建議您規劃離線維護並執行離線修訂清除,以便將區段存放區恢復為可管理的大小。
開啟健康檢查警報後需要執行什麼? 請參閱前一點。
如果「線上修訂清除」在排程的維護期間逾時,會發生什麼事? 將取消線上修訂清除,並刪除剩餘內容。 它將在下次計畫維護窗口時重新啟動。
是什麼導致SegmentNotFoundException實例記錄到error.log中,如何恢復?

當TarMK嘗試存取找不到的儲存單元(區段)時,會記錄SegmentNotFoundException。 有三種情況可能會導致此問題:

  1. 規避建議存取機制(例如Sling和JCR API),並使用較低層級API/SPI存取存放庫,然後超過區段保留時間的應用程式。 也就是說,它會保留對實體的引用時間超過「線上修訂清除」允許的保留時間(預設為24小時)。 此案例為暫時性,不會導致資料損毀。 若要復原,應使用oak-run工具來確認例外狀況的暫時性質(oak-run檢查不應回報任何錯誤)。 為此,執行個體必須離線,然後重新啟動。
  2. 外部事件導致磁碟上的資料損壞。 這可能是磁碟故障、磁碟空間不足或意外修改所需資料檔案。 在此情況下,執行個體需要離線,並使用oak-run檢查進行修復。 如需如何執行oak-run檢查的詳細資訊,請參閱下列Apache檔案
  3. 所有其他發生次數皆應透過Adobe客戶服務處理。

根據錯誤消息進行故障排除

如果線上修訂清除過程中發生事件,error.log將是詳細的。 下列矩陣旨在說明最常見的訊息並提供可能的解決方案:

階段 記錄訊息 說明 後續步驟
估計 TarMK GC #2:因為壓縮已暫停而跳過估計 當通過配置在系統上禁用壓縮時,將跳過估計階段。 啟用「線上修訂清除」。
TarMK GC #2:估計中斷:${REASON}。 略過壓縮。 估計階段提前終止。 可能會中斷估計階段的一些事件範例:主機系統上的記憶體或磁碟空間不足。 這取決於特定原因。
壓實 TarMK GC #2:已暫停 只要壓縮階段被配置暫停,則估計階段和壓縮階段都不會被執行。 啟用線上修訂清除。
TarMK GC #2:壓縮已取消:${REASON}。 壓縮階段提前終止。 可能會中斷壓縮階段的事件範例:主機系統上的記憶體或磁碟空間不足。 此外,還可以通過關閉系統或通過管理介面(如操作控制面板中的維護窗口)顯式取消壓縮來取消壓縮。 這取決於特定原因。
TarMK GC #2:5次循環後32.902分鐘(1974140毫秒)壓實失敗 此訊息不表示有無法復原的錯誤,但只有壓縮在經過特定嘗試後才會終止。 另請閱讀後面的段落 請參閱下列Oak檔案,以及執行線上修訂清除區段的最後一個問題。
清理 TarMK GC #2:清除中斷 已通過關閉儲存庫取消清理。 預期不會影響一致性。 此外,磁碟空間很可能不會完全回收。 將在下一個修訂清除週期中回收。 調查為何已關閉儲存庫,並在以後嘗試避免在維護窗口期間關閉儲存庫。

如何運行離線修訂清除

注意

您需使用不同版本的Oak執行工具,端視您與AEM安裝搭配使用的Oak版本而定。 使用此工具之前,請先檢查下方的版本需求清單:

  • 若為Oak版本​1.0.0至1.0.11​或​1.1.0至1.1.6,請使用Oak-run版本 1.0.11

  • 若Oak版本​較上方​較新,請使用符合AEM安裝之Oak核心的Oak-run版本。

Adobe提供​Oak-run​工具,用於執行修訂清除。 可在下列位置下載:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

此工具是可執行的Jar,可手動執行以壓縮存放庫。 此程式稱為離線修訂清除,因為必須關閉存放庫才能正確執行工具。 請務必根據您的維護時段規劃清理。

有關如何提高清理過程效能的提示,請參閱提高離線修訂清理的效能

注意

您也可以在進行維護前清除舊查核點(以下程式中的步驟2和3)。 僅建議具有超過100個查核點的例項使用。

  1. 請務必確認您最近有AEM例項的備份。

    關閉AEM。

  2. (選用)使用工具尋找舊查核點:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (選用)然後,刪除未參考的查核點:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. 執行壓縮並等待它完成:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

提高離線修訂清除的效能

oak-run工具引入多項功能,旨在提升修訂清除程式的效能,並盡可能降低維護期間。

此清單包含數個命令列參數,如下所述:

  • -mmap。 您可以將此值設為true或false。如果設為true,則使用記憶體映射訪問。 若設為false,則會使用檔案存取。 如果未指定,則64位系統上將使用記憶體映射訪問,32位系統上使用檔案訪問。 在Windows上,一律會強制執行一般檔案存取,並忽略此選項。 此參數已取代 — Dtar.memoryMapped參數。

  • -Dupdate.limit。定義臨時事務到磁碟的刷新閾值。 預設值為 10000。

  • -Dcompress-interval。要保留直到壓縮當前映射為止的壓縮映射條目數。 預設為1000000。 如果有足夠的堆記憶體可用,則應將此值增加到更高的數字,以加快吞吐量。 此參數已在Oak 1.6版中移除,且無效。

  • -Dcompaction-progress-log。要記錄的壓縮節點數。 預設值為150000,這表示在操作期間將記錄150000個壓縮的節點。 請結合下列說明的下一個參數使用。

  • -Dtar.PersistCompactionMap。 將此參數設為true ,以使用磁碟空間而非堆記憶體來保存壓縮映射。需要oak-run工具​1.4​版本及更新版本。 如需詳細資訊,請參閱離線修訂清除常見問題集一節中的問題3。 此參數已在Oak 1.6版中移除,且無效。

  • — 力。 強制壓縮並忽略非相符區段存放區版本。

注意

使用--force參數會將區段存放區升級至最新版本,與舊版Oak不相容。 此外,考慮到不可能降級。 一般來說,您應該小心使用這些參數,而且只有在您對如何使用這些參數有知識時才能使用。

使用中參數的範例:

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

觸發修訂清除的其他方法

除了上述方法,您也可以使用JMX控制台觸發修訂清除機制,如下所示:

  1. 前往http://localhost:4502/system/console/jmx開啟JMX主控台
  2. 按一下​RevisionGarbageCollection MBean。
  3. 在下一個窗口中,按一下​startRevisionGC(),然後按一下​調用​以啟動修訂垃圾收集作業。

離線修訂清除常見問題

決定離線修訂清除持續時間的因素有哪些?

需要清理的儲存庫大小和修訂的數量決定了清理的持續時間。

修訂版本和頁面版本之間有何差異?
  • Oak修訂: Oak以由節點和屬性組成的大型樹狀結構階層組織所有內容。此內容樹的每個快照或修訂都不可修改,對樹的更改將以新修訂的序清單示。 通常,每個內容修改都會觸發新修訂。 另請參閱追隨連結
  • 頁面版本: 版本設定會在特定時間點建立頁面的「快照」。通常,頁面啟動時會建立新版本。 如需詳細資訊,請參閱使用頁面版本
如果離線修訂清除任務在8小時內未完成,該如何加速? 如果修訂任務在8小時內未完成,且執行緒轉儲顯示主熱點為InMemoryCompactionMap.findEntry,請使用下列參數搭配oak-run工具版本1.4 或更新版本:-Dtar.PersistCompactionMap=true。 請注意,-Dtar.PersistCompactionMap參數已在Oak 1.6版中移除。

本頁內容