En af de mest almindelige flaskehalse i ydeevnen, som jeg ser som konsulent, er utilstrækkelig ydeevne for lagerundersystemet. Der er en række årsager til dårlig lagringsydelse, men at måle den og forstå, hvad der skal måles og overvåges, er altid en nyttig øvelse.
Der er faktisk tre hovedmålinger, der er vigtigst, når det kommer til måling af I/O-undersystemets ydeevne:
Latens
Den første metrik er latency, som simpelthen er den tid, det tager en I/O at fuldføre. Dette kaldes ofte responstid eller servicetid. Målingen starter, når operativsystemet sender en anmodning til drevet (eller diskcontrolleren) og slutter, når drevet er færdig med at behandle anmodningen. Læsninger er færdige, når operativsystemet modtager dataene, mens skrivninger er færdige, når drevet informerer operativsystemet om, at det har modtaget dataene.
Til skrivning kan dataene stadig være i en DRAM-cache på drevet eller diskcontrolleren, afhængigt af din cachepolitik og hardware. Caching til tilbageskrivning er meget hurtigere end gennemskrivningscaching, men det kræver en batteribackup til diskcontrolleren. Til SQL Server-brug vil du sikre dig, at du bruger tilbageskrivningscache frem for gennemskrivningscache, hvis det overhovedet er muligt. Du vil også gerne sikre dig, at din hardwarediskcache faktisk er aktiveret, da nogle diskhåndteringsværktøjer fra leverandører deaktiverer den som standard.
Input/Output Operations per Second (IOPS)
Den anden metrik er Input/Output Operations per Second (IOPS). Denne metric er direkte relateret til latens. For eksempel betyder en konstant latens på 1ms, at et drev kan behandle 1.000 IO'er i sekundet med en kødybde på 1. Efterhånden som flere IO'er tilføjes til køen, vil latenstiden stige. En af de vigtigste fordele ved flash-lagring er, at den kan læse/skrive til flere NAND-kanaler parallelt, sammen med det faktum, at der ikke er nogen elektromekaniske bevægelige dele til at bremse diskadgangen. IOPS er faktisk lig med kødybde divideret med latensen, og IOPS i sig selv tager ikke hensyn til overførselsstørrelsen for en individuel diskoverførsel. Du kan oversætte IOPS til MB/sek og MB/sek til latency, så længe du kender kødybden og overførselsstørrelsen.
Sekventiel gennemløb
Sekventiel gennemstrømning er den hastighed, du kan overføre data, typisk målt i megabyte pr. sekund (MB/sek.) eller gigabyte pr. sekund (GB/sek.). Din sekventielle gennemstrømningsmetrik i MB/sek. svarer til IOPS gange overførselsstørrelsen. For eksempel svarer 556 MB/sek. til 135.759 IOPS gange en 4096 bytes overførselsstørrelse, mens 135.759 IOPS gange en 8192 bytes overførselsstørrelse ville være 1112 MB/sek. sekventiel gennemstrømning. På trods af dens daglige betydning for SQL Server, bliver sekventiel diskgennemstrømning ofte forkortet i virksomhedens lager, både af lagerleverandører og af lageradministratorer. Det er faktisk også ret almindeligt at se de faktiske magnetiske diske i et DAS-kabinet (Direct Attached Storage) eller en SAN-enhed være så travlt, at de ikke kan levere deres fulde nominelle sekventielle gennemløb.
Sekventiel gennemstrømning er kritisk for mange almindelige databaseserveraktiviteter, inklusive fuld databasesikkerhedskopiering og -gendannelse, indeksoprettelse og -genopbygninger og store sekventielle læsescanninger af datavarehustypen (når dine data ikke passer ind i SQL Server-bufferpuljen). Et præstationsmål, jeg kan lide at skyde efter på nye databaseserver builds, er at have mindst 1 GB/sek. sekventiel gennemstrømning for hvert enkelt drevbogstav eller monteringspunkt. At have dette niveau af ydeevne (eller bedre) gør dit liv så meget lettere som databaseprofessionel. Det gør så mange af dine almindelige databaseopgaver så meget hurtigere, og det giver dig også frihed til at foretage hyppigere indeksjustering, når du kan oprette et indeks på en stor tabel på sekunder eller minutter i stedet for timer.
SQL Server I/O Workload Metrics
Når det kommer til SQL Server og I/O-ydelse, er der en række ting, som du bør måle og overvåge over tid. Du bør kende læse- og skriveforholdet for din arbejdsbyrde for alle dine brugerdatabasefiler og for tempdb. Forholdene vil være forskellige for forskellige SQL Server-filtyper og arbejdsbelastninger. Du kan bruge mine DMV Diagnostic Queries til at bestemme dette, og du kan også bruge Disk Activity View i SQL Sentry Performance Advisor for nemt at få et mere komplet overblik over din diskaktivitet, fra et overordnet billede på højt niveau, helt nede til individuelle filer:
SQL Sentry Performance Advisor:Diskaktivitet
Du bør også måle de typiske I/O-hastigheder for IOPS og sekventiel gennemløb. I Windows Performance Monitor (PerfMon) viser reads/sec og writes/sec IOPS, mens disk read bytes/sek og disk skrive bytes/sek repræsenterer sekventiel gennemstrømning. Du bør bruge PerfMon til at måle gennemsnitlig disk sek/læse og gennemsnitlig disk sek/skriv, som er læse- og skrivelatens på diskniveau. Endelig kan du bruge mine DMV Diagnostic Queries til at måle den gennemsnitlige læse- og skriveforsinkelse på filniveau for alle dine brugerdatabasefiler såvel som for tempdb.
Metoder til måling af I/O-ydelse
Du kan bruge Disk-sektionen i Windows Resource Monitor til at få et hurtigt overblik i realtid af nogle vigtige diskmetrikker for alle dine SQL Server-databasefiler. Går du dybere, kan du bruge PerfMon til at måle og overvåge de kritiske ydeevnetællere, som jeg tidligere har nævnt. Før du går i produktion med en ny databaseserver, bør du lave nogle diskbenchmark-tests for at bestemme, hvilken slags ydeevne dit I/O-undersystem rent faktisk kan levere. Dette er faktisk ikke så svært eller tidskrævende (hvis du bruger de rigtige værktøjer), men det bliver ofte glemt, når en ny databaseserver klargøres og testes.
Det første diskbenchmark, du altid bør køre, er CrystalDiskMark 4.0, som for nylig er blevet omskrevet til at bruge det relativt nye Microsoft DiskSpd diskbenchmark-program. CDM 4.0-brugergrænsefladen lader dig vælge en bredere række af testfilstørrelser, og den lader dig også vælge kødybden og antallet af tråde til testkørslerne. Dette giver dig mulighed for at få en mere serverlignende I/O-arbejdsbyrde, og det lader dig også mere korrekt understrege nyere NVMe flash-lagerenheder, der kan håndtere kødybder højere end 32.
CrystalDiskMark 4.03-resultater med QD =32 og tråde =1
Figur 2:CrystalDiskMark 4.03-resultater med QD =32 og tråde =4
I modsætning til tidligere versioner af CDM er de to mest relevante rækker til brug af SQL Server i midten af resultatvisningen. De er 4K tilfældige læser og skriver med en høj kødybde (32 som standard), og de sekventielle læser og skriver. Efter du har lavet nogle lagerbenchmark-tests med CrystalDiskMark 4.0, bør du lave nogle mere udtømmende tests med Microsoft DiskSpd. I en fremtidig artikel vil jeg dække, hvordan man bruger DiskSpd til at udføre mere komplet test for SQL Server.