了解和最佳化 Azure 檔案共用效能

✔️ 適用於： 以 Microsoft.Storage 資源提供者建立的經典 SMB 與 NFS 檔案共享

✔️ 適用於： 使用 Microsoft.FileShares 資源提供者建立的檔案共用

Azure 檔案儲存體可以滿足大部分應用程式和使用案例的效能需求。 本文說明影響檔案分享效能的不同因素，以及如何針對您的工作負載優化 Azure 檔案儲存體 的效能。

儲存效能詞彙表

在閱讀本文之前，可先了解與儲存體效能相關的一些重要詞彙：

  • 每秒的 I/O 作業數 (IOPS)

    IOPS (每秒的輸入/輸出作業) 會測量每秒檔案系統作業的數目。 在 Azure 檔案儲存體 文件中，「IO」一詞與「操作」和「交易」可互換。

  • I/O 大小

    I/O 大小 (有時稱為區塊大小) 是應用程式用來在儲存體上執行單一輸入/輸出 (I/O) 作業的要求大小。 視應用程式而定，I/O 大小的範圍可以從 4 KiB 到較大的大小。 I/O 大小對於達成輸送量而言至關重要。

  • 輸送量

    輸送量會測量每秒讀取或寫入儲存體的位元數，並以每秒的兆位元組數為單位測量 (MiB/秒)。 若要計算輸送量，請將 IOPS 乘以 I/O 大小。 例如，10,000 IOPS × 1 MiB I/O 大小 = 10 GiB/s，而 10,000 IOPS × 4 KiB I/O 大小 = 38 MiB/s。

  • 延遲

    延遲是延遲的同義字，並以毫秒為單位來測量。 延遲有兩種類型：端對端延遲和服務延遲。 如需詳細資訊，請參閱延遲。

  • 佇列深度

    佇列深度是儲存體資源一次可處理的擱置 I/O 要求數目。 如需詳細資訊，請參閱佇列深度。

根據使用模式選擇媒體層

Azure 檔案儲存體 提供兩種儲存媒介層級，可以用來平衡效能與價格：SSD 和 HDD。 你可以在儲存帳號層級選擇檔案分享的媒體層級。 在特定媒體層級建立儲存帳號後，若不 手動遷移到新的檔案共享，就無法移動到另一個媒體層級。

在選擇 SSD 或 HDD 檔案分享時，請考慮你計畫在 Azure 檔案儲存體 上運行的預期使用模式。 如果你需要大量 IOPS、快速資料傳輸速度或低延遲，請選擇 SSD 檔案分享。

下表摘要說明 SSD 與 HDD 檔案共用之間的預期效能目標。 詳細資料請參閱Azure 檔案儲存體擴充性和效能目標。

使用模式需求 SSD HDD
寫入延遲 (單一位數毫秒) 是 是
讀取延遲 (單一位數毫秒) 是 否

SSD 檔案分享採用配置模型，根據共享空間大小保證以下效能配置。 如需詳細資訊，請參閱佈建的 v1 模型 (部分內容可能是機器或 AI 翻譯)。

效能最佳做法

無論您是評估新工作負載或現有工作負載的效能需求，瞭解您的使用模式可協助您達到可預測的效能。

  • 延遲敏感度： 對讀取延遲敏感且對終端使用者能高度可視的工作負載，更適合 SSD 檔案分享，因為 SSD 在讀寫操作中可提供毫秒的延遲（小 I/O 容量可達不到 2 毫秒）。

  • IOPS 和輸送量需求： SSD 檔案共享支援比 HDD 檔案共用更大的 IOPS 和輸送量限制。 欲了解更多資訊，請參閱 檔案分享規模目標。

  • 工作量持續時間與頻率： 短（分鐘）和不頻繁（每小時）工作負載較不容易達到硬碟檔案共享的上限，相較於長時間且頻繁發生的工作負載。 在 SSD 檔案分享中，工作負載持續時間有助於根據配置的儲存空間、IOPS 和吞吐量決定正確的效能配置。 一個常見錯誤是只執行幾分鐘的性能測試，這往往具有誤導性。 為了獲得真實的表現，請確保你測試的頻率和持續時間足夠高。 在已配置的檔案共用中，短測試可測量點數制的突發 IOPS，而非已配置的 IOPS。 更多資訊請參見 高載量處理。

  • 工作負載平行處理： 對於平行執行作業的工作負載，例如透過相同用戶端上的多個線程、進程或應用程式實例，SSD 檔案共用提供比 HDD 檔案共用清楚的優勢：SMB 多重通道。 欲了解更多資訊，請參閱提升 SMB Azure 檔案分享效能。

  • API 操作分布：中繼資料量較多的工作負載，例如對大量檔案執行讀取操作的工作負載，更適合 SSD 檔案分享。 如需詳細資訊，請參閱 元資料或命名空間密集的工作負載。

  • 區域配置：使用區域配置選擇您的儲存帳戶所在的特定可用性區域。 此功能允許您將虛擬機置於與儲存裝置相同的可用性區域，延遲可減少高達 30%。 此功能目前僅適用於支援 區域內使用本地冗餘儲存（LRS）的 SSD 儲存帳號。

突發性

使用已配置 v2 或 provisioned v1 計費模式的檔案分享，支援基於信用的 IOPS 突發。 基於信用的突發讓檔案共用在有限時間內使用比其配置的 IOPS 更多的IOPS。 以額度為基礎的突發擴充是檔案共用的一項功能。 突發流量是一種工作負載模式，IOPS 或吞吐量會有短暫尖峰。 以點數為基礎的突發處理可以吸收突發流量造成的短暫 IOPS 尖峰。

基於信用的突發擴充費用包含在已設定的檔案共用費用中，且不會在帳單上增加費用。 點數型突發效能僅適用於 IOPS。 它不會讓吞吐量超過佈建的吞吐量。

隨用即付檔案分享不適用於突增功能。 可突發的經典檔案分享仍受儲存帳戶的 IOPS 限制。 欲了解更多資訊，請參閱 經典檔案共享資料平面限制。 關於突發如何影響成本的資訊，請參閱「了解 Azure 檔案儲存體 計費」。

已佈建的 v2 高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 利用這種彈性作為防範意外 IO 激增的緩衝。 對於已建立的 IO 模式，應預留 IO 峰值。

當檔案共享的流量低於佈建的 (基準) IOPS 時，突發 IOPS 點數會累積。 每當檔案共用的 IOPS 使用量超過所配置的 IOPS，且有可用的突增 IOPS 點數時，檔案共用可以突增至允許的最大突增 IOPS 限制。 只要額度有剩餘，檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 所有積分用盡後，效能會恢復為已佈建的 IOPS。 針對檔案共用的 IOPS 不需要執行任何特殊動作，即可使用高載。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，表示檔案共用使用小於已佈建 IOPS。
  • 減少，表示檔案共用使用超過已佈建 IOPS，且處於高載模式。
  • 固定，當檔案共用恰好使用已佈建的 IOPS，且未累積或使用任何點數時。

新的檔案共用最初會具有其高載貯體中的完整額度。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定檔案共用的高載 IOPS 限制和可能的額度數量：

Item SSD 公式 HDD 公式
高載 IOPS 限制 MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
高載 IOPS 額度 (BurstLimit - ProvisionedIOPS) * 3600 (BurstLimit - ProvisionedIOPS) * 3600

下表說明這些公式的幾個範例，適用於各種布建的 IOPS 數量：

已佈建 IOPS SSD 高載 IOPS 限制 SSD 高載額度 HDD 高載 IOPS 限制 HDD 高載額度
500 -- -- 最高 5,000 16,200,000
1,000 -- -- 最高 5,000 14,400,000
3,000 最高 10,000 25,200,000 最高 9,000 21,600,000
5,000 最高 15,000 36,000,000 最高 15,000 36,000,000
10,000 最高 30,000 72,000,000 最高 30,000 72,000,000
25,000 最高 75,000 180,000,000 最高 50,000 90,000,000
50,000 最高 102,400 188,640,000 最高 50,000 0
75,000 最高 102,400 98,640,000 -- --
102,400 最高 102,400 0 -- --

已佈建 v1 高載

配置型 v1 支援兩種突發方式：基於信用的突發，無需額外費用；以及付費突發，您可以選擇啟用，允許 IOPS 和輸送量超過已佈建的量，並依使用量收費。

已佈建 v1 額度型高載

以信用為基礎的 IOPS 突增功能為 IOPS 使用量提供更多的彈性。 利用這種彈性作為防範意外 IO 激增的緩衝。 對於已建立的 IO 模式，應預留 IO 峰值。

每當傳統檔案共用的流量低於配置（基準值）IOPS 時，突增 IOPS 點數就會累積。 每當傳統檔案共用的 IOPS 使用量超過佈建的 IOPS 且有可用的高載 IOPS 點數時，傳統檔案共用可能會高載至允許的最高高載 IOPS 限制。 只要額度有剩餘，傳統檔案共用就可以持續高載，這是以累積的高載額度數量為基礎。 超過布建 IOPS 的每個 IO 都會耗用一個點數。 當所有點數都用盡後，經典檔案共用會恢復為已佈建的 IOPS。 針對傳統檔案共用的 IOPS 不需要執行任何特殊動作即可使用突增。 高載會盡力運作。

共用額度有三種狀態：

  • 累積，當傳統文件共享的使用量低於配置的 IOPS 時。
  • 當傳統檔案共用使用的 IOPS 超過佈建數且處於突發模式時，會下降。
  • 固定，當傳統檔案共用正好使用配置好的 IOPS，且沒有積累或使用任何額度時。

新的傳統檔案共用將從爆發儲存桶中的完整額度點數開始。 如果共用 IOPS 因伺服器節流而低於佈建的限制，高載額度將不會累積。 下列公式是用來決定傳統檔案共用的高載 IOPS 限制和可能的額度數量：

Item Formula
高載限制 MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
高載額度 (BurstLimit - BaselineIOPS) * 3600

下表展示配置大小的這些公式的幾個範例：

容量 （GiB） 基準 IOPS 高載 IOPS 高載額度 輸送量 （MiB/秒）
100 3,100 最高 10,000 24,840,000 110
500 3,500 最高 10,000 23,400,000 150
1,024 4,024 最高 10,000 21,513,600 203
5,120 8,120 最高 15,360 26,064,000 613
10,240 13,240 最高 30,720 62,928,000 1,125
33,792 36,792 最高 102,400 227,548,800 3,480
51,200 54,200 最高 102,400 164,880,000 5,220
102,400 102,400 最高 102,400 0 10,340

已佈建 v1 付費高載

付費高載是已佈建 v1 模型的進階功能，其設計目的是支援從未想要節流的客戶。 付費高載會針對佈建儲存體上方的任何 IOPS 或輸送量，增加額外的使用量型計費。 此功能有別於以點數為基礎的突發效能；後者作為佈建儲存的一部分免費提供。 雖然付費高載可以增加您佈建傳統檔案共享的強大彈性，但如果使用不正確，也可能會導致非預期的計費。

與額度型高載一樣，付費高載並不是用來佈建正確 IOPS 和輸送量的替代方式。 相反地，如果您遇到非預期的需求，它會提供進一步保護來防止節流 如果你有穩定的 IOPS 或吞吐量使用率，透過儲存配置配置足夠的 IOPS 和吞吐量來滿足需求，比起依賴付費突發來得便宜。

付費突發擴增預設為停用，但您可以依照變更已佈建 v1 傳統檔案共用的成本與效能特性的指示來啟用它（僅限 PowerShell 和 CLI）。 如果您啟用付費突增，請使用 Azure 監視器 中提供的下列計量來監視 IOPS 和輸送量使用量：

  • 檔案共用佈建的 IOPS
  • 檔案共用布建頻寬 MiB/秒 （輸送量）
  • 根據最大 IOPS 的交易
  • 最大 MiB/秒的頻寬 (輸送量)
  • IOPS 高載額度 (額度型高載)
  • 付費高載 IOS (IO)
  • 付費高載頻寬

延遲 (Latency)

談到延遲，首先要了解 Azure 檔案儲存體 如何決定延遲。 最常見的度量是與端對端延遲和服務延遲計量相關聯的延遲。 利用這些 交易指標 ，能幫助你辨識客戶端延遲與網路問題，透過顯示應用程式流量往返客戶端所花費的時間。

  • 端對端延遲 (SuccessE2ELatency) 是交易執行從用戶端、經由網路、到 Azure 檔案儲存體服務、回到用戶端的完整來回行程所花費的總時間。

  • 服務延遲（SuccessServerLatency）是指交易僅在 Azure 檔案儲存體 內往返所需的時間。 此測量不包含用戶端或網路延遲。

    比較 Azure 檔案儲存體用戶端延遲和服務延遲的圖表。

SuccessE2ELatency 和 SuccessServerLatency 值之間的差異可能是由網路和/或用戶端所造成的延遲。

將用戶端延遲與服務延遲 (在此案例中為 Azure 檔案儲存體效能) 混淆很常見。 例如，如果服務延遲報告低延遲，而端對端延遲報告請求延遲非常高，那麼所有時間都花在往返用戶端的傳輸上，而非在 Azure 檔案儲存體 服務中。

此外，如圖所示，距離服務越遠，延遲體驗越慢，且任何雲端服務都越難達成效能尺度極限。 這種情況在從本地端存取 Azure 檔案儲存體 時尤其明顯。 雖然像 Azure ExpressRoute 這類方案非常適合本地部署，但它們仍無法匹敵只在同一 Azure 區域內執行的應用程式（運算+儲存）的效能。

提示

使用 Azure 中的 VM 來測試內部部署與 Azure 之間的效能，是比較 Azure 連線網路功能的實際有效方式。 尺寸不足或未正確路由的 ExpressRoute 線路或 VPN 閘道可能會顯著降低在 Azure 檔案上運行的工作負載速度。

佇列深度

佇列深度是儲存體資源可服務的擱置 I/O 要求數目。 隨著儲存系統所用的磁碟從硬碟軸（IDE、SATA、SAS）演進到固態裝置（SSD、NVMe），也演進以支援更高的佇列深度。 如果工作負載是由單一用戶端所組成，且該用戶端會與大型資料集內的單一檔案依序互動，就是低佇列深度的一個例子。 相反地，支援多個執行緒和多個檔案同時處理的工作負載可以輕鬆達到高佇列深度。 因為 Azure 檔案儲存體 是一個分散式檔案服務，涵蓋數千個 Azure 叢集節點，設計用來大規模執行工作負載，並建立並測試高隊列深度的工作負載。

你可以用多種方式達到高排隊深度。 要確定你的工作負載佇列深度，請將用戶端數量乘以檔案數再乘以執行緒數（用戶端×檔案 ×執行緒 = 佇列深度）。

下表說明了你可以用來增加排隊深度的各種組合。 雖然你可以超過最佳佇列深度 64，但不建議這麼做。 如果這麼做，將不會再看到效能提升，而且因為 TCP 飽和而有增加延遲的風險。

用戶端 檔案 執行緒 佇列深度
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 32

提示

為了達到最高效能限制，請確保你的工作負載或基準測試是多執行緒，包含多個檔案。

單執行緒與多執行緒應用

Azure 檔案儲存體 在多執行緒應用程式中運作最佳。 理解多執行緒對工作負載效能影響最簡單的方法是透過 I/O 來了解整個情境。 以下範例中，你有一個工作負載需要盡快將 10,000 個小型檔案複製到或從 Azure 檔案分享中複製。

此表格會根據以 4 KiB 區塊大小寫入的單一執行緒應用程式，細分在 Azure 檔案共用上建立單一 16 KiB 檔案所需的時間 (以毫秒為單位)。

I/O 作業 建立 4 KiB 寫入 4 KiB 寫入 4 KiB 寫入 4 KiB 寫入 關閉 總計
執行緒 1 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒

在此範例中，從六個操作中建立一個 16 KiB 檔案約需 14 毫秒。 如果單執行緒應用程式想將 10,000 個檔案移到 Azure 檔案分享，這個操作會轉換成 140,000 毫秒（× 10,000 毫秒）或 140 秒，因為每個檔案是依序移動的。 每個請求的服務時間主要取決於計算與儲存之間的距離，如前一節所述。

透過使用八個執行緒而非一個執行緒，你可以將先前的工作負載從 140,000 毫秒（140 秒）降到 17,500 毫秒（17.5 秒）。 如下表所示，當你同時移動八個檔案而非一次一個時，你可以在87.5% 更短的時間內移動相同數量的資料。

I/O 作業 建立 4 KiB 寫入 4 KiB 寫入 4 KiB 寫入 4 KiB 寫入 關閉 總計
執行緒 1 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 2 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 3 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 4 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 5 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 6 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 7 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒
執行緒 8 3 毫秒 2 毫秒 2 毫秒 2 毫秒 2 毫秒 3 毫秒 14 毫秒

另請參閱

  • 上次更新時間：