使用 DISKSPD 來測試工作負載儲存效能
適用於：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 很難模擬複雜的工作負載。 但是，當工作負載不是由單個線程檔案複本所接近，而且您需要一個簡單的工具來產生可接受的基準結果時，磁碟PD 非常出色。
快速入門：安裝和執行 DISKSPD
若要安裝和執行 DISKSPD，請以管理電腦上的系統管理員身分開啟 PowerShell，然後遵循下列步驟：
若要下載並展開 DISKSPD 工具的 ZIP 檔案，請執行下列命令：
# Define the ZIP URL and the full path to save the file, including the filename $zipName = "DiskSpd.zip" $zipPath = "C:\DISKSPD" $zipFullName = Join-Path $zipPath $zipName $zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName # Ensure the target directory exists, if not then create if (-Not (Test-Path $zipPath)) { New-Item -Path $zipPath -ItemType Directory | Out-Null } # Download and expand the ZIP file Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName Expand-Archive -Path $zipFullName -DestinationPath $zipPath若要將 DISKSPD 目錄新增至
$PATH環境變數，請執行下列命令：$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE if ($env:path -split ';' -notcontains $diskspdPath) { $env:path += ";" + $diskspdPath }使用下列 PowerShell 命令執行 DISKSPD。 將方括弧取代為適當的設定。
diskspd [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：這表示隨機 I/O 會對齊以位元組、KiB、MiB、Gib 或區塊為單位的指定大小（覆寫 -s 參數）。 常見的 4K 位元組大小是用來正確對齊區塊大小。
-w0：這會指定寫入要求的作業百分比（-w0 相當於 100% 讀取）。 在此情況下，0% 的寫入是用於簡單的測試。
-d120：這會指定測試的持續時間，不包括冷卻或熱身。 默認值為 10 秒，但建議在任何嚴重工作負載至少使用 60 秒。 在此情況下，使用120秒將任何極端值降到最低。
-Suw：停用軟體和硬體寫入快取（相當於 -Sh）。
-D：以毫秒間隔擷取 IOPS 統計數據，例如標準偏差（每個線程、每個目標）。
-L：測量延遲統計數據。
-c5g：設定測試中使用的範例檔案大小。 可以設定為位元組、KiB、MiB、GiB 或區塊。 在此情況下，使用了 5 GB 的目標檔案。
如需參數的完整清單，請參閱 GitHub 存放 庫。
了解環境
效能嚴重取決於您的環境。 那麼，我們的環境是什麼？ 我們的規格牽涉到具有存放集區和 儲存空間直接存取 （S2D） 的 Azure Stack HCI 叢集。 更具體來說，有五個 VM：DC、node1、node2、node3 和管理節點。 叢集本身是具有三向鏡像復原結構的三節點叢集。 因此，會維護三個數據複本。 叢集中的每個「節點」都是Standard_B2ms VM，最大 IOPS 限制為 1920。 在每個節點中，有四個進階 P30 SSD 磁碟驅動器，最大 IOPS 限制為 5000。 最後，每個 SSD 磁碟驅動器都有 1 TB 的記憶體。
您會在叢集共用磁碟區 （CSV） 提供的統一命名空間下產生測試檔案，以使用整個磁碟驅動器集區。
注意
範例環境沒有 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秒期間234408 I/O 計數總計。 因此，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 參數），以及檔案路徑。
從結果中，您可以快速判斷叢集設定很糟糕。 您可以看到它在 SSD 限制 5000 之前達到 1920 的 VM 限制。 如果您受限於 SSD 而非 VM，則可以跨多個磁碟驅動器跨越測試檔案，利用最多 20000 個 IOPS（4 個磁碟驅動器 * 5000 個磁碟驅動器）。
最後，您必須決定特定工作負載可接受的值。 下圖顯示一些重要的關聯性，可協助您考慮取捨：
這個數位中的第二種關係很重要，有時被稱為《小法》。 法律介紹一個概念，即有三個特性可控管進程行為，而您只需要變更一個來影響另一個，進而影響整個程式。 因此，如果您對系統的效能不滿意，您有三個自由維度來影響它。 Little's Law 規定，在我們的範例中，IOPS 是「輸送量」（每秒的輸入輸出作業）、延遲是「佇列時間」，而佇列深度則是「清查」。
延遲百分位數分析
最後一節詳述記憶體效能每個作業類型的百分位數延遲，從最小值到最大值。
本節很重要，因為它會決定 IOPS 的「品質」。 它會顯示有多少 I/O 作業能夠達到特定延遲值。 您必須決定該百分位數可接受的延遲。
此外，“九”是指九人的數目。 例如，“3-9s” 相當於第 99 個百分位數。 九個數目會公開在該百分位數上執行的 I/O 作業數目。 最後，您將會到達一個點，讓延遲值變得不再有意義。 在此情況下，您可以看到延遲值在 「4-9s」 之後維持不變。 此時，延遲值只會以234408作業中的一個 I/O 作業為基礎。
考量的事項
既然您已開始使用 DISKSPD，現在需要考慮數件事來取得真實世界的測試結果。 其中包括密切關注您設定的參數、儲存空間健全狀況和變數、CSV 擁有權，以及 DISKSPD 與檔案複製之間的差異。
DISKSPD 與真實世界
DISKSPD 的人工測試提供您實際工作負載的相對比較結果。 不過，您必須密切關注您設定的參數，以及它們是否符合您的實際案例。 請務必了解綜合工作負載永遠不會在部署期間完美地代表應用程式的實際工作負載。
準備
在執行 DISKSPD 測試之前，有幾個建議的動作。 這些包括驗證儲存空間的健康情況、檢查您的資源使用量，讓另一個程式不會干擾測試，以及如果您想要收集其他數據，請準備效能管理員。 不過，由於本主題的目標是要快速執行 DISKSPD，因此不會深入探討這些動作的詳細數據。 若要深入瞭解，請參閱在 Windows Server 中使用綜合工作負載測試 儲存空間 效能。
影響效能的變數
記憶體效能是一件微妙的事情。 也就是說，有許多變數可能會影響效能。 因此，您可能會遇到與您期望不一致的數位。 下列會醒目提示一些影響效能的變數，雖然這不是完整的清單：
- 網路頻寬
- 復原選項
- 記憶體磁碟組態：NVME、SSD、HDD
- I/O 緩衝區
- Cache
- RAID 設定
- 網路躍點
- 硬碟軸速度
CSV 擁有權
節點稱為磁碟區擁有者或 協調器節點（非協調器 節點會是沒有特定磁碟區的節點）。 每個標準磁碟區都會指派一個節點，而其他節點可以透過網路躍點存取此標準磁碟區，這會導致效能變慢（延遲較高）。
同樣地，叢集共用磁碟區 （CSV） 也有「擁有者」。 不過，CSV 是「動態」，因為它會在每次重新啟動系統時躍動並變更擁有權。 因此，請務必確認 DISKSPD 是從擁有 CSV 的協調器節點執行。 如果沒有，您可能需要手動變更 CSV 擁有權。
若要確認 CSV 擁有權：
執行下列 PowerShell 命令來檢查擁有權：
Get-ClusterSharedVolume如果 CSV 擁有權不正確（例如，您在 Node1 上，但 Node2 擁有 CSV），則執行下列 PowerShell 命令，將 CSV 移至正確的節點：
Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
檔案複製與 DISKSPD
有些人認為，他們可以複製並貼上巨大的檔案，並測量該程式花費的時間，來「測試記憶體效能」。 此方法背後的主要原因是其簡單且快速。 其概念並非錯誤，因為它會測試特定的工作負載，但很難將此方法分類為「測試記憶體效能」。
如果您的真實世界目標是測試檔案複製效能，則這可能是使用此方法的完全有效原因。 不過，如果您的目標是測量記憶體效能，建議您不要使用此方法。 您可以將檔案複製程序想像成使用一組不同的「參數」（例如佇列、平行處理等等），這是檔案服務特有的。
下列簡短摘要說明為何使用檔案複製來測量記憶體效能可能不會提供您要尋找的結果：
檔案復本可能無法優化， 發生兩個層級的平行處理原則，一個內部和另一個外部。 就內部而言，如果檔案復本是針對遠端目標進行，則 CopyFileEx 引擎會套用一些平行處理。 在外部，有不同的方式來叫用 CopyFileEx 引擎。 例如，來自 檔案總管的複本是單個線程，但 Robocopy 是多線程的。 基於這些原因，請務必瞭解測試的影響是否為您要尋找的內容。
每個復本都有兩面。 當您複製並貼上檔案時，您可能會使用兩個磁碟：來源磁碟和目的地磁碟。 如果其中一個比另一個慢，您基本上會測量較慢磁碟的效能。 在其他情況下，來源、目的地和複製引擎之間的通訊可能會以獨特的方式影響效能。
若要深入瞭解，請參閱 使用檔案複製來測量記憶體效能。
實驗和常見工作負載
本節包含一些其他範例、實驗和工作負載類型。
確認協調器節點
如先前所述，如果您目前測試的 VM 沒有 CSV，您會看到效能下降（IOPS、輸送量和延遲），而不是在節點擁有 CSV 時進行測試。 這是因為每次發出 I/O 作業時，系統會對協調器節點執行網路躍點來執行該作業。
針對三個節點的三向鏡像情況，寫入作業一律會讓網路躍點成為網路躍點，因為它需要在三個節點的所有磁碟驅動器上儲存數據。 因此，無論寫入作業為何，都會讓網路躍點成為網路躍點。 不過，如果您使用不同的復原結構，這可能會變更。
以下是範例：
- 在本機節點上執行： diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C：\ClusterStorage\test01\targetfile\IO.dat
- 在非本機節點上執行： diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C：\ClusterStorage\test01\targetfile\IO.dat
在此範例中，您可以在下圖的結果中清楚看到延遲降低、IOPS 增加，以及協調器節點擁有 CSV 時增加的輸送量。
在線事務處理 （OLTP） 工作負載
在線交易處理 （OLTP） 工作負載查詢 （Update， Insert， Delete） 著重於交易導向的工作。 相較於在線分析處理 （OLAP），OLTP 相依於記憶體延遲。 因為每個作業都會發出很少的 I/O，您關心的是每秒可以維持的作業數目。
您可以設計 OLTP 工作負載測試，以專注於隨機、小型的 I/O 效能。 針對這些測試，請專注於您可以推送輸送量，同時維持可接受的延遲。
此工作負載測試的基本設計選擇至少應包括：
- 8 KB 區塊大小 => 類似於 SQL Server 用於其數據檔的頁面大小
- 70% 讀取，30% 寫入 => 類似於典型的 OLTP 行為
在線分析處理 （OLAP） 工作負載
OLAP 工作負載著重於數據擷取和分析，讓使用者執行複雜的查詢來擷取多維度數據。 與 OLTP 相反，這些工作負載不會區分記憶體延遲。 他們強調將許多作業排入佇列，而不關心頻寬。 因此，OLAP 工作負載通常會產生較長的處理時間。
您可以設計 OLAP 工作負載測試，以專注於循序、大型 I/O 效能。 針對這些測試，請將焦點放在每秒處理的數據量，而不是 IOPS 數目。 延遲需求也較不重要，但這是主觀的。
此工作負載測試的基本設計選擇至少應包括：
當 SQL Server 使用預先讀取技術載入一批 64 個數據頁進行資料表掃描時，512 KB 區塊大小 => 類似於 I/O 大小。
每個檔案 1 個線程 => 目前，您必須將測試限制為每個檔案一個線程，因為測試多個循序線程時，DISKSPD 可能會發生問題。 如果您使用一個以上的線程，例如兩個和 -s 參數，線程將會以不具決定性的方式開始，以在相同位置內彼此發出 I/O 作業。 這是因為它們各自會追蹤自己的循序位移。
有兩個「解決方案」可解決此問題：
第一個解決方案牽涉到使用 -si 參數。 使用此參數時，這兩個線程都會共用單一聯鎖位移，讓線程合作發出單一循序模式來存取目標檔案。 這可讓檔案中沒有任何一個點多次運作。 不過，由於它們仍會彼此競爭，以將其 I/O 作業發行至佇列，因此作業可能會依序抵達。
如果一個線程變成CPU有限，此解決方案會正常運作。 您可能想要在第二個 CPU 核心上參與第二個線程，以將更多的記憶體 I/O 傳遞給 CPU 系統，以進一步飽和它。
第二個解決方案牽涉到使用 -T<位移>。 這可讓您指定不同線程在相同目標檔案上執行的 I/O 作業之間的位移大小（I/O 間距）。 例如，線程通常會從位移0開始，但此規格可讓您距離兩個線程，使其不會彼此重疊。 在任何多線程環境中，線程可能會位於工作目標的不同部分，而這是模擬這種情況的一種方式。
下一步
如需優化復原設定的詳細資訊和詳細範例，請參閱：