A DISKSPD használata a számítási feladatok tárolási teljesítményének teszteléséhez

Cikk
03/09/2025

A következőkre vonatkozik: Azure Stack HCI, 22H2 és 21H2 verzió; Windows Server 2022, Windows Server 2019

Fontos

Az Azure Stack HCI mostantól az Azure Local része. Az Azure Stack HCI régebbi verziói, például a 22H2 azonban továbbra is hivatkozni fognak az Azure Stack HCI-re, és nem tükrözik a névváltoztatást. További információ.

Ez a témakör útmutatást nyújt a DISKSPD használatával a számítási feladatok tárolási teljesítményének teszteléséhez. Be van állítva egy Azure Stack HCI-fürt, minden készen áll az indulásra. Nagyszerű, de honnan tudható, hogy az ígért teljesítménymetrikákat kapja, legyen szó a késésről, az átviteli sebességről vagy az IOPS-ről? Ilyenkor érdemes használni a DISKSPD-t. A témakör elolvasása után megtudhatja, hogyan futtathatja a DISKSPD-t, megismerheti a paraméterek egy részhalmazát, értelmezheti a kimenetet, és általános ismereteket szerezhet a számítási feladatok tárolási teljesítményét befolyásoló változókról.

Mi az a DISKSPD?

A DISKSPD egy I/O-generáló parancssori eszköz a mikro-teljesítményméréshez. Nagyszerű, szóval mit jelentenek ezek a kifejezések? Bárkinek, aki beállít egy Azure Stack HCI-fürtöt vagy fizikai kiszolgálót, oka van. Lehet, hogy web hosting környezetet állít be, vagy virtuális asztalokat futtat az alkalmazottak számára. Bármi is legyen a valós használati eset, valószínűleg egy tesztet szeretne szimulálni a tényleges alkalmazás üzembe helyezése előtt. Az alkalmazás valós forgatókönyvben való tesztelése azonban gyakran nehéz – itt jön be a DISKSPD.

A DISKSPD egy olyan eszköz, amelyet testre szabhat, hogy saját szintetikus számítási feladatokat hozzon létre, és az üzembe helyezés előtt tesztelje az alkalmazást. Az eszközben az a jó, hogy lehetővé teszi a paraméterek konfigurálását és finomhangolását, hogy egy olyan forgatókönyvet hozzon létre, amely a valódi számítási feladathoz hasonlít. A DISKSPD bepillantást nyerhet abba, hogy a rendszer mire képes az üzembe helyezés előtt. A DISKSPD egyszerűen egy csomó olvasási és írási műveletet ad ki.

Most már tudja, mi a DISKSPD, de mikor érdemes használni? A DISKSPD nehezen emulál összetett számítási feladatokat. A DISKSPD azonban akkor nagyszerű, ha a munkaterhelés nem egy szálas fájlmásolattal közelíthető meg, és egy egyszerű eszköz szükséges, amely elfogadható alapvető eredményeket hoz létre.

Rövid útmutató: A DISKSPD telepítése és futtatása

A DISKSPD telepítéséhez és futtatásához nyissa meg a PowerShellt rendszergazdaként a felügyeleti pc-n, majd kövesse az alábbi lépéseket:

A DISKSPD eszköz ZIP-fájljának letöltéséhez és kibontásához futtassa a következő parancsokat:

# 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

Ha hozzá szeretné adni a DISKSPD könyvtárat a $PATH környezeti változóhoz, futtassa a következő parancsot:

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

Futtassa a DISKSPD-t a következő PowerShell-paranccsal. Cserélje le a szögletes zárójeleket a megfelelő beállításaira.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Íme egy példaparancs, amelyet futtathat:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Feljegyzés

Ha nem rendelkezik tesztfájllal, a -c paraméterrel hozzon létre egyet. Ha ezt a paramétert használja, mindenképpen adja meg a tesztfájl nevét az elérési út meghatározásakor. Például: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. A példaparancsban IO.dat a tesztfájl neve, test01.txt pedig a DISKSPD kimeneti fájl neve.

Kulcsparaméterek megadása

Nos, ez egyszerű volt, igaz? Sajnos ennél többről van szó. Csomagoljuk ki, amit tettünk. Először is vannak különböző paraméterek, amelyekkel bütyköghet, és konkrétak lehetnek. A következő alapparamétereket használtuk azonban:

Feljegyzés

A DISKSPD-paraméterek megkülönböztetik a kis- és nagybetűket.

-t2: Ez a cél-/tesztfájlonkénti szálak számát jelzi. Ez a szám gyakran a processzormagok számán alapul. Ebben az esetben két szálat használtak az összes processzormag stresszelésére.

-o32: Ez azt jelzi, hogy a függőben lévő I/O-kérések száma célonként és szálonként. Ezt az üzenetsor mélységének is nevezik, és ebben az esetben 32-et használtak a processzor terhelésére.

-b4K: Ez a blokk méretét jelzi bájtokban, KiB-ben, MiB-ben vagy GiB-ben. Ebben az esetben 4K blokkmérettel szimuláltak egy véletlenszerű I/O-tesztet.

-r4K: Ez azt jelzi, hogy a véletlenszerű I/O a megadott mérethez igazodik bájtokban, KiB-ben, MiB-ben, Gibben vagy blokkokban (felülbírálja a -s paramétert). A közös 4K bájtméretet használták a blokk méretének megfelelő igazításához.

-w0: Ez az írási kérelmeket tartalmazó műveletek százalékos arányát adja meg (a-w0 100%-os olvasási aránynak felel meg). Ebben az esetben 0%-os jelöléseket használtak egy egyszerű teszt céljából.

-d120: Ez a teszt időtartamát határozza meg, a lehűlést és a bemelegítést nem beleértve. Az alapértelmezett érték 10 másodperc, de javasoljuk, hogy legalább 60 másodpercet használjon bármilyen komoly számítási feladathoz. Ebben az esetben 120 másodpercet használtak a kiugró értékek minimalizálására.

-Suw: Letiltja a szoftveres és hardveres írási gyorsítótárazást (egyenértékű az -Sh-val).

-D: Ezredmásodpercenként (szálonként, célonként) rögzíti az IOPS-statisztikákat, például a szórást.

-L: A késési statisztikákat méri.

-c5g: A tesztben használt mintafájl méretét állítja be. Bájtokban, KiB-ben, MiB-ben, GiB-ben vagy blokkokban állítható be. Ebben az esetben egy 5 GB-os célfájlt használtunk.

A paraméterek teljes listáját a GitHub-adattárban találja.

A környezet megismerése

A teljesítmény nagyban függ a környezetétől. Szóval, mi a környezetünk? Az általunk megadott specifikáció egy Azure Stack HCI-fürtöt tartalmaz tárolókészlettel és a Storage Spaces Direct (S2D) szolgáltatással. Pontosabban öt virtuális gép létezik: DC, node1, node2, node3 és a felügyeleti csomópont. Maga a fürt egy háromcsomópontos fürt, amely háromirányú tükrözött rugalmassági struktúrával rendelkezik. Ezért a rendszer három adatmásolatot tart fenn. A klaszter minden "csomópontja" egy Standard_B2ms virtuális gép, amelynél az IOPS-korlát maximálisan 1920 lehet. Minden csomóponton belül négy prémium P30 SSD-meghajtó található, amelyek maximális IOPS-korlátja 5000. Végül minden SSD-meghajtó 1 TB memóriával rendelkezik.

A tesztfájlt az egységes névtérben (C:\ClusteredStorage), amelyet a fürt megosztott kötete (CSV) biztosít, azért hozza létre, hogy a meghajtók teljes készletét használja.

Feljegyzés

A példakörnyezet nem rendelkezik Hyper-V-rel vagy beágyazott virtualizációs struktúrával.

Mint láthatja, teljesen lehetséges, hogy önállóan elérje az IOPS-t vagy a sávszélesség felső határát a virtuális gépen vagy a meghajtó korlátján. Ezért fontos megérteni a virtuális gép méretét és meghajtótípusát, mert mindkettő maximális IOPS-korlátot és sávszélesség-felső határt biztosít. Ez a tudás segít megtalálni a szűk keresztmetszeteket, és megérteni a teljesítmény eredményeit. Ha többet szeretne megtudni arról, hogy milyen méret felelhet meg a számítási feladatnak, tekintse meg a következő erőforrásokat:

A kimenet ismertetése

Ha tisztában van a paraméterekkel és a környezettel, készen áll a kimenet értelmezésére. Először is a korábbi teszt célja az IOPS maximális kihasználása volt, a késésre való tekintet nélkül. Így vizuálisan láthatja, hogy eléri-e a mesterséges IOPS-korlátot az Azure-ban. Ha grafikusan szeretné megjeleníteni a teljes IOPS-t, használja a Windows Felügyeleti központot vagy a Feladatkezelőt.

Az alábbi ábra a DISKSPD-folyamat megjelenését mutatja be a példakörnyezetben. Egy nem koordinátor csomópont 1 MiB írási műveletére mutat példát. A háromirányú rugalmassági struktúra és a nem koordinátor csomópontból származó művelet két hálózati ugrást eredményez, csökkentve a teljesítményt. Ha kíváncsi arra, hogy mi a koordinátori csomópont, ne aggódjon! Erről a Megfontolandó dolgok szakaszban olvashat. A piros négyzetek a virtuális gép és a meghajtó szűk keresztmetszeteit jelképezik.

Most, hogy megismerte a vizualizációt, vizsgáljuk meg a .txt fájlkimenet négy fő szakaszát:

Bemeneti beállítások

Ez a szakasz a futtatott parancsot, a bemeneti paramétereket és a tesztfuttatás további részleteit ismerteti.
CPU-kihasználtság részletei

Ez a szakasz olyan információkat emel ki, mint a tesztelési idő, a szálak száma, a rendelkezésre álló processzorok száma, valamint az egyes processzormagok átlagos kihasználtsága a teszt során. Ebben az esetben két processzormag van, amelyek átlagosan körülbelül 4,67%-os használatot jelentettek.
Teljes I/O

Ez a szakasz három alszakaszból áll. Az első szakasz kiemeli az általános teljesítményadatokat, beleértve az olvasási és írási műveleteket is. A második és a harmadik szakasz külön kategóriákra osztotta az olvasási és írási műveleteket.

Ebben a példában láthatja, hogy a teljes I/O-szám 234408 volt a 120 másodperces időtartam alatt. IOPS = 234408 /120 = 1953,30. Az átlagos késés 32,763 ezredmásodperc volt, az átviteli sebesség pedig 7,63 MiB/s volt. A korábbi információkból tudjuk, hogy az 1953.30 IOPS közel van a Standard_B2ms virtuális gépünkre vonatkozó 1920 IOPS korlátozáshoz. Nem hiszed el? Ha ezt a tesztet különböző paraméterekkel, például az üzenetsor mélységének növelésével futtatja újra, akkor azt fogja tapasztalni, hogy az eredmények továbbra is ezen a számon maradnak.

Az utolsó három oszlop az IOPS szórását mutatja 17,72-nél (-D paramétertől), a késés szórását 20,994 ezredmásodpercben (-L paramétertől) és a fájl elérési útját.

Az eredmények alapján gyorsan megállapíthatja, hogy a klaszterkonfiguráció rossz. Láthatja, hogy az 5000 SSD-korlátozás előtt elérte az 1920-ra vonatkozó virtuálisgép-korlátozást. Ha nem a virtuális gép, hanem az SSD okozta a korlátozást, akár 20000 IOPS-t (4 meghajtó * 5000) is kihasználhatott volna azzal, hogy a tesztfájlt több meghajtóra átszeli.

Végül el kell döntenie, hogy az adott számítási feladat milyen értékeket fogad el. Az alábbi ábra néhány fontos kapcsolatot mutat be, amelyek segítenek megfontolni a kompromisszumokat:

Az ábrán a második kapcsolat fontos, és néha Little's Law-nak is nevezik. A törvény bemutatja, hogy három jellemző szabályozza a folyamat viselkedését, és hogy csak az egyiket kell módosítania, hogy befolyásolja a másik kettőt, és így az egész folyamatot. Tehát, ha elégedetlen a rendszer teljesítményével, akkor három szabadságfokkal rendelkezik, hogy befolyásolja azt. A Little's Law azt diktálja, hogy a példánkban az IOPS az "átviteli sebesség" (bemeneti kimeneti műveletek másodpercenként), a késés az "üzenetsor ideje", az üzenetsor mélysége pedig a "leltár".
Késés percentilis elemzése

Ez az utolsó szakasz a tárolási teljesítmény művelettípusonkénti késéseit részletezi a minimális értéktől a maximális értékig.

Ez a szakasz azért fontos, mert meghatározza az IOPS "minőségét". Megmutatja, hogy az I/O-műveletek közül hány tudott elérni egy bizonyos késési értéket. A percentilis elfogadható késésének eldöntése Önön múlik.

A "kilences" a kilences számra utal. A "3-kilences" érték például a 99. percentilisnek felel meg. A kilences szám azt jelzi, hogy hány I/O-művelet futott ezen a percentilisen. Végül el fog érni egy pontot, ahol már nincs értelme komolyan venni a késési értékeket. Ebben az esetben láthatja, hogy a késési értékek állandóak maradnak a "4-9s" után. Ezen a ponton a késési érték a 234408 műveletek közül csak egy I/O-műveleten alapul.

Megfontolandó szempontok

Most, hogy megkezdte a DISKSPD használatát, több szempontot is figyelembe kell venni a valós teszteredmények lekéréséhez. Ezek közé tartozik a beállított paraméterek figyelmes megfigyelése, a tárterület egészségi állapota és a változók figyelése, a CSV tulajdonjoga, valamint a DISKSPD és a fájlmásolás közötti különbség.

DISKSPD és valós világ

A DISKSPD mesterséges tesztje viszonylag összehasonlítható eredményeket ad a valós számítási feladathoz. Azonban nagy figyelmet kell fordítania a beállított paraméterekre, és hogy azok megfelelnek-e a valós forgatókönyvnek. Fontos tisztában lenni azzal, hogy a szintetikus számítási feladatok soha nem fogják tökéletesen képviselni az alkalmazás valós számítási feladatait az üzembe helyezés során.

Előkészítés

A DISKSPD-teszt futtatása előtt van néhány ajánlott művelet. Ezek közé tartozik a tárolóterület állapotának ellenőrzése, az erőforrás-használat ellenőrzése, hogy egy másik program ne zavarja a tesztet, és előkészítse a teljesítménykezelőt, ha további adatokat szeretne gyűjteni. Mivel azonban a témakör célja a DISKSPD gyors futtatása, nem veszi figyelembe ezeknek a műveleteknek a sajátosságait. További információ: Tárolóhelyek teljesítmény tesztelése szintetikus számítási feladatok használatával a Windows Serveren.

A teljesítményt befolyásoló változók

A tárolási teljesítmény kényes dolog. Ez azt jelenti, hogy számos változó befolyásolhatja a teljesítményt. Így valószínű, hogy olyan számmal találkozik, amely nem felel meg az elvárásainak. Az alábbiakban néhány olyan változót emelünk ki, amelyek befolyásolják a teljesítményt, bár ez nem átfogó lista:

Hálózati sávszélesség
Rugalmasság választása
Tárolólemez konfigurációja: NVME, SSD, HDD
I/O-puffer
Gyorsítótár
RAID-konfiguráció
Hálózati ugrások
Merevlemez orsósebességei

CSV tulajdonjoga

A csomópontot kötettulajdonosnak vagy koordinátorcsomópontnak nevezzük (a nem koordinátor csomópont az a csomópont, amely nem rendelkezik adott kötetekkel). Minden standard kötethez hozzá van rendelve egy csomópont, a többi csomópont pedig hálózati ugrásokkal érheti el ezt a standard kötetet, ami lassabb teljesítményt (nagyobb késést) eredményez.

Hasonlóképpen, a Cluster Shared Volume (CSV) is rendelkezik a "tulajdonossal". A CSV azonban "dinamikus" abban az értelemben, hogy minden alkalommal, amikor újraindítja a rendszert (RDP), a tulajdonosi viszony megváltozik. Ennek eredményeképpen fontos ellenőrizni, hogy a DISKSPD a CSV-t birtoklevő koordinátor csomópontról fut-e. Ha nem, előfordulhat, hogy manuálisan kell módosítania a CSV tulajdonjogát.

A CSV tulajdonjogának megerősítése:

Ellenőrizze a tulajdonjogot a következő PowerShell-parancs futtatásával:
```
 Get-ClusterSharedVolume
```
Ha a CSV tulajdonjoga helytelen (például Ön az 1. csomóponton van, de a Node2 a CSV tulajdonosa), helyezze át a CSV-t a megfelelő csomópontra a következő PowerShell-parancs futtatásával:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Fájlmásolás és DISKSPD

Egyesek úgy vélik, hogy "tesztelhetik a tárolási teljesítményt" egy gigantikus fájl másolásával és beillesztésével, valamint annak mérésével, hogy mennyi ideig tart ez a folyamat. Ennek a megközelítésnek a fő oka valószínűleg az, hogy egyszerű és gyors. Az ötlet nem téves abban az értelemben, hogy egy adott számítási feladatot tesztel, de ezt a módszert nehéz a "tárolási teljesítmény tesztelése" kategóriába sorolni.

Ha a valós cél a fájlmásolási teljesítmény tesztelése, akkor ez lehet egy tökéletesen érvényes ok a módszer használatára. Ha azonban a cél a tárolási teljesítmény mérése, javasoljuk, hogy ne használja ezt a módszert. A fájlmásolási folyamat úgy képzelhető el, mintha a fájlszolgáltatásokra jellemző különböző "paramétereket" (például üzenetsort, párhuzamosítást stb.) használnánk.

Az alábbi rövid összefoglalás azt ismerteti, hogy miért nem feltétlenül adja meg a keresett eredményt a fájlmásolás a tárolási teljesítmény mérésére:

Előfordulhat, hogy a fájlmásolatok nem optimalizálhatók, két párhuzamossági szint fordul elő, az egyik belső, a másik külső. Belsőleg, ha a fájlpéldány egy távoli cél felé tart, a CopyFileEx motor némi párhuzamosítást alkalmaz. Külsőleg a CopyFileEx motor meghívásának különböző módjai vannak. A Fájlkezelő példányai például egyszálasak, de a Robocopy többszálas. Ezen okokból fontos megérteni, hogy a teszt következményei azok-e, amelyeket keres.
Minden másolatnak két oldala van. Fájl másolása és beillesztésekor két lemezt használhat: a forráslemezt és a céllemezt. Ha az egyik lassabb, mint a másik, lényegében a lassabb lemez teljesítményét méri. Vannak más esetek is, amikor a forrás, a cél és a másolási motor közötti kommunikáció egyedi módon befolyásolhatja a teljesítményt.

További információ: A fájlmásolás használata a tárolási teljesítmény méréséhez.

Kísérletek és gyakori számítási feladatok

Ez a szakasz további példákat, kísérleteket és számítási feladattípusokat tartalmaz.

A koordinátor csomópont megerősítése

Ahogy korábban említettük, ha a jelenleg tesztelt virtuális gép nem rendelkezik a CSV-sel, teljesítménycsökkenés (IOPS, átviteli sebesség és késés) jelenik meg, szemben a teszteléssel, amikor a csomópont a CSV-t birtokolja. Ennek az az oka, hogy minden alkalommal, amikor kibocsát egy I/O-műveletet, a rendszer hálózati ugrást végez a koordinátor csomópontjához a művelet végrehajtásához.

Háromcsomópontos, háromirányú tükrözött helyzetben az írási műveletek mindig hálózati ugrást hajtanak végre, mivel a három csomópont összes meghajtóján tárolnia kell az adatokat. Ezért az írási műveletek ettől függetlenül hálózati ugrást hajtanak végre. Ha azonban más rugalmassági struktúrát használ, ez megváltozhat.

Íme egy példa:

Helyi csomóponton fut: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Nem lokális csomóponton fut: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

Ebből a példából egyértelműen látható, hogy az alábbi ábrán látható, hogy a késés csökkent, az IOPS növekedett, és az átviteli sebesség növekedett, amikor a koordinátor csomópont a CSV tulajdonosa.

Online tranzakciófeldolgozási (OLTP) számítási feladat

Az online tranzakciós feldolgozási (OLTP) számítási feladatok lekérdezései (frissítés, beszúrás, törlés) a tranzakcióorientált tevékenységekre összpontosítanak. Az online elemzési feldolgozáshoz (OLAP) képest az OLTP a tárolási késéstől függ. Mivel minden művelet kevés I/O-problémát jelent, az a fontos, hogy másodpercenként hány művelet tartható fenn.

OLTP számítási feladattesztet is tervezhet, hogy a véletlenszerű, kis I/O-teljesítményre összpontosítson. Ezeknél a teszteknél koncentráljon arra, hogy milyen messzire tudja leküldni az átviteli sebességet, miközben fenntartja az elfogadható késéseket.

A számítási feladat teszteléséhez szükséges alapszintű kialakítási választásnak legalább a következőket kell tartalmaznia:

8 KB blokkméret => az SQL Server adatfájljaihoz használt oldalmérethez hasonlít
70% Olvasás, 30% Írás => hasonlít a tipikus OLTP-viselkedésre

Online analitikai feldolgozási (OLAP) munkafolyamat

Az OLAP-számítási feladatok az adatlekérésre és -elemzésre összpontosítanak, így a felhasználók összetett lekérdezéseket hajtanak végre a többdimenziós adatok kinyeréséhez. Az OLTP-vel ellentétben ezek a számítási feladatok nem érzékenyek a tárolási késésre. Hangsúlyozzák, hogy sok művelet sorba állítása anélkül történik, hogy sokat törődnének a sávszélességgel. Ennek eredményeképpen az OLAP-számítási feladatok gyakran hosszabb feldolgozási időt eredményeznek.

OLAP számítási feladattesztet is tervezhet, hogy a szekvenciális, nagy I/O-teljesítményre összpontosítson. Ezeknél a teszteknél az IOPS száma helyett a másodpercenként feldolgozott adatok mennyiségére kell összpontosítani. A késési követelmények szintén kevésbé fontosak, de ez szubjektív.