sql >> Database teknologi >  >> RDS >> Database

Brug af Microsoft DiskSpd til at teste dit lagerundersystem

Tidligere dækkede jeg det grundlæggende i lagerundersystem-metrics og -testning i min artikel Analysing I/O Subsystem Performance for SQL Server, inklusive en introduktion af CrystalDiskMark 4.0. CrystalDiskMark blev for nylig omskrevet til at bruge Microsoft DiskSpd til dets testning, hvilket gør det til et endnu mere værdifuldt værktøj til dit indledende lagringsundersystem. DiskSpd giver den nødvendige funktionalitet til at generere en lang række diskanmodningsmønstre, hvilket kan være meget nyttigt til diagnosticering og analyse af I/O-ydelsesproblemer med meget mere fleksibilitet end ældre benchmarkværktøjer som SQLIO. Det er yderst nyttigt til test af syntetiske lagerundersystem, når du ønsker et større kontrolniveau end det, der er tilgængeligt i CrystalDiskMark.

Nu skal vi dykke lidt dybere ned i, hvordan man rent faktisk bruger Microsoft DiskSpd til at teste dit lagerundersystem uden at bruge CrystalDiskMark 4.0. For at gøre dette skal du downloade og pakke DiskSpd ud. For at gøre tingene lettere kopierer jeg altid den ønskede diskspd.exe eksekverbare fil fra den relevante eksekverbare mappe (amd64fre, armfre eller x86fre) til en kort, simpel sti som C:\DiskSpd . I de fleste tilfælde vil du have 64-bit versionen af ​​DiskSpd fra mappen amd64fre.

Når du har den eksekverbare diskspd.exe-fil tilgængelig, skal du åbne en kommandoprompt med administrative rettigheder (ved at vælge "Kør som administrator") og derefter navigere til den mappe, hvor du kopierede diskspd.exe-filen.

Her er nogle af kommandolinjeparametrene, som du vil starte med:

Parameter Beskrivelse
-b Blokstørrelse for I/O, angivet som (K/M/G). For eksempel betyder –b8K en 8KB blokstørrelse, som er relevant for SQL Server
-d Testvarighed i sekunder. Tests på 30-60 sekunder er normalt lange nok til at få gyldige resultater
-o Udestående I/O'er (betyder kødybde) pr. mål, pr. arbejdertråd
-t Medarbejdertråde pr. testfilmål
-h Deaktiver softwarecaching på operativsystemniveau og hardware skrive-caching, hvilket er en god idé til at teste SQL Server
-r Tilfældigt eller sekventielt flag. Hvis –r bruges, udføres tilfældige tests, ellers udføres sekventielle tests
-w Skriveprocent. For eksempel betyder –w25 25 % skriver, 75 % læser
-Z Workload test skrivekildebufferstørrelse, angivet som (K/M/G). Bruges til at levere tilfældige data til skrivninger, hvilket er en god idé til SQL Server-testning
-L Fang latensinformation under testen, hvilket er en meget god idé til at teste SQL Server
-c Opretter arbejdsbelastningsfil(er) af den angivne størrelse, angivet som (K/M/G)

Tabel 1:Grundlæggende kommandolinjeparametre for DiskSpd

Du vil også specificere testfilens placering og filnavnet for resultaterne i slutningen af ​​linjen. Her er et eksempel på en kommandolinje:

diskspd –b8K –d30 –o4 –t8 –h –r –w25 –L –Z1G –c20G T:\iotest.dat> DiskSpeedResults.txt

Dette eksempel på kommandolinje vil køre en 30 sekunders tilfældig I/O-test ved hjælp af en 20 GB testfil placeret på T:-drevet, med et 25 % skrive- og 75 % læseforhold, med en blokstørrelse på 8K. Den vil bruge otte arbejdstråde, hver med fire fremragende I/O'er og en skriveentropiværdi på 1 GB. Det vil gemme resultaterne af testen til en tekstfil kaldet DiskSpeedResults.txt. Dette er et ret godt sæt parametre for en SQL Server OLTP-arbejdsbelastning.

Figur 1:Eksempel på kommandolinje til DiskSpd

Kørsel af testen starter med en standard fem sekunders opvarmningstid (før nogen målinger faktisk starter), og derefter vil den faktiske test køre i den angivne varighed i sekunder med en standard nedkølingstid på nul sekunder. Når testen er færdig, giver DiskSpd en beskrivelse af testen og de detaljerede resultater. Som standard vil dette være et simpelt tekstresumé i en tekstfil, der bruger det filnavn, du har angivet, som vil være i samme mappe som diskspd-eksekverbare.

Her er, hvordan resultaterne ser ud for netop denne testkørsel på min arbejdsstation.

Figur 2:Eksempler på DiskSpd-testresultater

Den første sektion af resultaterne giver dig den nøjagtige kommandolinje, der blev brugt til testen, og specificerer derefter alle de inputparametre, der blev brugt til testkørslen (som inkluderer standardværdierne, der muligvis ikke er angivet i den faktiske kommandolinje ). Derefter vises testresultaterne begyndende med den faktiske testtid, trådantal og logisk processorantal. CPU-sektionen viser CPU-udnyttelsen for hver logisk processor, inklusive bruger- og kernetid, for testintervallet.

Den mere interessante del af testresultaterne kommer derefter. Du får de samlede bytes, samlede I/O'er, MB/sekund, I/O per sekund (IOPS) og din gennemsnitlige latenstid i millisekunder. Disse resultater er opdelt for hver tråd (fire i vores tilfælde), med separate sektioner i resultaterne for Total IO, Læs IO og Skriv IO. Resultaterne for hver tråd bør være meget ens i de fleste tilfælde. I stedet for først at fokusere på de absolutte værdier for hver måling, kan jeg godt lide at sammenligne værdierne, når jeg kører den samme test på forskellige logiske drev (efter at have ændret placeringen af ​​testfilen på kommandolinjen), som lader dig sammenligne ydeevnen for hvert logisk drev.

Den sidste del af testresultaterne er endnu mere interessant. Den viser en percentilanalyse af fordelingen af ​​latenstestresultaterne startende fra minimumsværdien i millisekunder op til maksimumværdien i millisekunder, opdelt for læsninger, skrivninger og total latenstid. "Nierne" i %-ile kolonnen refererer til antallet af ni, hvor 3-ni betyder 99,9, 4-ni betyder 99,99 osv. Grunden til at værdierne for de højere percentilrækker er de samme, er fordi denne test havde et relativt lavt antal samlede operationer. Hvis du ønsker at karakterisere de højere percentiler nøjagtigt, bliver du nødt til at køre en længere varighedstest, der genererer et højere antal separate I/O-operationer.

Det, du vil kigge efter i disse resultater, er det punkt, hvor værdierne foretager et stort spring. For eksempel kan vi i denne test se, at 99 % af læsningerne havde en latenstid på 1,832 millisekunder eller mindre.

Figur 3:Fordeling af latensresultater

Som du kan se, er det faktisk ret simpelt at køre DiskSpd, når du først forstår, hvad de grundlæggende parametre betyder, og hvordan de bruges. Ikke alene kan du køre DiskSpd fra en gammeldags kommandolinje, du kan også køre den ved hjælp af PowerShell. DiskSpd giver dig også meget mere detaljeret information, end du får fra SQLIO. Den mere komplicerede del af at bruge DiskSpd er at analysere og fortolke resultaterne, hvilket er noget, jeg vil dække i en fremtidig artikel.


  1. Retter ORA-65096-fejl ved oprettelse af automatiserede test i Django ved hjælp af Oracle

  2. Opdater med Join-forespørgsel i Oracle

  3. Brug af jsonb_set() til at opdatere specifik jsonb-arrayværdi

  4. Fjern polstring, når du sender forespørgselsresultater i en e-mail fra SQL Server (T-SQL)