使用 DISKSPD 來測試工作負載儲存效能

發行項
02/26/2024

適用於：Azure Stack HCI 版本 22H2 和 21H2;Windows Server 2022、Windows Server 2019

本主題提供如何使用 DISKSPD 來測試工作負載儲存體效能的指引。您已設定好 Azure Stack HCI 叢集，一切已準備就緒。好的，但您要如何知道您在延遲、輸送量或 IOPS 上是否取得承諾的效能計量？這正是您轉換成 DISKSPD 的時候。閱讀本主題之後，您將了解如何執行 DISKSPD、了解參數子集、解讀輸出，以及大致了解影響工作負載儲存效能的變數。

什麼是 DISKSPD？

DISKSPD 是 I/O 產生的命令列工具，適用於微效能評定。那麼這些詞彙是什麼意思？任何設定 Azure Stack HCI 叢集或實體伺服器的人都有理由。您可以設定 Web 主控環境，或為員工執行虛擬桌面。無論實際的使用案例為何，您可能會想要在實際的應用程式部署之前模擬測試。不過，在實際案例中測試您的應用程式通常很困難 – 這時候就適合使用 DISKSPD。

DISKSPD 是一種工具，可讓您自訂建立您自己的綜合工作負載，並在部署前測試您的應用程式。這項工具最棒的地方在於它可讓您自由設定和調整參數，以建立類似您真正工作負載的特定案例。 DISKSPD 可讓您在部署之前深入了解系統的能力。在 DISKSPD 的核心只會發出一堆讀取和寫入作業。

現在您知道什麼是 DISKSPD，但何時該使用它？ DISKSPD 難以模擬複雜的工作負載。但是，當您的工作負載不是透過單一執行緒檔案複製來接近時，DISKSPD 就相當好用，而且您需要一個簡單的工具來產生可接受的基準結果。

快速入門：安裝和執行 DISKSPD

事不宜遲，讓我們開始吧：

從您的管理電腦，以管理員身分開啟 PowerShell，連線到您要使用 DISKSPD 測試的目標電腦，輸入下列命令，然後按下 [Enter]。
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
在此範例中，我們執行的虛擬機器 (VM) 稱為「節點 1」。

若要下載 DISKSPD 工具，請輸入下列命令，然後按下 [Enter] 鍵：

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.1.zip")

使用以下命令解壓縮下載的檔案：

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD

將目錄變更為 DISKSPD 目錄，並找出目標電腦執行的 Windows 作業系統適用的可執行檔。

在此範例中，我們使用的是 amd64 版本。

注意

您也可以直接從包括開放原始碼程式碼的 GitHub 存放庫，以及詳述所有參數和規格的 wiki 頁面下載 DISKSPD 工具。在存放庫的 [發行] 下，選取自動下載 ZIP 檔案的連結。

在 ZIP 檔案中，您會看到三個子資料夾：amd64 (64 位元系統)、x86 (32 位元系統) 和 ARM64 (ARM 系統)。這些選項可讓您在每個 Windows 用戶端或伺服器版本中執行此工具。
使用下列 PowerShell 命令來執行 DISKSPD。取代方括號內的所有設定，包括方括號本身以及您的適當設定。
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
以下是您可以執行的範例命令：
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
注意

如果您沒有測試檔案，請使用 -c 參數建立一個測試檔案。如果您使用此參數，當您定義路徑時，請務必包括測試檔案名。例如：[INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. 在範例命令中，IO.dat 是測試檔案名，test01.txt 是 DISKSPD 輸出檔案的名稱。

指定金鑰參數

很簡單吧？可惜的是，內容不只這樣。讓我們來解說執行的動作。首先，您可以使用各種不同的參數，且可取得特定的參數。不過，我們使用了下列一組基準參數：

注意

DISKSPD 參數會區分大小寫。

-t2：這表示每個目標 / 測試檔案的執行緒數目。此數目通常是根據 CPU 核心的數目。在此情況下，會使用兩個執行緒來對所有 CPU 核心進行壓力測試。

-o32：這表示每個執行緒每個目標未處理的 I/O 要求數目。這也稱為佇列深度，在此案例中，32 是用來對 CPU 進行壓力測試。

-b4K：這表示區塊大小 (以位元組、KiB、MiB 或 GiB 為單位)。在此情況下，會使用 4K 區塊大小來模擬隨機 I/O 測試。

-r4K：這表示對應到指定大小 (以位元組、KiB、MiB、Gib 或區塊) 的隨機 I/O (覆寫 -s 參數)。一般 4K 位元組大小用來正確對齊區塊大小。

-w0：這會指定寫入要求 (-w0 相當於 100% 取讀) 的作業百分比。在此情況下，會使用 0% 寫入作為簡單測試的目的。

-d120：這會指定測試的持續時間，不包括冷卻或準備時間。預設值為 10 秒，但建議您針對任何嚴重的工作負載至少使用 60 秒。在此情況下，會使用 120 秒來將任何極端值降至最低。

-Suw：停用軟體和硬體寫入快取 (相當於 -Sh)。

-D：依每個執行緒的每個目標，以毫秒為間隔來擷取 IOPS 統計資料 (例如標準差)。

-L：測量延遲統計資料。

-c5g：設定測試中使用的範例檔案大小。可以設定為位元組、KiB、MiB、GiB 或區塊。在此情況下，會使用 5 GB 的目標檔案。

如需完整的參數清單，請參閱 GitHub 存放庫。

了解環境

效能主要取決於您的環境。那麼，我們的環境呢？我們的規格包括具有存放集區的 Azure Stack HCI 叢集，以及儲存空間直接存取 (S2D)。更具體來說，有五個 VM：DC、節點 1、節點 2、節點 3 和管理節點。叢集本身是三個節點的叢集，具有三向鏡像復原結構。因此，系統會維護三個資料複本。叢集中的每個「節點」都是 Standard_B2ms 的 VM，IOPS 上限為 1920。在每個節點內，有四個 premium P30 SSD 磁碟機，IOPS 上限為 5000。最後，每個 SSD 磁碟機都有 1 TB 的記憶體。

您會在叢集共用磁碟區 (CSV) 提供 (C:\clusteredstorage)的統一命名空間下產生測試檔案，以用於整個磁碟集區。

注意

範例環境沒有 Hyper-V 或巢狀的虛擬結構。

如您所見，您可以在 VM 或硬碟限制中獨自達到 IOPS 或頻寬上限。因此，請務必了解您的 VM 大小和磁碟類型，因為兩者都有 IOPS 上限和頻寬上限。這知識有助於找出瓶頸，並了解您的效能結果。若要深入了解您的工作負載可能適合的大小，請參閱下列資源：

了解輸出

在您了解參數和環境之後，您就可以開始解讀輸出。首先，先前測試的目標是在不考慮延遲的情況下增加 IOPS 上限。如此一來，您就能以視覺化的方式查看是否達到 Azure 內的人工 IOPS 限制。如果您想要將整個 IOPS 圖形視覺化，請使用 Windows Admin Center 或工作管理員。

下圖顯示 DISKSPD 程序在我們的範例環境中的樣子。它會顯示來自非協調器節點的 1 MiB 寫入操作範例。三向復原結構以及來自非協調器節點的作業會導致兩個網路躍點，進而降低效能。如果您想要知道什麼是協調器節點，別擔心！您將在考慮事項一節中了解其內容。紅色方塊代表 VM 和磁碟機瓶頸。

既然您已經透過視覺化了解情況，讓我們來看看 .txt 檔案輸出的四個主要章節：

輸入設定

本節說明您執行的命令、輸入參數，以及測試回合的其他詳細資料。
CPU 使用率詳細資料

本節將重點說明測試時間、執行緒數目、可用的處理器數目，以及測試期間每個 CPU 核心的平均使用率等資訊。在此情況下，有兩個 CPU 核心平均的使用量大約為 4.67%。
總 I/O

這一節具有下列三小節。第一個小節強調整體效能資料，包括讀取和寫入作業。第二個和第三個小節會將讀取和寫入作業分割成不同的類別。

在此範例中，您可以看到在 120 秒的期間內，總 I/O 計數為 234408。因此，IOPS = 234408/120 = 1953.30。平均延遲為 32.763 毫秒，輸送量為 7.63 MiB/秒。從先前的資訊，我們知道 1953.30 IOPS 接近我們 Standard_B2ms VM 的 1920 IOPS 限制。不相信嗎？如果您使用不同的參數 (例如增加佇列深度) 來重新執行此測試，您會發現結果仍以這個數字為上限。

最後三個資料行顯示 IOPS 的標準差：17.72 (從 -D 參數) 、20.994 毫秒的延遲標準差 (從 -L 參數) 和檔案路徑。

從結果中，您可以快速判斷叢集設定是否很糟糕。您可以看到在達到 5000 的 SSD 限制之前，它會達到 1920 的 VM 限制。如果您受限於 SSD 而不是 VM，您可以透過延伸測試檔案到多個磁碟機，充分利用高達 20000 的 IOPS (4 個磁碟機 * 5000)。

最後，您必須決定特定工作負載可接受哪些值。下圖顯示一些重要的關聯性，可協助您取捨：

圖中的第二個關聯性很重要，有時也稱為利特爾法則。這項法則的概念是，有三個特性可管理程序行為，而您只需要變更一個特性即可影響另外兩個特性，也就是整個程序。因此，如果您對系統的效能感到不滿意，就有三個可自由影響效能的特點。利特爾法則決定在我們的範例中，IOPS 是「輸送量」(每秒的輸入輸出作業)，延遲是「佇列時間」，而佇列深度則是「庫存」。
延遲百分位數分析

最後一節將詳細說明儲存體效能從最小值到最大值，每個作業類型的百分位數延遲。

此章節很重要，因為它會判斷您的 IOPS「品質」。它會顯示有多少 I/O 作業可以達到特定的延遲值。由您決定該百分位數可接受的延遲。

此外，「9」指的是 9 的數目。例如，「999」相當於第 99 個百分位數。 9 的數目會揭露在該百分位數執行的 I/O 作業數目。最後，您將不再需要認真看待延遲值的情況。在此情況下，您可以看到延遲值在達到「9999」之後仍維持不變。此刻，延遲值是根據 234408 個作業中唯一的 I/O 作業產生。

考量事項

現在您已開始使用 DISKSPD，需要考慮幾件事才能取得實際的測試結果。這些包括密切注意您所設定的參數、儲存空間健康情況和變數、CSV 所有權，以及 DISKSPD 和檔案複製之間的差異。

DISKSPD 與實際情況

DISKSPD 的人工測試可為您的實際工作負載提供類似的結果。不過，您必須特別注意您所設定的參數，以及它們是否符合您的實際案例。請務必了解，在部署期間，綜合工作負載永遠無法完全代表您應用程式的實際工作負載。

準備

執行 DISKSPD 測試之前，有幾個建議的動作。其中包括驗證儲存空間的健全狀況、檢查您的資源使用狀況，以免其他程式干擾測試，以及在您想要收集其他資料時準備效能管理員。不過，因為本主題的目標是要讓 DISKSPD 快速執行，所以不會深入探討這些動作的細節。若要深入了解，請參閱 Windows Server 中使用綜合工作負載測試儲存空間效能。

影響效能的變數

儲存體效能是一項需小心處理的事情。也就是說，有許多變數可能會影響效能。因此，您可能會遇到與您的預期不一致的數字。以下是一些會影響效能的變數，但並不是完整的清單：

網路頻寬
復原選擇
儲存體磁碟設定：NVME、SSD 和 HDD
I/O 緩衝區
快取
RAID 設定
網路躍點
硬碟主軸速度

CSV 所有權

節點稱為「磁碟區擁有者」或「協調器」節點 (非協調器節點會是未擁有特定磁碟區的節點)。每個標準磁碟區都會被指派一個節點，而其他節點可以透過網路躍點存取此標準磁碟區，這會導致效能變慢 (更高的延遲)。

同樣地，叢集共用磁碟區 (CSV) 也有「擁有者」。不過，CSV 在每次您重新啟動系統 (RDP) 時，會以「動態」的方式來躍點及變更所有權。因此，請務必確認 DISKSPD 是從擁有 CSV 的協調器節點中執行。如果不是，您可能需要手動變更 CSV 所有權。

確認 CSV 所有權：

藉由執行下列 PowerShell 命令來檢查所有權：
```
 Get-ClusterSharedVolume
```
如果 CSV 所有權不正確 (例如，您位於節點 1，但節點 2 擁有 CSV)，請執行下列 PowerShell 命令，將 CSV 移至正確的節點：
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

檔案複製與 DISKSPD

有些人相信他們可以藉由複製並貼上超大的檔案，並測量該程式所花費的時間，來「測試儲存體效能」。使用這種方法的主要理由很可能是因為它既簡單又快速。它會測試特定的工作負載，因此這個想法沒什麼問題，但很難將此方法歸類為「測試儲存體效能」。

如果您的實際目標是要測試檔案複製效能，則這可能是使用此方法最佳的理由。但是，如果您的目標是要測量儲存體效能，建議您不要使用此方法。您可以將檔案複製程序視為使用一組不同的「參數」 (例如「佇列」、「平行處理」和「檔案服務」等等) 的特定檔案服務。

下列簡短摘要說明為何使用檔案複製來測量儲存體效能可能無法提供您所尋找的結果：

檔案複製可能未經過最佳化，有兩個層級的平行處理 (一內一外)。在內部，如果檔案複製是針對遠端目標，則 CopyFileEx 引擎會套用一些平行處理。在外部，叫用 CopyFileEx 引擎的方式有很多種。例如，來自檔案總管的複製是單一執行緒，但 Robocopy 為多執行緒。基於這些理由，請務必了解測試的含意是否為您要尋找的內容。
每個複本都有內外兩面。 當您只是複製並貼上檔案時，可能會使用兩個磁碟：來源磁碟和目的地磁碟。如果其中一個比另一個慢，您基本上是測量較慢磁碟的效能。在其他情況下，來源、目的地和複製引擎之間的通訊可能會以獨特的方式影響效能。

若要深入了解，請參閱使用檔案複製來測量儲存體效能。

實驗和一般工作負載

本節包括一些其他範例、實驗和工作負載類型。

確認協調器節點

如先前所述，如果您目前測試的 VM 未擁有 CSV，您將會看到效能下降 (IOPS、輸送量和延遲)，而不是在節點擁有 CSV 時進行測試。這是因為當您每次發出 I/O 作業時，系統會對協調器節點進行網路躍點以執行該操作。

在三個節點的三向鏡像情況下，寫入作業一律會建立網路躍點，因為它需要將資料儲存在三個節點的所有磁碟機上。因此，寫入作業無論如何都會建立網路躍點。但是，如果您使用不同的復原結構，可能會改變。

範例如下：

正在本機節點上執行：.\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
正在非本機節點上執行：.\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

在此範例中，您可以清楚地看到下圖的結果中，延遲減少、IOPS 增加，以及當協調器節點擁有 CSV 時會增加輸送量。

線上交易處理 (OLTP) 工作負載

線上交易處理 (OLTP) 工作負載查詢 (更新、插入、刪除) 著重於交易導向的工作。相較於線上分析處理 (OLAP)，OLTP 與儲存體的延遲相依。因為每個作業都只會發出少量的 I/O，您所在意的是每秒可承受的作業數目。

您可以設計 OLTP 工作負載測試，以專注於測試隨機的小型 I/O 效能。針對這些測試，請將焦點放在您可以發送輸送量的程度，同時維持可接受的延遲。

此工作負載測試的基本設計選擇至少應包括：

8 KB 的區塊大小 => 類似 SQL Server 用於其資料檔案的頁面大小
70% 讀取，30% 寫入 => 類似一般 OLTP 行為

線上分析處理 (OLAP) 工作負載

OLAP 工作負載著重於資料擷取和分析，讓使用者能夠執行複雜的查詢來解壓縮多維度資料。與 OLTP 相反，這些工作負載不太受儲存體延遲的影響。它們強調在不管頻寬的情況下將許多作業排入佇列。因此，OLAP 工作負載通常會導致較長的處理時間。

您可以設計 OLAP 工作負載測試，以專注於測試連續的大型 I/O 效能。針對這些測試，請將焦點放在每秒處理的資料量，而不是 IOPS 的數目。延遲需求也比較不重要，但這很主觀。