En av de vanligaste prestandaflaskhalsarna som jag ser som konsult är otillräcklig prestanda för lagringsundersystemet. Det finns ett antal orsaker till dålig lagringsprestanda, men att mäta den och förstå vad som behöver mätas och övervakas är alltid en användbar övning.
Det finns faktiskt tre huvudmått som är viktigast när det gäller att mäta I/O-undersystems prestanda:
Latens
Det första måttet är latens, vilket helt enkelt är den tid som det tar en I/O att slutföra. Detta kallas ofta för svarstid eller servicetid. Mätningen startar när operativsystemet skickar en begäran till enheten (eller diskkontrollern) och slutar när enheten har avslutat bearbetningen av begäran. Läsningar är klara när operativsystemet tar emot data, medan skrivningar är klara när enheten informerar operativsystemet om att den har tagit emot data.
För skrivningar kan data fortfarande finnas i en DRAM-cache på enheten eller diskkontrollern, beroende på din cachningspolicy och hårdvara. Återskrivningscache är mycket snabbare än genomskrivningscache, men det kräver en batteribackup för diskkontrollern. För användning av SQL Server vill du se till att du använder återskrivningscache snarare än genomskrivningscache om det alls är möjligt. Du vill också se till att din hårdvarudiskcache faktiskt är aktiverad, eftersom vissa diskhanteringsverktyg från leverantören inaktiverar den som standard.
Input/Output Operations per Second (IOPS)
Det andra måttet är Input/Output Operations per Second (IOPS). Detta mått är direkt relaterat till latens. Till exempel betyder en konstant latens på 1ms att en enhet kan bearbeta 1 000 IO:er per sekund med ett ködjup på 1. När fler IO:er läggs till i kön kommer latensen att öka. En av de viktigaste fördelarna med flashlagring är att den kan läsa/skriva till flera NAND-kanaler parallellt, tillsammans med det faktum att det inte finns några elektromekaniska rörliga delar för att bromsa diskåtkomsten. IOPS är faktiskt lika med ködjup dividerat med latensen, och IOPS i sig tar inte hänsyn till överföringsstorleken för en individuell disköverföring. Du kan översätta IOPS till MB/sek och MB/sek till latens så länge du känner till ködjupet och överföringsstorleken.
Sekventiell genomströmning
Sekventiell genomströmning är den hastighet som du kan överföra data, vanligtvis mätt i megabyte per sekund (MB/sek) eller gigabyte per sekund (GB/sek). Ditt sekventiella genomströmningsmått i MB/sek är lika med IOPS gånger överföringsstorleken. Till exempel, 556 MB/sek motsvarar 135 759 IOPS gånger en 4096 byte överföringsstorlek, medan 135 759 IOPS gånger en 8192 byte överföringsstorlek skulle vara 1112 MB/sek sekventiell genomströmning. Trots dess vardagliga betydelse för SQL Server, blir sekventiell diskgenomströmning ofta kortare i företagslagring, både av lagringsleverantörer och av lagringsadministratörer. Det är faktiskt också ganska vanligt att se de faktiska magnetiska skivorna i ett DAS-hölje (Direct Attached Storage) eller en SAN-enhet (Storage Area Network) vara så upptagen att de inte kan leverera sin fulla nominella sekventiella genomströmning.
Sekventiell genomströmning är avgörande för många vanliga databasserveraktiviteter, inklusive fullständiga databassäkerhetskopieringar och -återställningar, indexskapande och ombyggnader och stora sekventiella lässkanningar av datalagertyp (när dina data inte får plats i SQL Server-buffertpoolen). Ett prestationsmål jag gillar att skjuta efter på nya databasserverbyggen är att ha minst 1 GB/sek sekventiell genomströmning för varje enskild enhetsbokstav eller monteringspunkt. Att ha denna prestandanivå (eller bättre) gör ditt liv så mycket enklare som databasproffs. Det gör så många av dina vanliga databassysslor så mycket snabbare, och det ger dig också friheten att göra mer frekventa indexjusteringar när du kan skapa ett index på ett stort bord på sekunder eller minuter istället för timmar.
SQL Server I/O arbetsbelastningsstatistik
När det kommer till SQL Server och I/O-prestanda finns det ett antal saker som du bör mäta och övervaka över tid. Du bör känna till läs- och skrivförhållandet för din arbetsbelastning för alla dina användardatabasfiler och för tempdb. Förhållandena kommer att vara olika för olika SQL Server-filtyper och arbetsbelastningar. Du kan använda mina DMV-diagnostikfrågor för att avgöra detta, och du kan också använda Disk Activity View i SQL Sentry Performance Advisor för att enkelt få en mer komplett bild av din diskaktivitet, från en övergripande bild på hög nivå, hela vägen ner till enskilda filer:
SQL Sentry Performance Advisor:Disk Activity
Du bör också mäta de typiska I/O-hastigheterna för IOPS och sekventiell genomströmning. I Windows Performance Monitor (PerfMon) visar läs/sek och skriv/sek IOPS, medan diskläsbyte/sek och diskskrivbyte/sek representerar sekventiell genomströmning. Du bör använda PerfMon för att mäta genomsnittlig disksek/läs och genomsnittlig disksek/skriv, vilket är läs- och skrivlatens på disknivå. Slutligen kan du använda mina DMV Diagnostiska frågor för att mäta den genomsnittliga läs- och skrivfördröjningen på filnivå för alla dina användardatabasfiler såväl som för tempdb.
Metoder för att mäta I/O-prestanda
Du kan använda avsnittet Disk i Windows Resource Monitor för att få en snabb överblick i realtid av några viktiga diskmått för alla dina SQL Server-databasfiler. Om du går djupare kan du använda PerfMon för att mäta och övervaka de kritiska prestandaräknare som jag tidigare nämnt. Innan du går i produktion med en ny databasserver bör du göra några diskbenchmark-tester för att avgöra vilken typ av prestanda ditt I/O-undersystem faktiskt kan leverera. Detta är faktiskt inte så svårt eller tidskrävande (om du använder rätt verktyg), men det glöms ofta bort när en ny databasserver tillhandahålls och testas.
Det första diskriktmärket du alltid bör köra är CrystalDiskMark 4.0, som nyligen har skrivits om för att använda det relativt nya diskbenchmarkprogrammet Microsoft DiskSpd. Användargränssnittet för CDM 4.0 låter dig välja ett bredare utbud av testfilstorlekar och det låter dig också välja ködjup och antal trådar för testkörningarna. Detta låter dig få en mer serverliknande I/O-arbetsbelastning och det låter dig också stressa upp nyare NVMe flash-lagringsenheter som kan hantera ködjup högre än 32.
CrystalDiskMark 4.03-resultat med QD =32 och trådar =1
Figur 2:CrystalDiskMark 4.03-resultat med QD =32 och trådar =4
Till skillnad från tidigare versioner av CDM är de två mest relevanta raderna för SQL Server-användning i mitten av resultatvisningen. De är 4K slumpmässiga läsningar och skrivningar med ett högt ködjup (32 som standard), och sekventiell läsning och skrivning. Efter att du har gjort några benchmark-tester för lagring med CrystalDiskMark 4.0 bör du göra några mer omfattande tester med Microsoft DiskSpd. I en framtida artikel kommer jag att täcka hur man använder DiskSpd för att göra mer kompletta tester för SQL Server.