Avamar：備份效能緩慢故障診斷

  
備份效能緩慢的典型徵兆：

• 備份無法在排程時間內完成。活動監視器回報「Client time out - end」
• 備份無法在排程時間結束前啟動。活動監視器回報「Client time out - start」
• 垃圾收集定期失敗，並顯示 MSG_ERR_BACKUPSINPROGRESS 或 MSG_ERR_TRYAGAINLATER 

收集資訊：
收集有關此問題的詳細資訊： 

• 在調查 Avamar Client 備份效能問題時，支援部門所需的資訊。

判斷備份鏈的哪一部分具有最嚴重瓶頸：
以下示意圖顯示備份系統中的主要元件。  


瓶頸始終存在，但我們應該努力瞭解它們在哪裡。
如果我們能夠做到這一點，並緩解瓶頸，效能應該會提高。
一旦瓶頸得到緩解，另一個瓶頸可能會變得明顯。我們的最終目標是達到可接受備份持續時間的情況。


Avamar Server 端瓶頸：
如果對 Avamar Server 的所有備份速度皆變慢，請考慮發生伺服器端問題的可能性。  
如果對 Avamar Server 的所有備份在一天中的特定時間變慢，請考慮伺服器端的爭奪或網路瓶頸。
如果一或幾個備份用戶端發生效能問題，請著重於每個用戶端本身。


伺服器健全狀況：
健全狀況良好的 Avamar Server 不太可能成為備份的瓶頸。

檢查備份伺服器的健全狀況。  

• Avamar：如何在 Avamar Server 上執行 proactive_check.pl 健全狀況檢查指令檔
• 如果備份傳送至 Data Domain，請檢查 DD 自動支援資訊或聯絡 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 - 如何在兩個 Avamar 系統之間執行 iperf，以測試網路輸送效能

啟用 avtar comstats 記錄，以利進行故障診斷。

• Avamar：如何啟用和解譯 avtar COMSTATS 紀錄，以針對通訊問題進行故障診斷

用戶端瓶頸：

• Avamar 備份失敗並顯示「Time Out - End」，因為它仍在執行初始備份

確定並未提前取消備份：
在備份記錄中搜尋「已取消」。以下是缺乏耐心的使用者取消 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)

在這種情況下，如果備份為正常終止，則資料會保留為「部分」備份。

• Avamar：初始備份的部分備份功能和最佳實務

雖然部分備份記錄會指出備份效能，但正確分析需要來自已完成備份的記錄。


檢查記錄以確認是否發生檔案快取或雜湊快取大小問題：

• 請參閱 Avamar - 如何檢查 Avamar Client 記錄，以確認是否發生檔案快取或雜湊快取大小問題

檢查是否有節流旗標傳遞至 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 不足的線索。

當 Avamar v7.x 用戶端至 Data Domain 使用「分頁快取」(f_cache2.dat) 時，這個問題就不那麼嚴重了。
與傳統的「大型」avtar 快取相比，分頁快取減少了用戶端上的記憶體佔用情況。


檢查用戶端 I/O 瓶頸：
在調整用戶端快取大小之後，決定備份效能的下一個因素是儲存系統，因為該儲存系統負責託管備份資料，並將其傳送至 avtar。


確定目標儲存裝置的狀況良好：
請確定目標儲存裝置沒有任何問題會導致無法發揮最佳效能。 
 

請確定第三方軟體並未與 avtar 競爭 I/O：
用戶端上是否有任何應用程式與 Avamar Client 競爭儲存 I/O？
防毒軟體的即時或存取時掃描會大幅影響 Avamar Client 效能。  

• Avamar 用戶端備份效能會受到防毒軟體即時檔案掃描的嚴重影響

• 使用磁碟區平行處理改善 Avamar 備份效能

確定用戶端未使用 CIFS 或 NFS 進行備份
僅支援透過 NDMP 加速器進行 CIFS 或 NFS 資料的備份。 

• 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」和 Avamar 稀疏檔案處理行為而產生誤導 

查看備份摘要行，以瞭解備份範圍並識別離群值：
在備份記錄中搜尋「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 萬個檔案中約有 1 萬 1 千，屬於合理範圍)
6. 所有待處理檔案的總大小。(這僅為預估值)
7. 要傳送到 Avamar 伺服器的變更資料量。(668 MB)
8. 變更率是否合理。若資料集較小，則可容許較高的變更率 (0.04% 為合理範圍)
9. 基於備份的整體大小和範圍而定，每小時的效能是否合理。(根據其他特性，每小時 12 萬 4 千個檔案屬於效能緩慢)

這些詳細資料通常能提供足夠的資料，讓我們瞭解備份效能不佳的原因。
如有必要，請檢閱在備份執行過程中產生的狀態行訊息。

判斷這兩個記錄行中是否有任何值為離群值。換言之，它們是否比標準值更大或更小？
如果您熟悉備份行為，則更容易偵測到異常。


檔案與資料夾的比例
大部分客戶資料集的檔案與資料夾比例大約是 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 Client 備份效能調整。

使用 avtar 記錄狀態資訊訊息進行效能分析：
使用 Notepad++ 或類似應用程式，在記錄中篩選包含狀態訊息的 avtar Info 行。視 Avamar Client 的版本而定，您可以使用包含 <5100> 或 <8688> 的代碼項目進行篩選。這些行是由 avtar 回報的定期狀態訊息。

• Avamar - 如何解釋 avtar 備份記錄狀態行。  

• 由於第三方軟體為其他無變更的檔案修改中繼資料，導致 Avamar 備份作業執行緩慢 

檢閱包含和排除旗標的使用方式。避免使用「包含」陳述式：
作業最佳實務指南中討論了「包含」和「排除」清單。

Avamar 必須將備份資料集中的每個檔案與兩個清單進行比較，以判斷是否備份檔案。此比較程序會消耗額外效能，並可能會延長備份執行時間。

檢查用戶端的 avsar 目錄是否具有 avtar.cmd 檔案。
檢查該檔案是否包含任何作用中的 --exclude 或 --exclude-from-file 陳述式。
若排除目錄或檔案系統，但使用了包含旗標，avtar 會對其進行掃描，以尋找被告知要「包含」的項目。

檢查資料集是否包含重新解析點或存根檔案：
如果資料集包含存根檔或指向儲存在其他裝置上的資料，請小心。
若 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 作業最佳實務指南，協助最佳化 Avamar 系統、排程備份和調整用戶端快取。

其他參考資料

• Avamar 用戶端效能和 Windows NTFS 壓縮