Avamar：バックアップのパフォーマンスが遅い場合のトラブルシューティング

  
バックアップ パフォーマンス低下の一般的な症状：

• スケジュール設定されたウィンドウ内でバックアップが完了しない。アクティビティー モニターで「Client time out - end」と報告される。
• スケジュール設定されたウィンドウが終了する前にバックアップを開始する機会がない。アクティビティー モニターで「Client time out - start」と報告される。
• ガベージ コレクションが「MSG_ERR_BACKUPSINPROGRESS」または「MSG_ERR_TRYAGAINLATER」で定期的に失敗する。 

情報を収集する：
問題に関する詳細情報を収集します。 

• 「Avamarクライアントのバックアップ パフォーマンスに関する問題を調査する際にサポートが必要とする情報（英語）」

バックアップ チェーンのどの部分に最も重大なボトルネックがあるかを確認する：
以下は、バックアップ チェーンの主要なコンポーネントを示す図です。  


ボトルネックは常に存在しますが、ボトルネックがどこにあるのかを確認するよう努める必要があります。
これを確認してボトルネックを軽減すると、パフォーマンスは向上するはずです。
ボトルネックが緩和されると、別のボトルネックが表面化する場合があります。最終目標は、バックアップに要する時間を業務上許容できる範囲に収めることです。


Avamarサーバー側のボトルネック：
Avamarサーバーのすべてのバックアップが遅い場合は、サーバー側に問題がある可能性を考慮してください。  
特定の時間帯にAvamarサーバーのすべてのバックアップが遅い場合は、サーバー側の競合またはネットワークのボトルネックを考慮してください。
1つまたはいくつかのバックアップ クライアントにパフォーマンスの問題がある場合は、各クライアントに単独で焦点を当てます。


サーバーの正常性：
正常なAvamarサーバーがバックアップのボトルネックになる可能性はほとんどありません。

バックアップ サーバーの正常性を確認します。  

• Avamar：Avamarサーバーでproactive_check.plヘルス チェック スクリプトを実行する方法
• バックアップがData Domainに送信されている場合は、DD Autosupport情報を確認するか、Data Domainサポートに連絡して正常性を確認します。

Avamarは、許容可能なレベルのパフォーマンスを維持するために、クライアント接続を制限します。


サーバーの競合：

バックアップ パフォーマンスが低い時間帯がある場合は、競合が発生している可能性があります。

• sched.shスクリプトを実行して、低速なバックアップと並行して実行されていたアクティビティーを視覚的に表示します。
• 「Avamar：sched.shスクリプトを使用してAvamar Server上のバックアップ、レプリケーション、メンテナンス アクティビティーの履歴を確認する方法（英語）」を参照してください。
• status.dpnを実行して、進行中のメンテナンス タスクを確認します。
• アクティブなクライアント セッションの数を確認します。

  • admin@utilitynode:~/>: avmaint session | grep path | wc -l

• メンテナンスとバックアップのスケジュールが重複しないように調整します。
• status.dpnコマンドとtopコマンドの出力をチェックして、データ ノードへの負荷を確認します。
• データ ノードでmapall 'iostat -x'を実行します。%iowait、%idle、%utilをチェックして、ディスクのI/O帯域幅が飽和状態になっているかどうかを確認します。
• 特定のクライアントのパフォーマンスを切り分けるには、Avamar Serverがメンテナンス タスク、その他のバックアップ、レプリケーションを実行していないときにバックアップをテストします。

Data Domainバックアップ取得のパフォーマンス：
Dellサポート ポータルにログインし、次の内容を確認します。

• Data Domain：DDPCONNCHK - Data Domain DDBoostの接続性とパフォーマンスをトラブルシューティングする方法

ネットワーク側のボトルネック：
クライアントがWAN経由でバックアップされている場合、ネットワークがボトルネックになる可能性があります。

ネットワーク レイテンシー：
これは、クライアントがAvamar Serverにハッシュが存在するかどうかを確認できる速度に影響します。  

• クライアントからAvamar Serverにpingを使用し、ネットワークのパケット ロスとレイテンシーを確認します。

2014-11-20 04:45:30 avtar Info <5156>: Backup #1180 timestamp 2014-11-20 04:45:28, 23 files, 5 folders, 291.7 GB (23 files, 4.316 GB, 1.48% new) 

クライアントとサーバーがWANで分離されている場合、リンクはバックアップ ウィンドウ内に必要なデータを送信できるでしょうか？
この場合、転送する必要があるデータは4.316 GBです。

以下の値はすべて相互に関連しています。

• 新しいバックアップ データの量
• バックアップに使用できる時間
• 有効なネットワーク帯域幅

新しいデータの量が多いほど、より多くのネットワーク帯域幅やより長いバックアップ時間が必要になります。
これらの要因には実用的な制限がありますが、ユーザーがある程度制御できます。
タイムリーなバックアップに対応するために、それらのどれかを操作できるかどうかを検討します。


ネットワークのボトルネックまたはサーバー通信の問題が疑われる場合：
クライアントとバックアップ デバイス間のネットワーク スループットを確認します。 

• 「Avamar - 2つのAvamarシステム間でiperfを実行してネットワーク スループットのパフォーマンスをテストする方法（英語）」

avtar comstatsログを有効にして、トラブルシューティングを効果的に行います。

• Avamar：avtar COMSTATSログを有効にして解釈し、通信に関する問題を診断する方法（英語）」

クライアント側のボトルネック：

• 「Avamarバックアップでまだ初期バックアップを実行しているために「Time Out - End」エラーで失敗する（英語）」

バックアップが早期にキャンセルされていないことを確認する：
バックアップ ログで「canceled」を検索します。以下は、ユーザーが待ちきれずにL1バックアップをキャンセルした例です。
 

2013-11-05 12:15:29 avtar Info <5157>: PARTIAL Backup #14 timestamp 2011-11-05 12:13:36, 2,030 files, 562 folders, 397.3 MB (691 files, 17.44 MB, 4.39% new)
2013-11-05 12:15:29 avtar Info <7539>: Label "MOD-xxxxxxxxxx", scheduled to expire 11/12/11, none backup
2013-11-05 12:15:29 avtar Info <6083>: Backed-up 397.3 MB in 1.36 minutes: 17 GB/hour (89,593 files/hour)
2013-11-05 12:15:29 avtar Info <7883>: Finished at 2011-11-05 12:15:29 GMT Standard Time, Elapsed time: 0000h:01m:21s
2013-11-05 12:15:29 avtar Info <8468>: Sending wrapup message to parent
2013-11-05 12:15:29 avtar Info <5314>: Command failed (exit code 10013: Externally canceled)

このようなケースでバックアップが正常に終了した場合、データは「PARTIAL Backup/部分バックアップ」として保持されます。

• Avamar：部分バックアップ機能と初期バックアップに関するベスト プラクティス

部分バックアップ ログからバックアップ パフォーマンスが分かる場合もありますが、完全な分析には完全なバックアップからのログが必要です。


ログでファイル キャッシュまたはハッシュ キャッシュのサイズ設定の問題を確認する：

• 「Avamar - Avamarクライアント ログでファイル キャッシュまたはハッシュ キャッシュのサイズ設定の問題を確認する方法（英語）」を参照してください。

「throttling」フラグがavtarに渡されているかどうかを確認する：
Avtar CPUまたはネットワーク スロットルは、バックアップ パフォーマンスを大幅に低下させます。
「Avamar：Avamarクライアントのシステム リソース（CPU、ネットワーク、I/O、メモリー）消費量をスロットリングする方法（英語）」を参照してください。

これは、バックアップ ログで検出できます。

2013-09-06 14:22:13 avtar Info <6557>: Network bandwidth throttling is enabled, limiting to approx. 0.512 Mbps (62.50 KB/sec)
2013-09-06 14:22:13 avtar Info <6558>: CPU throttling is enabled, limiting CPU usage to approx. 70%

Avamar ClientのCPUまたはメモリーのボトルネックがあるか確認する：
Avamarバックアップは、ハードウェアが許容する速度で実行され、リソースについて他のサービスと競合します。クライアントの本来の業務と忙しい時間帯を意識してください。

タスク マネージャーまたはProcess Explorer（Windowsの場合）または「top」コマンド（UNIXまたはLinuxの場合）を使用してクライアントを監視します。これにより、バックアップ中にCPUの飽和状態が発生しているかどうかが明らかになります。

Dellには、時間の経過に伴うリソースの消費量とパフォーマンスをグラフ化する内蔵「LogAnalyzer」ツールがあります。これを使用するには、サポートと連携してください。

キャッシュ ファイルはバックアップ中にメモリーにロードされます。クライアントのメモリー使用量を確認して、ページ フォールトや、クライアントがRAM不足であることを示すサインを監視します。

これは、Data DomainへのAvamar v7.xクライアントが「ページング キャッシュ」(f_cache2.dat)を利用している場合には、それほど問題ではありません。
ページング キャッシュは、従来の「モノリス型」avtarキャッシュと比較して、クライアントのメモリー フットプリントを削減します。


クライアント側のI/Oボトルネックを確認する：
クライアント キャッシュのサイズ設定後、バックアップ パフォーマンスを決定する次の要因は、バックアップ データをホストしてavtarにフィードするストレージ システムです。


ターゲット ストレージが正常であることを確認する：
最適なパフォーマンスを妨げるターゲット ストレージ デバイスに問題がないことを確認します。 
 

サード パーティー製ソフトウェアがI/Oに関してavtarと競合していないことを確認する：
ストレージI/Oに関してAvamar Clientと競合するクライアント上のアプリケーションはありますか？
ウイルス対策ソフトウェアのリアルタイムまたはオンアクセス スキャンは、Avamar Clientのパフォーマンスに大きく影響します。  

• Avamar Clientのバックアップ パフォーマンスは、ウイルス対策ソフトウェアによるファイルのリアルタイム スキャンの影響を多大に受けます

• 「ボリュームの並列化を使用したAvamarバックアップ パフォーマンスの向上」

クライアントがCIFSまたはNFSを使用してデータをバックアップしていないことを確認する：
CIFSまたはNFSデータのバックアップは、NDMPアクセラレーターを介してのみサポートされます。 

• 「AvamarとCIFS(SMB)およびNFSにマップされたネットワーク共有のサポート」 

ストレージ圧縮または暗号化が使用されているかを確認する：
ファイル システム レベルでデータが圧縮または暗号化されているターゲット ストレージにターゲット データが存在する場合、バックアップ パフォーマンスが予想よりも低くなる可能性があります。  


Perfmonを使用してWindowsクライアント リソースのボトルネックを分析する：
次の記事は、パフォーマンス グラフを作成して、クライアントが特定の時点で特定のリソースを待機しているかどうかを理解するのに役立ちます。これは、LogAnalyzerツールによって生成されたグラフと一緒に使用することを検討してください。

• 「Avamar - Microsoft Windows perfmonを使用してAvamarクライアントのパフォーマンスを監視する方法（英語）」 

Outlookアーカイブ.pstファイルのバックアップ：
多数のまたは大きな.pstファイルを含むバックアップは、実行速度が遅くなる場合があります。 

• 「Avamarを使用してOutlookアーカイブの.pstファイルをバックアップする際のパフォーマンスに関する考慮事項（英語）」

ストレージ パフォーマンスのベンチマーキング：
ターゲット データがホストされているストレージ デバイスのパフォーマンスを確認します。

• 「Avamar Linuxクライアントのディスク パフォーマンス テスト（英語）」 

バックアップされるデータによるバックアップ パフォーマンスの低下：
バックアップが遅くなる一般的な原因のひとつに、バックアップされるデータの性質が挙げられます。


新しいデータや変更されたデータが多数あるかどうかを確認する：

• 「Avamar - 新しいデータや変更されたデータが多数あるため、バックアップが遅いまたは「Time out - end」で失敗する（英語）」  

いくつかの大きな新しいファイルや変更されたファイルが原因で、高速に実行されるはずのバックアップがバックアップ ウィンドウを超える可能性があります。これらのファイルを特定する方法については、次を参照してください。

• Avamar：クライアント ログを使用して以前のバックアップ以降に新規または変更されたファイルを特定する方法（英語）」   
• 「Avamarバックアップ中に処理に時間がかかったファイルを特定する方法（英語）」 

Windowsクライアント

• 「多数のシンボリック リンクを含むデータセットのAvamarバックアップが非常に低速で実行される（英語）」  
• 「AvamarクライアントのパフォーマンスとWindows NTFS圧縮（英語）」 

LinuxおよびUNIXクライアント - クライアントのデータセットに大きなスパース ファイルが含まれているかどうかを確認します。 

• 「Avamarバックアップおよびスパース ファイル（英語）」 
• 「Avamar -Linuxクライアント バックアップのサイズは、「/var/log/lastlog」とスパース ファイル処理の動作が原因で誤解を招く可能性があります」 

バックアップ サマリー行を確認して、バックアップ範囲を把握し、外れ値を特定する：
バックアップ ログで文字列「Backup #」または「Backed-up」を検索します。

2017-06-07 20:21:38 avtar Info <5156>: Backup #441 timestamp 2017-06-07 20:21:38, 2,653,523 files, 255,181 folders, 1,566 GB (10,777 files, 668.4 MB, 0.04% new)
2017-06-07 20:21:38 avtar Info <6083>: Backed-up 1,566 GB in 1281.60 minutes: 73 GB/hour (124,228 files/hour)

これにより、バックアップのパフォーマンスを調査する時間を大幅に節約できます。
上記の出力では、次の点を考慮します。

1. これが初期バックアップであるか、レベル1バックアップであるか。（バックアップ ラベルが「#441」のため、可能性は低い）
2. バックアップ内のファイル数が妥当かどうか。（260万のファイルが妥当）
3. ファイルとフォルダーの比率は？（10:1で標準です）
4. データセット内のデータの合計量。（～1.5 TB）
5. 処理するファイルの数と、ファイルの合計数の割合。（250万ファイルのうち最大11,000ファイルが妥当）
6. 処理されるすべてのファイルの合計サイズ。（これは推定値に過ぎません）
7. Avamarサーバーに送信される変更済みデータの量。(668 MB)
8. 変更率が妥当かどうか。より小さいデータセットに対して、より高い変更率を許容できるか（0.04%が妥当）。
9. バックアップの全体的なサイズと範囲を考慮して、1時間あたりのパフォーマンスが妥当かどうか（他の数値を考慮して、124 Kのファイル/時間はパフォーマンスの低下と見なされます）。

これらの詳細情報は多くの場合、バックアップ パフォーマンスの低下原因を特定するために十分なデータを提供します。
必要に応じて、バックアップの過程で生成されるステータス行のメッセージを確認します。

これら2つのログ行のいずれかの値が外れ値であるかどうかを判断します。言い換えれば、それらは通常よりも大きいか、それとも小さいかです。
バックアップの動作を熟知していれば、異常を簡単に検出できます。


ファイル対フォルダーの比率
ほとんどのお客様のデータセットは、ファイル対フォルダーの比率が約10:1であり、avtarはこれを反映するように調整されています。
次の例のように、データセットのファイル対フォルダーの比率が低い場合は、軽微なチューニングを行わないとバックアップが効率的に実行されない可能性があります。  

2015-11-18 00:34:32 avtar Info <5156>: Backup #75 timestamp 2015-11-18 00:24:43, 4,007,032 files, 1,974,043 folders, 1,589 GB (2,680 files, 419.4 MB, 0.03% new)

「Avamar： ファイルとフォルダーの比率が低いデータセットのクライアント バックアップ パフォーマンスのチューニング」を参照してください。

avtarログのStatus情報メッセージを使用したパフォーマンス分析：
Notepad++などを使用して、ログでStatusメッセージを含むavtar Info行をフィルタリングします。これらは、Avamarクライアントのバージョンに応じて、<5100>または<8688>を含むコード エントリーを使用してフィルタリングできます。これらの行は、avtarによって報告された定期的なステータス メッセージです。

• 「Avamar - avtarバックアップ ログのステータス行を解釈する方法（英語）」  

• 「サード パーティー製ソフトウェアが変更しなくてよいファイルのメタデータを変更するためにAvamarバックアップの実行が遅くなる（英語）」 

包含フラグと除外フラグの使用を確認し、「include」ステートメントは避ける：
『Operational Best Practices guide』では、包含リストと除外リストについて説明しています。

Avamarは、バックアップ データセット内のすべてのファイルを両方のリストと比較して、ファイルをバックアップするかどうかを判断する必要があります。この比較プロセスではオーバーヘッドが増加し、バックアップの実行時間が長くなる可能性があります。

クライアントのavsarディレクトリーにavtar.cmdファイルが存在するかどうかを確認します。
そのファイルにアクティブな--excludeまたは--exclude-from-fileステートメントが含まれているかどうかを確認します。
ディレクトリーまたはファイル システムが除外されていても、includeフラグが使用されている場合、avtarは「include」と指示された項目をスキャンします。

データセットに再解析ポイントまたはスタブ ファイルが含まれているかどうかを確認する：
データセットにスタブ ファイルまたは別のデバイスに保存されているデータへのポインターが含まれている場合は注意してください。
avtarがリモート ファイルのリコールを待機する必要がある場合、バックアップ パフォーマンスが低下します。
このようなソフトウェアの例：Enterprise Vault Archiver、Moonwalk、DiskXtender。

• 「7.0から7.2にアップグレードした後、winclusterfsプラグイン バックアップのAvamarバックアップ パフォーマンスが低下する（英語）」

Avamarゲスト インストールを使用した仮想クライアントのバックアップ

• 「ハードウェア リソースのボトルネックが原因で仮想マシンのAvamarゲスト バックアップが遅くなりタイムアウトする（英語）」  
• 「VMware vShield Endpoint Trend Micro Deep SecurityによりAvamar VMクライアントのゲスト バックアップ パフォーマンスが低下する（英語）」  

• Avamar：7.0から7.2にアップグレードした後にwinclusterfsプラグイン バックアップのバックアップ パフォーマンスが低下する（英語）」 

その他の注意事項

• 仮想マシン クライアントにリソース制限がないこと、またはAvamarバックアップを迅速に完了する機能に影響を与える厳格なハードウェア制限に順守していることを確認します。  ビジー状態のマシンでは、オペレーティング システムが過負荷になるか、多数のスレッドを操作するため、重大なコンテキスト スイッチが発生する可能性があります。
• 『Avamar Operational Best Practices Guide』は、Avamarシステム、バックアップのスケジュール設定、クライアント キャッシュのチューニングを最適化する際に役立ちます。

その他の参照

• 「AvamarクライアントのパフォーマンスとWindows NTFS圧縮（英語）」