Använda DISKSPD för att testa lagringsprestanda för arbetsbelastningar

Artikel
11/23/2024

Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server 2019

Viktigt!

Azure Stack HCI är nu en del av Azure Local. Namnbytet av produktdokumentation pågår. Äldre versioner av Azure Stack HCI, till exempel 22H2, fortsätter dock att referera till Azure Stack HCI och återspeglar inte namnändringen. Läs mer.

Det här avsnittet innehåller vägledning om hur du använder DISKSPD för att testa lagringsprestanda för arbetsbelastningar. Du har ett Azure Stack HCI-kluster som är konfigurerat och klart att användas. Bra, men hur vet du om du får de utlovade prestandamåtten, oavsett om det gäller svarstid, dataflöde eller IOPS? Här kan DISKSPD vara till hjälp. När du har läst det här avsnittet vet du hur du kör DISKSPD, förstår en delmängd parametrar, tolkar utdata och får en allmän förståelse för de variabler som påverkar lagringsprestanda för arbetsbelastningar.

Vad är DISKSPD?

DISKSPD är ett I/O-genererande kommandoradsverktyg för mikromätning. Bra, så vad betyder alla dessa termer? Alla som konfigurerar ett Azure Stack HCI-kluster eller en fysisk server har en anledning. Det kan vara att konfigurera en webbvärdmiljö eller köra virtuella skrivbord för anställda. Oavsett det verkliga användningsfallet vill du förmodligen simulera ett test innan du distribuerar ditt faktiska program. Det är dock ofta svårt att testa ditt program i ett verkligt scenario – det är här DISKSPD kommer in.

DISKSPD är ett verktyg som du kan anpassa för att skapa egna syntetiska arbetsbelastningar och testa programmet före distributionen. Det coola med verktyget är att det ger dig friheten att konfigurera och justera parametrarna för att skapa ett specifikt scenario som liknar din verkliga arbetsbelastning. DISKSPD kan ge dig en inblick i vad systemet kan hantera före distributionen. I grunden utfärdar DISKSPD helt enkelt en massa läs- och skrivåtgärder.

Nu vet du vad DISKSPD är, men när ska du använda det? DISKSPD har svårt att efterlikna komplexa arbetsbelastningar. Men DISKSPD är bra när din arbetsbelastning inte är nära approximerad av en enkeltrådad filkopia, och du behöver ett enkelt verktyg som ger godtagbara baslinjeresultat.

Snabbstart: installera och köra DISKSPD

Om du vill installera och köra DISKSPD öppnar du PowerShell som administratör på hanteringsdatorn och följer sedan dessa steg:

Om du vill ladda ned och expandera ZIP-filen för DISKSPD-verktyget kör du följande kommandon:

# 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

Om du vill lägga till DISKSPD-katalogen i $PATH miljövariabeln kör du följande kommando:

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

Kör DISKSPD med följande PowerShell-kommando. Ersätt hakparenteser med lämpliga inställningar.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Här är ett exempelkommando som du kan köra:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Kommentar

Om du inte har någon testfil använder du parametern -c för att skapa en. Om du använder den här parametern måste du inkludera testfilens namn när du definierar sökvägen. Exempel: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. I exempelkommandot är IO.dat namnet på testfilen och test01.txt är filnamnet för DISKSPD-utdata.

Ange nyckelparametrar

Det var enkelt, eller hur? Tyvärr är det mer än så. Vi packar upp det vi gjorde. För det första finns det olika parametrar som du kan mixtra med och det kan bli specifikt. Vi använde dock följande uppsättning baslinjeparametrar:

Kommentar

DISKSPD-parametrar är skiftlägeskänsliga.

-t2: Detta anger antalet trådar per mål-/testfil. Det här antalet baseras ofta på antalet CPU-kärnor. I det här fallet användes två trådar för att betona alla CPU-kärnor.

-o32: Detta anger antalet utestående I/O-begäranden per mål per tråd. Detta kallas även för ködjupet, och i det här fallet användes 32 för att stressa processorn.

-b4K: Detta anger blockstorleken i byte, KiB, MiB eller GiB. I det här fallet användes 4K-blockstorlek för att simulera ett slumpmässigt I/O-test.

-r4K: Detta anger den slumpmässiga I/O som är justerad till den angivna storleken i byte, KiB, MiB, Gib eller block (åsidosätter parametern -s ). Den vanliga 4K-bytestorleken användes för att korrekt justera med blockstorleken.

-w0: Detta anger procentandelen åtgärder som är skrivbegäranden (-w0 motsvarar 100 % läsning). I det här fallet användes 0 % skrivningar för ett enkelt test.

-d120: Detta anger testets varaktighet, inte inklusive nedkylning eller uppvärmning. Standardvärdet är 10 sekunder, men vi rekommenderar att du använder minst 60 sekunder för allvarliga arbetsbelastningar. I det här fallet användes 120 sekunder för att minimera avvikande värden.

-Suw: Inaktiverar cachelagring av programvara och maskinvara (motsvarande -Sh).

-D: Samlar in IOPS-statistik, till exempel standardavvikelse, i millisekunders intervall (per tråd, per mål).

-L: Mäter svarstidsstatistik.

-c5g: Anger den exempelfilstorlek som används i testet. Den kan anges i byte, KiB, MiB, GiB eller block. I det här fallet användes en målfil på 5 GB.

En fullständig lista över parametrar finns på GitHub-lagringsplatsen.

Förstå miljön

Prestandan är starkt beroende av din miljö. Så, vad är vår miljö? Vår specifikation omfattar ett Azure Stack HCI-kluster med lagringspool och Lagringsutrymmen Direct (S2D). Mer specifikt finns det fem virtuella datorer: DC, node1, node2, node3 och hanteringsnoden. Själva klustret är ett kluster med tre noder med en trevägs speglad återhämtningsstruktur. Därför bevaras tre datakopior. Varje "nod" i klustret är en Standard_B2ms virtuell dator med en maximal IOPS-gräns på 1920. Inom varje nod finns det fyra Premium P30 SSD-enheter med en maximal IOPS-gräns på 5 000. Slutligen har varje SSD-enhet 1 TB minne.

Du genererar testfilen under det enhetliga namnområdet som den klusterdelade volymen (CSV) tillhandahåller (C:\ClusteredStorage) för att använda hela poolen med enheter.

Kommentar

Exempelmiljön har inte Hyper-V eller en kapslad virtualiseringsstruktur.

Som du ser är det fullt möjligt att självständigt nå IOPS- eller bandbreddstaket på den virtuella datorn eller enhetsgränsen. Därför är det viktigt att förstå storleken på din virtuella dator och enhetstyp, eftersom båda har en maximal IOPS-gräns och ett bandbreddstak. Den här kunskapen hjälper dig att hitta flaskhalsar och förstå dina prestandaresultat. Mer information om vilken storlek som kan vara lämplig för din arbetsbelastning finns i följande resurser:

Förstå utdata

Beväpnad med din förståelse av parametrarna och miljön är du redo att tolka utdata. För det första var målet med det tidigare testet att maxa IOPS utan hänsyn till svarstid. På så sätt kan du visuellt se om du når den artificiella IOPS-gränsen i Azure. Om du vill visualisera det totala antalet IOPS grafiskt använder du antingen Windows Admin Center eller Aktivitetshanteraren.

Följande diagram visar hur DISKSPD-processen ser ut i vår exempelmiljö. Den visar ett exempel på en 1 MiB-skrivåtgärd från en nod som inte är koordinator. Trevägsåterhämtningsstrukturen, tillsammans med åtgärden från en nod som inte är koordinator, leder till två nätverkshopp, vilket minskar prestandan. Oroa dig inte om du undrar vad en koordinatornod är! Du får lära dig mer om det i avsnittet Saker att tänka på . De röda fyrkanterna representerar den virtuella datorn och driver flaskhalsar.

Nu när du har en visuell förståelse ska vi undersöka de fyra huvudavsnitten i .txt filutdata:

Indatainställningar

I det här avsnittet beskrivs kommandot du körde, indataparametrarna och ytterligare information om testkörningen.
Information om CPU-användning

Det här avsnittet visar information som testtid, antal trådar, antal tillgängliga processorer och den genomsnittliga användningen av varje CPU-kärna under testet. I det här fallet finns det två CPU-kärnor som i genomsnitt var cirka 4,67 % användning.
Totalt I/O

Det här avsnittet innehåller tre underavsnitt. Det första avsnittet visar övergripande prestandadata, inklusive både läs- och skrivåtgärder. Det andra och tredje avsnittet delar upp läs- och skrivåtgärderna i separata kategorier.

I det här exemplet kan du se att det totala I/O-antalet 234408 under varaktigheten på 120 sekunder. Således IOPS = 234408 /120 = 1953.30. Den genomsnittliga svarstiden var 32,763 millisekunder och dataflödet var 7,63 MiB/s. Från tidigare information vet vi att IOPS 1953.30 ligger nära IOPS-begränsningen 1920 för vår Standard_B2ms virtuella dator. Tror du inte på det? Om du kör det här testet igen med hjälp av olika parametrar, till exempel att öka ködjupet, ser du att resultatet fortfarande är begränsat till det här talet.

De tre sista kolumnerna visar standardavvikelsen för IOPS på 17,72 (från -D-parametern), standardavvikelsen för svarstiden vid 20,994 millisekunder (från -L-parametern) och filsökvägen.

Från resultaten kan du snabbt fastställa att klusterkonfigurationen är hemsk. Du kan se att den nådde vm-begränsningen 1920 innan SSD-begränsningen på 5 000. Om du begränsades av SSD i stället för den virtuella datorn kunde du ha utnyttjat upp till 2 000 IOPS (4 enheter * 5 000) genom att sträcka sig över testfilen över flera enheter.

I slutändan måste du bestämma vilka värden som är acceptabla för din specifika arbetsbelastning. Följande bild visar några viktiga relationer som hjälper dig att överväga kompromisserna:

Det andra förhållandet i figuren är viktigt, och det kallas ibland Little's Law. Lagen introducerar idén att det finns tre egenskaper som styr processbeteendet och att du bara behöver ändra en för att påverka de andra två, och därmed hela processen. Så om du är missnöjd med systemets prestanda har du tre dimensioner av frihet att påverka det. Littles lag avgör att IOPS i vårt exempel är "dataflödet" (indatautdataåtgärder per sekund), svarstiden är "kötiden" och ködjupet är "inventeringen".
Percentilanalys för svarstid

I det sista avsnittet beskrivs svarstiderna för percentilen per åtgärdstyp för lagringsprestanda från det lägsta värdet till det maximala värdet.

Det här avsnittet är viktigt eftersom det avgör "kvaliteten" på din IOPS. Den visar hur många av I/O-åtgärderna som kunde uppnå ett visst svarstidsvärde. Det är upp till dig att bestämma den acceptabla svarstiden för den percentilen.

Dessutom refererar "niorna" till antalet nior. Till exempel motsvarar "3-nior" den 99:e percentilen. Antalet nior visar hur många I/O-åtgärder som kördes vid den percentilen. Så småningom kommer du till en punkt där det inte längre är meningsfullt att ta svarstidsvärdena på allvar. I det här fallet kan du se att svarstidsvärdena förblir konstanta efter "4-nior". I det här läget baseras svarstidsvärdet endast på en I/O-åtgärd av 234408 åtgärder.

Saker att tänka på

Nu när du har börjat använda DISKSPD finns det flera saker att tänka på för att få verkliga testresultat. Dessa inkluderar att vara uppmärksam på de parametrar du anger, hälsotillstånd för lagringsutrymme och variabler, CSV-ägarskap och skillnaden mellan DISKSPD och filkopiering.

DISKSPD jämfört med verkliga

DISKSPD:s artificiella test ger dig relativt jämförbara resultat för din verkliga arbetsbelastning. Du måste dock vara uppmärksam på de parametrar du anger och om de matchar ditt verkliga scenario. Det är viktigt att förstå att syntetiska arbetsbelastningar aldrig perfekt representerar programmets verkliga arbetsbelastning under distributionen.

Förberedelse

Innan du kör ett DISKSPD-test finns det några rekommenderade åtgärder. Dessa inkluderar att verifiera hälsotillståndet för lagringsutrymmet, kontrollera resursanvändningen så att ett annat program inte stör testet och förbereda prestandahanteraren om du vill samla in ytterligare data. Men eftersom målet med det här avsnittet är att snabbt få DISKSPD att köras, går det inte att gå in på detaljerna i dessa åtgärder. Mer information finns i Testa Lagringsutrymmen prestanda med syntetiska arbetsbelastningar i Windows Server.

Variabler som påverkar prestanda

Lagringsprestanda är en känslig sak. Det innebär att det finns många variabler som kan påverka prestanda. Så det är troligt att du kan stöta på ett tal som är inkonsekvent med dina förväntningar. Följande visar några av de variabler som påverkar prestanda, även om det inte är en omfattande lista:

Nätverksbandbredd
Återhämtningsalternativ
Konfiguration av lagringsdisk: NVME, SSD, HDD
I/O-buffert
Cache
RAID-konfiguration
Nätverkshopp
Hårddiskspindelhastigheter

CSV-ägarskap

En nod kallas volymägare eller koordinatornod (en nod som inte är koordinator är den nod som inte äger en viss volym). Varje standardvolym tilldelas en nod och de andra noderna kan komma åt den här standardvolymen via nätverkshopp, vilket resulterar i långsammare prestanda (högre svarstid).

På samma sätt har en klusterdelad volym (CSV) också en "ägare". En CSV är dock "dynamisk" i den meningen att den hoppar runt och ändrar ägarskapet varje gång du startar om systemet (RDP). Därför är det viktigt att bekräfta att DISKSPD körs från den koordinatornod som äger CSV:en. Annars kan du behöva ändra CSV-ägarskapet manuellt.

Så här bekräftar du CSV-ägarskapet:

Kontrollera ägarskapet genom att köra följande PowerShell-kommando:
```
 Get-ClusterSharedVolume
```
Om CSV-ägarskapet är felaktigt (till exempel om du är på Node1 men Node2 äger CSV:en) flyttar du CSV:en till rätt nod genom att köra följande PowerShell-kommando:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Filkopiering jämfört med DISKSPD

Vissa tror att de kan "testa lagringsprestanda" genom att kopiera och klistra in en gigantisk fil och mäta hur lång tid processen tar. Den främsta orsaken till den här metoden är troligen att den är enkel och snabb. Idén är inte fel i den meningen att den testar en viss arbetsbelastning, men det är svårt att kategorisera den här metoden som "testa lagringsprestanda".

Om ditt verkliga mål är att testa filkopieringsprestanda kan det vara en helt giltig anledning att använda den här metoden. Men om målet är att mäta lagringsprestanda rekommenderar vi att du inte använder den här metoden. Du kan se filkopieringsprocessen som att använda en annan uppsättning "parametrar" (till exempel kö, parallellisering och så vidare) som är specifik för filtjänster.

Följande korta sammanfattning förklarar varför det kanske inte ger de resultat du letar efter när du använder filkopiering för att mäta lagringsprestanda:

Filkopior kanske inte är optimerade, det finns två nivåer av parallellitet som inträffar, en intern och en extern. Internt, om filkopian är på väg mot ett fjärrmål, tillämpar CopyFileEx-motorn viss parallellisering. Externt finns det olika sätt att anropa CopyFileEx-motorn. Till exempel är kopior från Utforskaren entrådade, men Robocopy är flera trådar. Av dessa skäl är det viktigt att förstå om konsekvenserna av testet är vad du letar efter.
Varje kopia har två sidor. När du kopierar och klistrar in en fil kanske du använder två diskar: källdisken och måldisken. Om den ena är långsammare än den andra mäter du i princip prestanda för den långsammare disken. Det finns andra fall där kommunikationen mellan källan, målet och kopieringsmotorn kan påverka prestandan på unika sätt.

Mer information finns i Använda filkopiering för att mäta lagringsprestanda.

Experiment och vanliga arbetsbelastningar

Det här avsnittet innehåller några andra exempel, experiment och arbetsbelastningstyper.

Bekräfta koordinatornoden

Om den virtuella dator som du testar för närvarande inte äger CSV:n ser du som tidigare en prestandaminskning (IOPS, dataflöde och svarstid) i stället för att testa den när noden äger CSV:n. Detta beror på att varje gång du utfärdar en I/O-åtgärd gör systemet ett nätverkshopp till koordinatornoden för att utföra den åtgärden.

För en trenods, trevägsspegling gör skrivåtgärder alltid ett nätverkshopp eftersom de måste lagra data på alla enheter över de tre noderna. Skrivåtgärder gör därför ett nätverkshopp oavsett. Men om du använder en annan återhämtningsstruktur kan detta ändras.

Här är ett exempel:

Körs på lokal nod: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Körs på nod som inte finns: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

I det här exemplet kan du tydligt se i resultatet av följande bild att svarstiden minskade, IOPS ökade och dataflödet ökade när koordinatornoden äger CSV:en.

Arbetsbelastning för onlinetransaktionsbearbetning (OLTP)

OLTP-arbetsbelastningsfrågor (Online Transactional Processing) (Uppdatering, Infoga, Ta bort) fokuserar på transaktionsorienterade uppgifter. Jämfört med Online Analytical Processing (OLAP) är OLTP beroende av lagringsfördröjning. Eftersom varje åtgärd har lite I/O är det du bryr dig om hur många åtgärder per sekund du kan upprätthålla.

Du kan utforma ett OLTP-arbetsbelastningstest för att fokusera på slumpmässiga, små I/O-prestanda. För dessa tester fokuserar du på hur långt du kan skicka dataflödet samtidigt som du behåller acceptabla svarstider.

Det grundläggande designvalet för det här arbetsbelastningstestet bör minst omfatta:

8 KB blockstorlek => liknar sidstorleken som SQL Server använder för sina datafiler
70 % läsning, 30 % skrivning => liknar typiskt OLTP-beteende

OLAP-arbetsbelastning (Online Analytical Processing)

OLAP-arbetsbelastningar fokuserar på datahämtning och analys, vilket gör det möjligt för användare att utföra komplexa frågor för att extrahera flerdimensionella data. I motsats till OLTP är dessa arbetsbelastningar inte lagringsfördröjningskänsliga. De betonar att köa många åtgärder utan att bry sig så mycket om bandbredd. Därför resulterar OLAP-arbetsbelastningar ofta i längre bearbetningstider.

Du kan utforma ett OLAP-arbetsbelastningstest för att fokusera på sekventiella, stora I/O-prestanda. För dessa tester fokuserar du på mängden data som bearbetas per sekund i stället för antalet IOPS. Svarstidskrav är också mindre viktiga, men detta är subjektivt.