共用方式為

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

  • 發行項

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

重要

Azure Stack HCI 現在是 Azure Local 的一部分。 不過，舊版的 Azure Stack HCI，例如 22H2 會繼續參考 Azure Stack HCI，而且不會反映名稱變更。 深入了解。

本主題提供如何使用 DISKSPD 來測試工作負載記憶體效能的指引。 您已設定好 Azure Stack HCI 叢集，一切已準備就緒。 很好，但您如何知道您在延遲、輸送量或 IOPS 上是否達到承諾的效能指標？ 這正是您應該考慮使用 DISKSPD 的時候。 閱讀本主題之後，您將瞭解如何執行 DISKSPD、了解參數子集、解譯輸出，以及大致了解影響工作負載記憶體效能的變數。

什麼是 DISKSPD？

DISKSPD 是用於微基準檢驗的 I/O 產生命令行工具。 太好了，那麼所有這些詞彙意味著什麼？ 任何設定 Azure Stack HCI 叢集或實體伺服器的人都有理由。 可能是設定 Web 主控環境，或為員工執行虛擬桌面。 無論實際使用案例為何，您可能想要在部署實際應用程式之前模擬測試。 不過，在實際情況下測試您的應用程式通常很困難，而這正是 DISKSPD 發揮作用的地方。

DISKSPD 是一種工具，您可以自定義以建立自己的綜合工作負載，並在部署之前測試您的應用程式。 此工具的酷之處在於，它可讓您自由設定和調整參數，以建立類似您實際工作負載的特定案例。 DISKSPD 可讓您瞥見系統在部署之前能夠的功能。 根本上，DISKSPD 只會執行許多讀取和寫入作業。

現在您知道什麼是 DISKSPD，但何時應該使用它？ DISKSPD 很難模擬複雜的工作負載。 當工作負載並非接近於單線程檔案拷貝，而且您需要一個簡單的工具來產生可接受的基準結果時，DISKSPD 非常出色。

快速入門：安裝和執行 DISKSPD

若要安裝和執行 DISKSPD，請以管理電腦上的系統管理員身分開啟 PowerShell，然後遵循下列步驟：

  1. 若要下載並展開 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

  2. 若要將 DISKSPD 目錄新增至 $PATH 環境變數，請執行下列命令：

    $diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

  3. 使用下列 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 和磁碟驅動器瓶頸。

用來使用 DISKSPD 測試效能的範例環境。

現在您已了解視覺效果，讓我們檢查.txt檔案輸出的四個主要區段：

  1. 輸入設定

    本節說明您執行的命令、輸入參數，以及有關測試回合的其他詳細數據。

    範例輸出會顯示命令和輸入參數。

  2. CPU 使用率詳細數據

    本節會醒目提示測試時間、線程數目、可用處理器數目，以及測試期間每個 CPU 核心的平均使用率等資訊。 在此情況下，有兩個 CPU 核心平均使用量約為 4.67%。

    CPU 詳細數據範例。

  3. 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 參數），以及檔案路徑。

    範例顯示整體 I/O 效能數據總計。

    從結果中，您可以快速判斷叢集設定很糟糕。 您可以看到它在 SSD 限制 5000 之前達到 VM 限制 1920。 如果您受限於 SSD 而非 VM，您可以透過將測試檔案分布在多個磁碟上，最多可獲得 20000 個 IOPS（4 個磁碟 * 每個 5000 IOPS）。

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

    圖顯示工作負載關聯性取捨。

    圖中的第二種關係很重要，有時被稱為小法則。 法律介紹一個概念，即有三個特性可控管進程行為，而您只需要變更一個來影響另一個，進而影響整個程式。 因此，如果您對系統的效能不滿意，您有三個自由維度來影響它。 Little's Law 規定，在我們的範例中，IOPS 是「輸送量」（每秒的輸入輸出作業）、延遲是「佇列時間」，而佇列深度則是「清查」。

  4. 延遲百分位數分析

    最後一節詳述記憶體效能每個作業類型的百分位數延遲，從最小值到最大值。

    本節很重要，因為它會決定 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 擁有權：

  1. 執行下列 PowerShell 命令來檢查擁有權：

     Get-ClusterSharedVolume

  2. 如果 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開始，但此規格可讓您距離兩個線程，使其不會彼此重疊。 在任何多線程環境中，線程可能會位於工作目標的不同部分，而這是模擬這種情況的一種方式。

下一步

如需優化復原設定的詳細資訊和詳細範例，請參閱：