Tidigare täckte jag grunderna för lagringsundersystemsmetrik och testning i min artikel Analysera I/O-subsystemprestanda för SQL Server, inklusive en introduktion av CrystalDiskMark 4.0. CrystalDiskMark skrevs nyligen om för att använda Microsoft DiskSpd för sina tester, vilket gör det till ett ännu mer värdefullt verktyg för dina initiala tester av lagringsundersystem. DiskSpd tillhandahåller den funktionalitet som behövs för att generera en mängd olika diskbegäranmönster, vilket kan vara till stor hjälp vid diagnos och analys av I/O-prestandaproblem med mycket mer flexibilitet än äldre benchmarkverktyg som SQLIO. Det är extremt användbart för testning av syntetiska lagringsundersystem när du vill ha en högre kontrollnivå än den som är tillgänglig i CrystalDiskMark.
Nu ska vi dyka lite djupare in i hur du faktiskt använder Microsoft DiskSpd för att testa ditt lagringsundersystem utan att använda CrystalDiskMark 4.0. För att göra detta måste du ladda ner och packa upp DiskSpd. För att göra saker enklare kopierar jag alltid den önskade körbara diskspd.exe-filen från lämplig körbar mapp (amd64fre, armfre eller x86fre) till en kort, enkel sökväg som C:\DiskSpd . I de flesta fall vill du ha 64-bitarsversionen av DiskSpd från mappen amd64fre.
När du har den körbara filen diskspd.exe tillgänglig måste du öppna en kommandotolk med administrativa rättigheter (genom att välja "Kör som administratör") och sedan navigera till katalogen där du kopierade filen diskspd.exe.
Här är några av kommandoradsparametrarna som du vill börja med:
| Parameter | Beskrivning |
| -b | Blockstorlek för I/O, specificerad som (K/M/G). Till exempel –b8K betyder en 8KB blockstorlek, vilket är relevant för SQL Server |
| -d | Testlängd i sekunder. Tester på 30-60 sekunder är vanligtvis tillräckligt långa för att få giltiga resultat |
| -o | Utestående I/O (vilket betyder ködjup) per mål, per arbetartråd |
| -t | Arbetartrådar per testfilmål |
| -h | Inaktivera programvarucache på operativsystemnivå och hårdvaruskrivcache, vilket är en bra idé för att testa SQL Server |
| -r | Slumpmässig eller sekventiell flagga. Om –r används görs slumpmässiga tester, annars görs sekventiella tester |
| -w | Skrivprocent. Till exempel betyder –w25 25 % skriver, 75 % läser |
| -Z | Arbetsbelastningstestskrivkällbuffertstorlek, specificerad som (K/M/G). Används för att tillhandahålla slumpmässiga data för skrivningar, vilket är en bra idé för SQL Server-testning |
| -L | Fånga latensinformation under testet, vilket är en mycket bra idé för att testa SQL Server |
| -c | Skapar arbetsbelastningsfil(er) av angiven storlek, specificerad som (K/M/G) |
Tabell 1:Grundläggande kommandoradsparametrar för DiskSpd
Du kommer också att vilja ange testfilens plats och filnamnet för resultaten i slutet av raden. Här är ett exempel på kommandoraden:
diskspd –b8K –d30 –o4 –t8 –h –r –w25 –L –Z1G –c20G T:\iotest.dat> DiskSpeedResults.txtDen här kommandoraden kommer att köra ett slumpmässigt I/O-test på 30 sekunder med en testfil på 20 GB som finns på T:-enheten, med 25 % skriv- och 75 % läsförhållande, med en blockstorlek på 8K. Den kommer att använda åtta arbetstrådar, var och en med fyra enastående I/O och ett skriventropivärde på 1 GB. Det kommer att spara resultaten av testet i en textfil som heter DiskSpeedResults.txt. Det här är en ganska bra uppsättning parametrar för en SQL Server OLTP-arbetsbelastning.
Figur 1:Exempel på kommandorad för DiskSpd
Att köra testet börjar med en förinställd uppvärmningstid på fem sekunder (innan några mätningar faktiskt börjar), och sedan körs det faktiska testet under den angivna varaktigheten i sekunder med en förinställd nedkylningstid på noll sekunder. När testet är klart kommer DiskSpd att ge en beskrivning av testet och de detaljerade resultaten. Som standard kommer detta att vara en enkel textsammanfattning i en textfil med filnamnet som du angav, som kommer att finnas i samma katalog som diskspd-filen.
Så här ser resultaten ut för just den här testkörningen på min arbetsstation.
Figur 2:Exempel på DiskSpd-testresultat
Den första delen av resultaten ger dig den exakta kommandoraden som användes för testet, och anger sedan alla indataparametrar som användes för testkörningen (som inkluderar standardvärdena som kanske inte har angetts på den faktiska kommandoraden ). Därefter visas testresultaten med början på den faktiska testtiden, antalet trådar och antalet logiska processorer. CPU-avsnittet visar CPU-användningen för varje logisk processor, inklusive användar- och kärntid, för testintervallet.
Den mer intressanta delen av testresultaten kommer härnäst. Du får totala bytes, totala I/O, MB/sekund, I/O per sekund (IOPS) och din genomsnittliga latens i millisekunder. Dessa resultat är uppdelade för varje tråd (fyra i vårt fall), med separata avsnitt i resultaten för Total IO, Läs IO och Skriv IO. Resultaten för varje tråd bör vara mycket lika i de flesta fall. Istället för att initialt fokusera på de absoluta värdena för varje mätning, gillar jag att jämföra värdena när jag kör samma test på olika logiska enheter (efter att ha ändrat platsen för testfilen på kommandoraden), vilket låter dig jämföra prestanda för varje logisk enhet.
Den sista delen av testresultaten är ännu mer intressant. Den visar en percentilanalys av fördelningen av latenstestresultaten från det lägsta värdet i millisekunder som går upp till det maximala värdet i millisekunder, uppdelat för läsningar, skrivningar och total latens. "Nioorna" i %-ile kolumnen hänvisar till antalet nior, där 3-nies betyder 99,9, 4-nies betyder 99,99, etc. Anledningen till att värdena för de högre percentilraderna är desamma beror på att detta test hade ett relativt lågt antal totala operationer. Om du vill karakterisera de högre percentilerna exakt måste du köra ett längre varaktighetstest som genererar ett högre antal separata I/O-operationer.
Det du vill titta efter i dessa resultat är punkten där värdena gör ett stort hopp. I det här testet kan vi till exempel se att 99 % av avläsningarna hade en latens på 1,832 millisekunder eller mindre.
Figur 3:Fördelning av latensresultat
Som du kan se är det faktiskt ganska enkelt att köra DiskSpd när du väl förstår vad de grundläggande parametrarna betyder och hur de används. Du kan inte bara köra DiskSpd från en gammaldags kommandorad, du kan också köra den med PowerShell. DiskSpd ger dig också mycket mer detaljerad information än du får från SQLIO. Den mer komplicerade delen av att använda DiskSpd är att analysera och tolka resultaten, vilket jag kommer att ta upp i en framtida artikel.