Avamar v7 及更新版本 - 當數據使用中時，由於「Hash Referenced Bit Maps」，導致垃圾收集報告「略過哈希」無法清理

摘要: 在Avamar v7及更新版本中，當基礎數據在執行維護活動時使用時，垃圾收集記錄可能會回報數個「略過哈希」。

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。
查看其他资源

症状

哈希參考位地圖功能是以 Avamar v7.x 功能推出，可讓備份在垃圾收集 （GC） 維護活動期間進行。

在進行此功能之前，由於數據衝突的可能性，垃圾收集無法同時執行。

在垃圾收集階段，新功能會在記憶體中保留新增或變更數據的相關信息 （「參考哈希地圖」）。垃圾收集會檢查此資訊，以瞭解哪些哈希 （以及他們參考的數據） 不應移除。  

此功能的要求是，這些「地圖」至少需要 5 分鐘的「安靜」時間，期間不會發生任何備份，才能重設備份。重設后，即可在後續的垃圾收集週期中掃描被鎖定的數據，只要數據持續維持不變。

設計每日 Avamar 備份和維護排程時，應考慮這個安靜的時間。
地圖無法重設，可能會使垃圾收集無法清理過期的數據。
如果哈希參考的地圖無法獲得重設的機會，則不會處理用於垃圾移除的數據，而且容量使用量可能會增加。如果地圖長時間無法重設，垃圾收集記錄可能會顯示不斷增加的「略過哈希」數量。

原因

備份已過期，但垃圾收集並未還原所有符合刪除資格的數據，因為當時有部分數據在使用中。

若要檢查此問題，請執行以下命令：
命令傾印垃圾收集維護記錄 7 天，並將其分析為顯示。
  • 略過多少哈希，
  • 刪除多少數據
  • 垃圾收集過多少次
  • 垃圾收集的運行時間
dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

分析：

輸出顯示隨著時間推移而增加的略過哈希數目，直到哈希參考對應在 2014 年 2 月 16 日重設為止。
我們也可以看到在哈希釋放后，清理到「兆位元組-復原」的數據量快速躍進，垃圾收集可以處理這些數據以處理過期的數據。

解决方案

立即解決方案

1.請確定地圖可以重設，並允許重新執行垃圾收集。
2.請確定沒有執行 avtar 工作階段將資料新增至系統 （備份或傳入複製數據）。使用 GUI 活動監視器，並檢查是否只有使用「avmaint sessions --full」命令顯示停止會話。
3.停止所有備份和傳入複寫會話。
4.等待至少五分鐘，讓哈希參考位圖有足夠的時間重設。  
5.當 GC 再次執行時，請檢查 GC 維護記錄，確認 略過的哈希s=0

如果 skipped-hashes 尚未重設為零，請與支持部門合作，仔細檢查上述步驟。如果垃圾收集報告 MSG_ERR_TRYAGAINLATER，支援部門可以確認這是否是因為索引等量分割活動所致。 
 

長期解決方案

設計備份和維護排程，以便定期進行「閑置」，可供重設哈希參考位對應。

換言之，備份排程不應 24/7 執行。建立一個排程，在沒有任何備份或傳入複寫數據寫入系統時，提供短時間的時間。 


 

其他信息

注意： 
  • 哈希參考位圖唯一會在avtar會話終止後，檢查是否可以重設的時間。當沒有任何avtar會話進行時，對應只會在下列情況下重設：
    （a） 索引等量尚未分割
    （b） 如果垃圾收集未執行 （地圖會從 GC 期間重設時「鎖定」）
    （c） 如果沒有其他 avtar （備份、還原、複製） 工作階段在 Avamar 伺服器上執行。 
 
  • 略過哈希計數可能暫時高的原因之一是索引等量分割。發生這種情況是因為移到分割目標的哈希受到保護。索引等量分割發生在仍在成長或充滿數據的系統上。 
  • 當索引等量分割時 ，MSG_ERR_TRYAGAINLATER 也可能會導致垃圾收集失敗：  
  • MCS 可能不一定知道 Avamar 伺服器上發生的所有 avtar 工作階段。

受影响的产品

Avamar

产品

Avamar
文章属性
文章编号: 000169212
文章类型: Solution
上次修改时间: 03 6月 2025
版本:  10
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。