Dela via

Samla in baslinje: Metodtips för prestanda för SQL Server på en virtuell Azure-dator

  • Artikel

Gäller för:SQL Server på en virtuell Azure-dator

Den här artikeln innehåller information om hur du samlar in en prestandabaslinje som en serie metodtips och riktlinjer för att optimera prestanda för din SQL Server på virtuella Azure-datorer (VM).

Det finns vanligtvis en kompromiss mellan att optimera för kostnader och optimera prestanda. Den här serien med metodtips för prestanda fokuserar på att få bästa prestanda för SQL Server på virtuella Azure-datorer. Om din arbetsbelastning är mindre krävande kanske du inte behöver varje rekommenderad optimering. Tänk på dina prestandabehov, kostnader och arbetsbelastningsmönster när du utvärderar dessa rekommendationer.

Översikt

För en normativ metod samlar du in prestandaräknare med PerfMon/LogMan och samlar in SQL Server-väntestatistik för att bättre förstå allmänna tryck och potentiella flaskhalsar i källmiljön.

Börja med att samla in PROCESSOR, minne, IOPS, dataflöde och svarstid för källarbetsbelastningen vid tider med hög belastning efter checklistan för programprestanda.

Samla in data under hög belastning, till exempel arbetsbelastningar under din vanliga arbetsdag, men även andra processer med hög belastning, till exempel bearbetning i slutet av dagen och ETL-arbetsbelastningar under helgen. Överväg att skala upp dina resurser för atypiskt mycket arbetsbelastningar, till exempel bearbetning i slutet av kvartalet, och skala sedan när arbetsbelastningen är klar.

Använd prestandaanalysen för att välja den VM-storlek som kan skalas efter arbetsbelastningens prestandakrav.

Lagring

SQL Server-prestanda beror mycket på I/O-undersystemet och lagringsprestanda mäts med IOPS och dataflöde. Om inte databasen passar in i fysiskt minne tar SQL Server ständigt databassidor in och ut ur buffertpoolen. Datafilerna för SQL Server bör behandlas på olika sätt. Åtkomsten till loggfiler är sekventiell, förutom när en transaktion måste återställas där datafiler, inklusive tempdb, används slumpmässigt. Om du har ett långsamt I/O-undersystem kan dina användare uppleva prestandaproblem som långsamma svarstider och uppgifter som inte slutförs på grund av tidsgränser.

De virtuella Azure Marketplace-datorerna har loggfiler på en fysisk disk som är separat från datafilerna som standard. Antalet tempdb datafiler och storleken uppfyller bästa praxis och är riktade till den tillfälliga D:\ enheten.

Följande PerfMon-räknare kan hjälpa dig att verifiera det I/O-dataflöde som krävs av din SQL Server:

  • \LogicalDisk\DiskLäsningar/s (läs-IOPS)
  • \LogicalDisk\Disk Writes/Sec (skriv-IOPS)
  • \LogicalDisk\Disk Read Bytes/Sec (läsdataflödeskrav för data, logg och tempdb filer)
  • \LogicalDisk\Disk Write Bytes/Sec (krav på skrivdataflöde för data, logg och tempdb filer)

Med hjälp av IOPS- och dataflödeskrav på toppnivåer utvärderar du VM-storlekar som matchar kapaciteten från dina mått.

Om din arbetsbelastning kräver 20 000 läs-IOPS- och 10K-skriv-IOPS kan du antingen välja E16s_v3 (med upp till 32 000 cachelagrat och 2 5600 ej cachelagrat IOPS) eller M16_s (med upp till 20 000 cachelagrade och 10 000 ej cachelagrade IOPS) med 2 P30-diskar randiga med lagringsutrymmen.

Se till att förstå både dataflödes- och IOPS-kraven för arbetsbelastningen eftersom virtuella datorer har olika skalningsgränser för IOPS och dataflöde.

Minne

Spåra både externt minne som används av operativsystemet samt det minne som används internt av SQL Server. Genom att identifiera tryck för någon av komponenterna kan du storleksanpassa virtuella datorer och identifiera möjligheter till justering.

Följande PerfMon-räknare kan hjälpa till att verifiera minneshälsan för en virtuell SQL Server-dator:

Compute

Beräkning i Azure hanteras på ett annat sätt än lokalt. Lokala servrar är byggda för att pågå i flera år utan uppgradering på grund av hanteringskostnader och kostnader för att skaffa ny maskinvara. Virtualisering minskar vissa av dessa problem, men program är optimerade för att dra största möjliga nytta av den underliggande maskinvaran, vilket innebär att alla betydande förändringar i resursförbrukningen kräver ombalansering av hela den fysiska miljön.

Detta är inte en utmaning i Azure där en ny virtuell dator på en annan serie maskinvara, och även i en annan region, är lätt att uppnå.

I Azure vill du dra nytta av så mycket av de virtuella datorresurserna som möjligt. Därför bör virtuella Azure-datorer konfigureras för att hålla den genomsnittliga processorn så hög som möjligt utan att påverka arbetsbelastningen.

Följande PerfMon-räknare kan hjälpa till att verifiera beräkningshälsan för en virtuell SQL Server-dator:

  • \Processorinformation(_Total)% processortid
  • \Process(sqlservr)% processortid

Kommentar

Försök helst att sikta på att använda 80 % av din beräkning, med toppar över 90 % men inte når 100 % under en längre tidsperiod. I grund och botten vill du bara etablera den beräkning som programmet behöver och sedan planera för att skala upp eller ned som företaget kräver.

Nästa steg

Mer information finns i de andra artiklarna i den här serien med metodtips:

Metodtips för säkerhet finns i Säkerhetsöverväganden för SQL Server på virtuella Azure-datorer.

Granska andra SQL Server Virtual Machine-artiklar på SQL Server på Översikt över virtuella Azure-datorer. Om du har frågor om virtuella SQL Server-datorer kan du läsa Vanliga frågor.