非經常性存取的 Azure NetApp Files 儲存體效能考量
資料集不一定會主動使用。 集合中最多 80% 的資料可視為「非經常性存取」,這表示目前未使用或最近未被存取。 在 Azure NetApp Files 等高效能儲存體上儲存資料時,所使用容量上花費的金錢基本上會浪費,因為再次存取非經常性存取資料之前,不需要高效能儲存體。
非經常性存取的 Azure NetApp Files 儲存體旨在降低 Azure 中雲端儲存體的成本。 特定使用案例中有需要考量的效能考量。
存取已移至非經常性存取層的資料會產生更多延遲,特別是針對隨機 I/O。 在最糟的情況下,正在存取的所有資料可能位於非經常性存取層,因此每個要求都需要進行資料擷取。 主動使用資料集中的所有資料在非經常性存取層中並不常見,因此不太可能觀察到這類延遲。
選取預設非經常性存取擷取原則時,系統會直接從非經常性存取層提供循序 I/O 讀取,而且不會重新填入經常性存取層。 隨機讀取資料會重新填入經常性存取層,以提升後續讀取的效能。 相較於隨機讀取,循序工作負載的最佳化通常會降低雲端擷取所產生的延遲,並改善整體效能。
在使用具 Azure NetApp Files 非經常性存取權的標準儲存體執行的近期測試中,取得了下列結果。
注意
所有已發佈的結果僅供參考之用。 結果不保證因為生產工作負載中的效能會因為許多因素而有所不同。
經常性/非經常性存取層的 100% 循序讀取 (單一作業)
在下列案例中,在使用 Ultra 效能層級的 50 TiB Azure NetApp Files 磁碟區上使用了單一 D32_V5 虛擬機器 (VM) 上的單一作業。 不同的區塊大小可用來測試經常性存取層和非經常性存取層的效能。
注意
Ultra 服務等級的最大值是每 TiB 配置容量 128 MiB/秒。 Azure NetApp Files 一般磁碟區可管理高達大約 5,000 MiB/秒的輸送量。
下圖顯示此測試使用各種佇列深度的非經常性存取層效能。 單一 VM 的最大輸送量約為 400 MiB/秒。
熱層效能較快 2.75 倍左右,上限約為 1,180 MiB/秒。
此圖表顯示 256K 區塊大小的非經常性存取層與經常性存取層效能並排比較。
造成經常性存取層和非經常性存取層延遲的原因為何?
經常性存取層的延遲是儲存體系統本身的一個因素,而當傳送至服務的 I/O 超過可在任何指定時間處理的 I/O 時,系統資源會耗盡。 因此,作業必須排入佇列,直到先前傳送的作業完成為止。
非經常性存取層的延遲通常出現於雲端擷取作業:透過網路向物件存放區發出 I/O 要求 (循序工作負載),或將非經常性區塊解除凍結至經常性存取層 (隨機工作負載)。
結果摘要
- 當工作負載為 100% 循序時,非經常性存取層的輸送量會比經常性存取層減少約 47% (相較於 1742 MiB/秒的 3330 MiB/秒)。
- 當工作負載為 100% 隨機時,非經常性存取層的輸送量會比經常性存取層減少約 88% (相較於 280 MiB/秒的 2479 MiB/秒)。
- 執行 100% 循序 (3,330 MiB/秒) 和 100% 隨機 (2,479 MiB/秒) 工作負載時,經常性儲存層的效能下降約 25%。 執行 100% 循序 (1,742 MiB/秒) 和 100% 隨機 (280 MiB/秒) 工作負載時,非經常性儲存層的效能下降約 88%。
- 當工作負載包含任意百分比的隨機 I/O 時,非經常性存取層的整體輸送量更接近 100% 隨機 (與 100% 循序相比)。
- 從 100% 循序移至 80/20 循序/隨機混合時,來自非經常性存取層的讀取下降約 50%。
- 循序 I/O 可以利用 Azure NetApp Files 中隨機 I/O 未使用的
readahead
快取。 循序 I/O 的優點有助於降低經常性存取層與非經常性存取層之間的整體效能差異。
考慮和建議
- 如果工作負載經常以無法預測的方式變更存取模式,非經常性存取可能會因為經常性存取層與非經常性存取層之間的效能差異而不太理想。
- 如果工作負載包含任意百分比的隨機 I/O,則存取非經常性存取層上的資料時,效能預期應據以調整。
- 設定非經常性存取期間和非經常性存取擷取設定,以符合您的工作負載模式,並將非經常性存取層擷取量降到最低。
- 非經常性存取的效能可能會因應用程式執行所在的數據集和系統負載而有所不同。 建議您使用數據集進行相關測試,以瞭解並考慮非經常性存取的效能變化。