Avamar v7以降 : データの使用中に「ハッシュ参照ビット マップ」が原因でクリーンアップできない「スキップハッシュ」を報告するガベージ コレクション
摘要: Avamar v7以降では、メンテナンス アクティビティの実行時に基盤となるデータが使用中の場合、ガベージ コレクション ログに複数の「スキップハッシュ」が報告されることがあります。
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
症状
ハッシュ参照ビット マップ機能は、Gc(ガベージ コレクション)メンテナンス アクティビティ中にバックアップを実行できるAvamar v7.x機能で導入された機能です。
この機能を使用する前は、データの競合が発生する可能性があるため、ガベージ コレクションを同時に実行できませんでした。
ガベージ コレクション フェーズ中、新しい機能は、追加または変更されたデータ(「参照ハッシュのマップ」)に関する情報をメモリー内に保持します。ガベージ コレクションは、この情報をチェックして、削除すべきでないハッシュ(および参照するデータ)を把握します。
この機能の要件は、これらの「マップ」に少なくとも5分間の「静止」時間が必要であり、その間にリセットするためにバックアップが実行されないということです。このリセットが発生すると、ロックされたデータは、変更され続ける限り、後続のガベージ コレクション サイクル中にスキャンできます。
毎日のAvamarバックアップおよびメンテナンス スケジュールを設計する際には、この静かな時間を考慮する必要があります。
マップをリセットできない場合、ガベージ コレクションが期限切れのデータをクリーンアップできなくなる可能性があります。
ハッシュ参照マップがリセットの機会を得られない場合、ガベージによる削除の対象となるはずのデータは処理されず、容量の使用量が増加する可能性があります。マップが長期間にわたってリセットできない場合、ガベージ コレクション ログに「スキップされたハッシュ」の量が増加することがあります。
この機能を使用する前は、データの競合が発生する可能性があるため、ガベージ コレクションを同時に実行できませんでした。
ガベージ コレクション フェーズ中、新しい機能は、追加または変更されたデータ(「参照ハッシュのマップ」)に関する情報をメモリー内に保持します。ガベージ コレクションは、この情報をチェックして、削除すべきでないハッシュ(および参照するデータ)を把握します。
この機能の要件は、これらの「マップ」に少なくとも5分間の「静止」時間が必要であり、その間にリセットするためにバックアップが実行されないということです。このリセットが発生すると、ロックされたデータは、変更され続ける限り、後続のガベージ コレクション サイクル中にスキャンできます。
毎日のAvamarバックアップおよびメンテナンス スケジュールを設計する際には、この静かな時間を考慮する必要があります。
マップをリセットできない場合、ガベージ コレクションが期限切れのデータをクリーンアップできなくなる可能性があります。
ハッシュ参照マップがリセットの機会を得られない場合、ガベージによる削除の対象となるはずのデータは処理されず、容量の使用量が増加する可能性があります。マップが長期間にわたってリセットできない場合、ガベージ コレクション ログに「スキップされたハッシュ」の量が増加することがあります。
原因
バックアップの有効期限が切れましたが、一部のデータが当時使用されていたため、ガベージ コレクションでは削除対象のすべてのデータがリカバリされませんでした。
これを確認するには、次のコマンドを実行します。
コマンドは、ガベージ コレクションのメンテナンス ログを7日間ダンプし、解析して表示します。
また、ハッシュが解放され、ガベージ コレクションが期限切れのデータを処理した後に、クリーンアップされたデータの量が「メガバイトリカバリー」された場合にジャンプすることも確認できます。
これを確認するには、次のコマンドを実行します。
コマンドは、ガベージ コレクションのメンテナンス ログを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分間待って、ハッシュ参照ビット マップがリセットされるまで十分な時間を確保します。
5.GCが再度実行されたら、GCメンテナンス ログをチェックして 、skipped-hashes=0
であることを確認します。スキップされたハッシュがゼロにリセットされていない場合は、サポートと協力して上記の手順をダブル チェックします。ガベージ コレクションが MSG_ERR_TRYAGAINLATER報告された場合、サポートは、これがインデックス ストライプ 分割アクティビティが原因であるかどうかを確認できます。
長期的なソリューション
ハッシュ参照ビット マップをリセットするために通常の「アイドル」が使用可能になるように、バックアップとメンテナンスのスケジュールを設計します。つまり、バックアップ スケジュールを24時間365日実行しないようにする必要があります。バックアップまたは受信レプリケーション データがシステムに書き込まれる時間が短いスケジュールを作成します。
其他信息
メモ:
- ハッシュが参照するビット マップがリセットできるかどうかを確認するのは、avtarセッションが終了した直後のみです。進行中のavtarセッションがない場合、マップは次の場合にのみリセットされます。
(a)インデックス ストライプが分割されていない
(b)ガベージ コレクションが実行されていない場合(GC中にマップが「ロック」されてリセットされない)
(c)Avamarサーバーで他のavtar(バックアップ、リストア、レプリケーション)セッションが実行されていない場合。
- スキップされたハッシュ数が一時的に増加する理由の1つは、インデックス ストライプの分割によるものです。これは、分割されたターゲットに移動されたハッシュが保護されているために発生します。インデックス ストライプの分割は、まだ増加中またはデータがいっぱいになっているシステムで発生します。
- インデックス ストライプが分割されている場合、ガベージ コレクションが MSG_ERR_TRYAGAINLATER で失敗する場合もあります。
- MCSは、必ずしもAvamarサーバーで発生するすべてのavtarセッションを認識していない場合があります。
受影响的产品
Avamar产品
Avamar文章属性
文章编号: 000169212
文章类型: Solution
上次修改时间: 03 6月 2025
版本: 10
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。