Lagring: Metodtips för prestanda för SQL Server på virtuella Azure-datorer

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

Den här artikeln innehåller metodtips och riktlinjer för lagring 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 möjliga 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.

Mer information finns i de andra artiklarna i den här serien: Checklista, VM-storlek, Säkerhet, HADR-konfiguration och Samla in baslinje.

Checklista

Läs följande checklista för en kort översikt över de metodtips för lagring som beskrivs i resten av artikeln mer detaljerat:

• Övervaka programmet och fastställa kraven på lagringsbandbredd och svarstid för SQL Server-data, logg och tempdb filer innan du väljer disktyp.
• Om det är tillgängligt konfigurerar tempdbdu data och loggfiler på den lokala SSD-volymen D: . SQL IaaS-agenttillägget hanterar mappen och behörigheterna som behövs vid ometablering.
• För att optimera lagringsprestanda planerar du för högsta tillgängliga IOPS och använder datacachelagring som prestandafunktion för dataläsningar samtidigt som du undviker begränsningar för virtuella datorer och diskar.
• Överväg att använda Azure Elastic SAN för SQL Server-arbetsbelastningar för bättre kostnadseffektivitet på grund av lagringskonsolidering, delade dynamiska prestanda och möjligheten att köra högre dataflöde för lagring utan att behöva uppgradera en virtuell dator.
• Placera data, logg och tempdb filer på separata enheter.
  • För dataenheten använder du Premium P30- och P40-diskar eller mindre diskar för att säkerställa tillgängligheten för cachestöd. När du använder Ebdsv5 VM-serien använder du Premium SSD v2 som ger bättre prisprestanda för arbetsbelastningar som kräver högt IOPS- och I/O-dataflöde.
  • För loggenhetsplanen för kapacitet och testprestanda jämfört med kostnad vid utvärdering av antingen Premium SSD v2 eller Premium SSD P30 – P80-diskar
    • Om lagringsfördröjning undermillisekunder krävs använder du antingen Premium SSD v2 eller Azure Ultra Disks för transaktionsloggen .
    • För distributioner av virtuella datorer i M-serien bör du överväga att skriva accelerator över att använda Azure Ultra Disks.
  • Placera tempdb på den tillfälliga disken (den tillfälliga disken är tillfällig och standardvärdet D:\är ) för de flesta SQL Server-arbetsbelastningar som inte ingår i en redundansklusterinstans (FCI) när du har valt den optimala VM-storleken.
    • Om kapaciteten på den lokala enheten inte räcker för tempdbkan du överväga att storleksanpassa den virtuella datorn. Mer information finns i Principer för cachelagring av datafiler.
  • För FCI-plats tempdb på den delade lagringen.
    • Om FCI-arbetsbelastningen är starkt beroende av tempdb diskprestanda kan du som en avancerad konfigurationsplats tempdb på den lokala tillfälliga SSD-enheten (standard D:\) som inte ingår i FCI-lagringen. Den här konfigurationen behöver anpassad övervakning och åtgärd för att säkerställa att den lokala tillfälliga SSD-enheten (standard D:\) är tillgänglig hela tiden eftersom eventuella fel på den här enheten inte utlöser en åtgärd från FCI.
• Stripe flera Azure-datadiskar med hjälp av Lagringsutrymmen för att öka I/O-bandbredden upp till måldatorns IOPS- och dataflödesgränser.
• Ange värdcachelagring till skrivskyddad för datafildiskar.
• Ange värdcachelagring till ingen för loggfildiskar.
  • Aktivera inte cachelagring av läsning/skrivning på diskar som innehåller SQL Server-data eller loggfiler.
  • Stoppa alltid SQL Server-tjänsten innan du ändrar cacheinställningarna för disken.
• För utveckling och testning av arbetsbelastningar och långsiktig säkerhetskopieringsarkivering bör du överväga att använda standardlagring. Vi rekommenderar inte att du använder Standard HDD/SSD för produktionsarbetsbelastningar.
• Kreditbaserad disksprängning (P1-P20) bör endast beaktas för mindre dev/test-arbetsbelastningar och avdelningssystem.
• Optimera lagringsprestanda genom att planera för högsta tillgängliga IOPS och använda datacachelagring som prestandafunktion för dataläsningar samtidigt som du undviker att begränsa/begränsa virtuella datorer och diskar.
• Formatera datadisken så att den använder 64 KB allokeringsenhetsstorlek för alla datafiler som placeras på en annan enhet än den tillfälliga D:\ enheten (som har standardvärdet 4 KB). Virtuella SQL Server-datorer som distribueras via Azure Marketplace har datadiskar som är formaterade med allokeringsenhetsstorlek och interleave för lagringspoolen inställd på 64 KB.
• Konfigurera lagringskontot i samma region som den virtuella SQL Server-datorn.
• Inaktivera Geo-redundant lagring i Azure (geo-replikering) och använd LRS (lokal redundant lagring) på lagringskontot.
• Aktivera SQL Best Practices Assessment för att identifiera möjliga prestandaproblem och utvärdera att den virtuella SQL Server-datorn har konfigurerats för att följa metodtipsen.
• Granska och övervaka disk- och VM-gränser med hjälp av mått för lagrings-I/O-användning.
• Undanta SQL Server-filer från genomsökning av antivirusprogram, inklusive datafiler, loggfiler och säkerhetskopieringsfiler.

Information om hur du jämför lagringschecklistan med andra metodtips finns i den omfattande checklistan med metodtips för prestanda.

Översikt

Om du vill hitta den mest effektiva konfigurationen för SQL Server-arbetsbelastningar på en virtuell Azure-dator börjar du med att mäta lagringsprestanda för ditt affärsprogram. När lagringskraven är kända väljer du en virtuell dator som stöder nödvändig IOPS och dataflöde med rätt förhållande mellan minne och virtuell kärna.

Välj en VM-storlek med tillräcklig lagringsskalbarhet för din arbetsbelastning och en blandning av diskar (vanligtvis i en lagringspool) som uppfyller företagets kapacitets- och prestandakrav.

Vilken typ av disk som är beroende av både den filtyp som finns på disken och dina högsta prestandakrav.

Dricks

Etablering av en virtuell SQL Server-dator via Azure-portalen hjälper dig genom lagringskonfigurationsprocessen och implementerar de flesta metodtips för lagring, till exempel att skapa separata lagringspooler för dina data och loggfiler, rikta in dig på tempdb D:\ enheten och aktivera den optimala cachelagringsprincipen. Mer information om hur du etablerar och konfigurerar lagring finns i SQL VM-lagringskonfiguration.

VM-disktyper

Du har ett val i prestandanivån för dina diskar. De typer av hanterade diskar som är tillgängliga som underliggande lagring (som anges genom att öka prestandafunktionerna) är standardhårddiskenheter (HDD), SSD (Standard Solid State Drives), Premium SSD, Premium SSD v2 och Ultra Disks.

För Standard HDD, Standard SSD och Premium SSD ökar diskens prestanda med storleken på disken, grupperad efter premiumdisketiketter som P1 med 4 GiB utrymme och 120 IOPS till P80 med 32 TiB lagringsutrymme och 20 000 IOPS. Premium Storage har stöd för en lagringscache som hjälper till att förbättra läs- och skrivprestanda för vissa arbetsbelastningar. Mer information finns i Översikt över hanterade diskar.

Prestanda för Premium SSD v2 och Ultra Disks kan ändras oberoende av diskens storlek. Mer information finns i Ultra-diskprestanda och Premium SSD v2-prestanda.

Det finns också tre huvudsakliga diskroller att tänka på för din SQL Server på en virtuell Azure-dator – en OS-disk, en tillfällig disk och dina datadiskar. Välj noggrant vad som lagras på operativsystemenheten (C:\) och den tillfälliga tillfälliga enheten (D:\).

Operativsystemdisk

En operativsystemdisk är en virtuell hårddisk som kan startas och monteras som en version av ett operativsystem som körs och är märkt som C:\ enheten. När du skapar en virtuell Azure-dator ansluter plattformen minst en disk till den virtuella datorn för operativsystemdisken. Enheten C:\ är standardplatsen för programinstallationer och filkonfiguration.

För SQL Server-produktionsmiljöer ska du inte använda operativsystemdisken för datafiler, loggfiler, felloggar.

Tillfällig disk

Många virtuella Azure-datorer innehåller en annan disktyp som kallas tillfällig disk (märkt som D:\ enheten). Beroende på VM-serien och storleken på den här disken varierar kapaciteten. Den tillfälliga disken är tillfällig, vilket innebär att disklagringen återskapas (som i frigörs och allokeras igen), när den virtuella datorn startas om eller flyttas till en annan värd (till exempel för tjänståterställning).

Den tillfälliga lagringsenheten lagras inte i fjärrlagring och bör därför inte lagra användardatabasfiler, transaktionsloggfiler eller något som måste sparas.

Placera tempdb på den lokala tillfälliga SSD-enheten D:\ för SQL Server-arbetsbelastningar om inte förbrukning av lokal cache är ett problem. Om du använder en virtuell dator som inte har en tillfällig disk rekommenderar vi att du placerar tempdb den på en egen isolerad disk eller lagringspool med cachelagring inställd på skrivskyddad. Mer information finns i principer för cachelagring av tempdb-data.

Datadiskar

Datadiskar är fjärrlagringsdiskar som ofta skapas i lagringspooler för att överskrida den kapacitet och prestanda som en enskild disk kan erbjuda den virtuella datorn.

Koppla det minsta antalet diskar som uppfyller IOPS-, dataflödes- och kapacitetskraven för din arbetsbelastning. Överskrid inte det maximala antalet datadiskar för den minsta virtuella datorn som du planerar att ändra storlek till.

Placera data och loggfiler på datadiskar som etablerats efter bästa prestandakrav.

Formatera datadisken så att den använder 64 KB allokeringsenhetsstorlek för alla datafiler som placeras på en annan enhet än den tillfälliga D:\ enheten (som har standardvärdet 4 KB). Virtuella SQL Server-datorer som distribueras via Azure Marketplace har datadiskar som är formaterade med allokeringsenhetsstorlek och interleave för lagringspoolen inställd på 64 KB.

Kommentar

Det är också möjligt att vara värd för dina SQL Server-databasfiler direkt på Azure Blob Storage eller på SMB-lagring , till exempel Azure Premium-filresurs, men vi rekommenderar att du använder Azure-hanterade diskar för bästa prestanda, tillförlitlighet och funktionstillgänglighet.

Premium SSD v2

Du bör använda Premium SSD v2-diskar när du kör SQL Server-arbetsbelastningar i regioner som stöds, om de aktuella begränsningarna är lämpliga för din miljö. Beroende på din konfiguration kan Premium SSD v2 vara billigare än Premium SSD, samtidigt som prestandaförbättringar uppnås. Med Premium SSD v2 kan du individuellt justera ditt dataflöde eller IOPS oberoende av diskens storlek. Om du kan justera prestandaalternativen individuellt kan du göra detta större kostnadsbesparingar och göra så att du kan utföra skriptändringar för att uppfylla prestandakraven under förväntade eller kända perioder av behov. Vi rekommenderar att du använder Premium SSD v2 när du använder Ebdsv5 VM-serien eftersom det är en mer kostnadseffektiv lösning för dessa datorer med högt I/O-dataflöde. Premium SSD v2 stöder för närvarande inte värdcachelagring, så du bör välja en VM-storlek med högt oanvänd dataflöde, till exempel virtuella Datorer i Ebdsv5-serien.

Premium SSD v2-diskar stöds för närvarande inte av SQL Server-galleribilder, men de kan användas med SQL Server på virtuella Azure-datorer när de konfigureras manuellt.

Azure Elastic SAN

Azure Elastic SAN levererar en enormt skalbar, kostnadseffektiv, mycket högpresterande och tillförlitlig blocklagringslösning som ansluter till en mängd olika Azure-beräkningstjänster via iSCSI-protokollet. Elastic SAN möjliggör en sömlös övergång från en befintlig SAN-lagringsegendom till molnet utan att behöva omstrukturera kundens programarkitektur. Den här lösningen kan uppnå massiv skalning – upp till miljontals IOPS, tvåsiffriga GB/s dataflöde och korta svarstider med ensiffrig millisekunder med inbyggd återhämtning för att minimera stilleståndstiden. Detta gör det bra för kunder som vill konsolidera lagring, kunder som arbetar med flera beräkningstjänster eller de som har arbetsbelastningar som kräver höga dataflödesnivåer som uppnås genom att driva lagring över nätverksbandbredd. 

Kommentar

• Vm-storleksändring med elastiskt SAN bör hantera dataflödeskrav för produktion (VM till virtuell dator) tillsammans med lagringsdataflödet.

Överväg att placera SQL Server-arbetsbelastningar på Elastic SAN för bättre kostnadseffektivitet eftersom:

• Lagringskonsolidering och dynamisk prestandadelning: Normalt för SQL Server på Azure VM-arbetsbelastningar etableras disklagring per virtuell dator baserat på kundens kapacitet och högsta prestandakrav för den virtuella datorn. Den här överetablerade prestandan är tillgänglig när det behövs, men den oanvända prestandan kan inte delas med arbetsbelastningar på andra virtuella datorer. Elastiskt SAN, som liknar lokalt SAN, gör det möjligt att konsolidera lagringsbehoven för flera SQL- och icke-SQL-arbetsbelastningar för att uppnå bättre kostnadseffektivitet, med möjlighet att dynamiskt dela etablerade prestanda över de volymer som etablerats till dessa olika arbetsbelastningar baserat på I/O-krav. Till exempel i USA, östra, om du har 10 arbetsbelastningar som kräver 2 TiB-kapacitet och 10 000 IOPS vardera, men tillsammans behöver de inte mer än 60 000 IOPS vid någon tidpunkt. Du kan konfigurera ett elastiskt SAN med 12 basenheter (1 basenhet = 0,08 USD per GiB/månad) som ger dig 12 TiB-kapacitet och 60 000 IOPS och 8 enheter med endast kapacitet (1 kapacitetsenhet = 0,06 USD per GiB/månad) som ger dig den återstående 8 TiB-kapaciteten till ett billigare pris. Den här optimala lagringskonfigurationen ger bättre kostnadseffektivitet samtidigt som du tillhandahåller nödvändiga prestanda (10 000 IOPS) för var och en av dessa arbetsbelastningar. Mer information om elastiska SAN-basenheter och endast kapacitetsetableringsenheter finns i Planera för ett Elastiskt SAN för Azure och för priser, besök Azure Elastic SAN – Prissättning.
• För att öka dataflödet för lagring: SQL Server på distributioner av virtuella Azure-datorer kräver ibland överetablering av en virtuell dator på grund av diskens dataflödesgränser för den virtuella datorn. Du kan undvika detta med Elastic SAN, eftersom du kör högre lagringsdataflöde över beräkningsnätverksbandbredden med iSCSI-protokollet. Till exempel är en Standard_E32bds_v5 virtuell dator (SCSI) begränsad till 88 000 IOPS och 2 500 Mbit/s för disk-/lagringsdataflöde, men det kan uppnå upp till högst 16 000 Mbit/s-nätverksdataflöde. Om kravet på lagringsdataflöde för din arbetsbelastning är större än 2 500 Mbit/s behöver du inte uppgradera den virtuella datorn till en högre SKU eftersom den nu kan stödja upp till 16 000 Mbit/s med elastic SAN.

Premium SSD

Använd Premium SSD för data och loggfiler för SQL Server-produktionsarbetsbelastningar. Premium SSD IOPS och bandbredd varierar beroende på diskstorlek och typ.

För produktionsarbetsbelastningar använder du P30- och/eller P40-diskarna för SQL Server-datafiler för att säkerställa cachelagringsstöd och använda P30 upp till P80 för SQL Server-transaktionsloggfiler. För den bästa totala ägandekostnaden börjar du med P30s (5 000 IOPS/200 MBPS) för data och loggfiler och väljer bara högre kapaciteter när du behöver kontrollera antalet virtuella datorer. För dev/test eller små system kan du välja att använda storlekar som är mindre än P30 eftersom dessa stöder cachelagring, men de erbjuder inte reserverade priser.

För OLTP-arbetsbelastningar matchar du mål-IOPS per disk (eller lagringspool) med dina prestandakrav med hjälp av arbetsbelastningar vid hög belastning och Disk Reads/sec + Disk Writes/sec prestandaräknare. För informationslager och rapporteringsarbetsbelastningar matchar du måldataflödet med hjälp av arbetsbelastningar vid tider med hög belastning och Disk Read Bytes/sec + Disk Write Bytes/sec.

Använd Lagringsutrymmen för att uppnå optimala prestanda, konfigurera två pooler, en för loggfilerna och den andra för datafilerna. Om du inte använder disklistning använder du två Premium SSD-diskar mappade till separata enheter, där den ena enheten innehåller loggfilen och den andra innehåller data.

Etablerad IOPS och dataflöde per disk som används som en del av din lagringspool. Diskarnas kombinerade IOPS- och dataflödesfunktioner är den maximala kapaciteten upp till dataflödesgränserna för den virtuella datorn.

Det bästa sättet är att använda så många diskar som möjligt samtidigt som du uppfyller de minsta kraven för IOPS (och dataflöde) och kapacitet. Pris- och prestandabalansen tenderar dock att vara bättre med ett stort antal små diskar snarare än ett litet antal stora diskar.

Skala premiumdiskar

Storleken på din Premium SSD avgör diskens initiala prestandanivå. Ange prestandanivån vid distributionen eller ändra den efteråt, utan att ändra diskens storlek. Om efterfrågan ökar kan du öka prestandanivån för att uppfylla dina affärsbehov.

Om du ändrar prestandanivån kan administratörer förbereda sig för och möta högre efterfrågan utan att förlita sig på disksprängningar.

Använd högre prestanda så länge som det behövs där faktureringen är utformad för att uppfylla lagringsprestandanivån. Uppgradera nivån så att den matchar prestandakraven utan att öka kapaciteten. Gå tillbaka till den ursprungliga nivån när den extra prestandan inte längre krävs.

Den här kostnadseffektiva och tillfälliga prestandaökningen är ett starkt användningsfall för riktade händelser som shopping, prestandatestning, träningshändelser och andra korta fönster där bättre prestanda endast behövs på kort sikt.

Mer information finns i Prestandanivåer för hanterade diskar.

Azure Ultra Disk

Om det finns behov av svarstider för undermillisekunder med kortare svarstid bör du överväga att använda Azure Ultra Disk för SQL Server-loggenheten, eller till och med dataenheten för program som är extremt känsliga för I/O-svarstid.

Ultradisk kan konfigureras där kapacitet och IOPS kan skalas separat. Med ultradiskadministratörer kan etablera en disk med kapacitets-, IOPS- och dataflödeskrav baserat på programbehov.

Ultradisk stöds inte i alla VM-serier och har andra begränsningar som regiontillgänglighet, redundans och stöd för Azure Backup. Mer information finns i Använda Azure-ultradiskar för en fullständig lista över begränsningar.

Standard HDD och SSD

Standard-HDD:er och SSD:er har varierande svarstider och bandbredd och rekommenderas endast för dev/test-arbetsbelastningar. Produktionsarbetsbelastningar bör använda Premium SSD v2 eller Premium SSD. Om du använder Standard SSD (utvecklings-/testscenarier) rekommenderar vi att du lägger till det maximala antalet datadiskar som stöds av din VM-storlek och använder disklistning med Lagringsutrymmen för bästa prestanda.

Cachelagring

Virtuella datorer som stöder cachelagring i Premium Storage kan dra nytta av ytterligare en funktion som kallas Azure BlobCache eller värdcachelagring för att utöka IOPS- och dataflödesfunktionerna för en virtuell dator. Virtuella datorer som är aktiverade för både Premium Storage- och Premium Storage-cachelagring har dessa två olika gränser för lagringsbandbredd som kan användas tillsammans för att förbättra lagringsprestandan.

Dataflödet för IOPS och MBIT/s utan cachelagring räknas mot en virtuell dators oanvända diskgenomflödesgränser. De maximala cachelagrade gränserna ger en annan buffert för läsningar som hjälper till att hantera tillväxt och oväntade toppar.

Aktivera premiumcachelagring när alternativet stöds för att avsevärt förbättra prestanda för läsningar mot dataenheten utan extra kostnad.

Läsningar och skrivningar till Azure BlobCache (cachelagrad IOPS och dataflöde) räknas inte mot den virtuella datorns ej anslutna IOPS- och dataflödesgränser.

Kommentar

Disk Cachelagring stöds inte för diskar 4 TiB och större (P50 och större). Om flera diskar är anslutna till den virtuella datorn stöds cachelagring på alla diskar som är mindre än 4 TiB. Mer information finns i Diskcachelagring.

Oåtkomt dataflöde

Maximalt IOPS och dataflöde för oansluten disk är den maximala gränsen för fjärrlagring som den virtuella datorn kan hantera. Den här gränsen definieras på den virtuella datorn och är inte en gräns för den underliggande disklagringen. Den här gränsen gäller endast för I/O mot dataenheter som fjärransluts till den virtuella datorn, inte den lokala I/O-enheten mot den temporära enheten (D:\ enheten) eller OS-enheten.

Mängden oanvänd IOPS och dataflöde som är tillgängligt för en virtuell dator kan verifieras i dokumentationen för den virtuella datorn.

Dokumentationen i M-serien visar till exempel att det maximala oanvända dataflödet för den Standard_M8ms virtuella datorn är 5 000 IOPS och 125 Mbit/s utan diskdataflöde.

På samma sätt kan du se att Standard_M32ts stöder 20 000 oanvänd disk-IOPS och 500 Mbit/s utan diskdataflöde. Den här gränsen styrs på VM-nivå oavsett den underliggande premiumdisklagringen.

Mer information finns i ej cachelagrade och cachelagrade gränser.

Cachelagrat och temporärt lagringsdataflöde

Gränsen för maximalt cachelagrat och temporärt lagringsdataflöde är en separat gräns från gränsen för oåtkomt dataflöde på den virtuella datorn. Azure BlobCache består av en kombination av den virtuella datorvärdens minne med slumpmässig åtkomst och lokalt ansluten SSD. Den temporära enheten (D:\ enheten) i den virtuella datorn finns också på den här lokala SSD:n.

Gränsen för maximalt cachelagrat och temporärt lagringsflöde styr I/O mot den lokala temporära enheten (D:\ enheten) och Azure BlobCache endast om cachelagring av värd är aktiverat.

När cachelagring är aktiverat på Premium Storage kan virtuella datorer skalas utöver begränsningarna för den fjärranslutna virtuella datorns IOPS- och dataflödesgränser.

Endast vissa virtuella datorer stöder cachelagring av både Premium Storage och Premium Storage (som måste verifieras i dokumentationen för den virtuella datorn). Dokumentationen i M-serien anger till exempel att både premiumlagring och cachelagring av Premium Storage stöds:

Gränserna för cacheminnet varierar beroende på storleken på den virtuella datorn. Till exempel stöder den Standard_M8ms virtuella datorn 10000 cachelagrad disk-IOPS och 1 000 Mbit/s cachelagrat diskdataflöde med en total cachestorlek på 793 GiB. På samma sätt stöder den Standard_M32ts virtuella datorn 40000 cachelagrad disk-IOPS och 400 Mbit/s cachelagrat diskdataflöde med en total cachestorlek på 3174 GiB.

Du kan aktivera cachelagring av värd manuellt på en befintlig virtuell dator. Stoppa alla programarbetsbelastningar och SQL Server-tjänsterna innan några ändringar görs i den virtuella datorns cachelagringsprincip. Om du ändrar inställningarna för vm-cachen kopplas måldisken från och kopplas tillbaka när inställningarna har tillämpats.

Principer för cachelagring av datafiler

Din cachelagringsprincip för lagring varierar beroende på vilken typ av SQL Server-datafiler som finns på enheten.

Följande tabell innehåller en sammanfattning av de rekommenderade cachelagringsprinciperna baserat på typen av SQL Server-data:

SQL Server-disk	Rekommendation
Datadisk	Aktivera Read-only cachelagring för de diskar som är värdar för SQL Server-datafiler. Läsningar från cachen går snabbare än de oåtkomliga läsningarna från datadisken. Ej angiven IOPS och dataflöde plus cachelagrad IOPS och dataflöde ger den totala möjliga prestandan som är tillgänglig från den virtuella datorn inom gränserna för de virtuella datorerna, men den faktiska prestandan varierar beroende på arbetsbelastningens möjlighet att använda cachen (cacheträffförhållandet).
Transaktionsloggdisk	Ange cachelagringsprincipen till None för diskar som är värdar för transaktionsloggen. Det finns ingen prestandafördel för att aktivera cachelagring för transaktionsloggdisken, och att ha antingen Read-only eller Read/Write cachelagring aktiverat på loggenheten kan försämra skrivningarnas prestanda mot enheten och minska mängden cache som är tillgänglig för läsningar på dataenheten.
Operativsystemdisk	Standardprincipen för cachelagring är Read/write för OS-enheten. Vi rekommenderar inte att du ändrar cachelagringsnivån för OS-enheten.
tempdb	Om tempdb det inte går att placera på den tillfälliga enheten D:\ på grund av kapacitetsskäl ändrar du antingen storlek på den virtuella datorn så att den får en större tillfällig enhet eller placerar tempdb den på en separat dataenhet med Read-only cachelagring konfigurerad. Den virtuella datorns cacheminne och tillfälliga enhet använder både den lokala SSD:n, så tänk på detta när storleksändringen som tempdb I/O räknas mot de cachelagrade IOPS- och dataflödes-VM-gränserna när den finns på den tillfälliga enheten.

Viktigt!

När du ändrar cacheinställningen för en Azure-disk så frånkopplas och återansluts måldisken. När du ändrar cacheinställningen för en disk som är värd för SQL Server-data, loggfiler eller programfiler bör du stoppa SQL Server-tjänsten tillsammans med andra relaterade tjänster för att undvika skadade data.

Mer information finns i Diskcachelagring.

Disklistning

Analysera dataflödet och bandbredden som krävs för dina SQL-datafiler för att fastställa antalet datadiskar, inklusive loggfilen och tempdb. Dataflödes- och bandbreddsgränserna varierar beroende på vm-storlek. Mer information finns i VM-storlek

Lägg till fler datadiskar och använd disklistning för mer dataflöde. Ett program som till exempel behöver 12 000 IOPS- och 180 MB/s-dataflöde kan använda tre randiga P30-diskar för att leverera 15 000 IOPS och 600 MB/s dataflöde.

Information om hur du konfigurerar disklistning finns i Disklistning.

Disktak

Det finns dataflödesgränser på både disk- och VM-nivå. De maximala IOPS-gränserna per virtuell dator och disk skiljer sig åt och är oberoende av varandra.

Program som förbrukar resurser utanför dessa gränser begränsas (kallas även begränsade). Välj en virtuell dator och diskstorlek i en diskremsa som uppfyller programkraven och som inte kommer att drabbas av begränsningar. Använd cachelagring eller justera programmet så att mindre dataflöde krävs för att åtgärda begränsningen.

Ett program som till exempel behöver 12 000 IOPS och 180 MB/s kan:

• Använd Standard_M32ms, som har ett maximalt oanvänt diskdataflöde på 20 000 IOPS och 500 Mbit/s.
• Stripe tre P30-diskar för att leverera 15 000 IOPS och 600 MB/s dataflöde.
• Använd en Standard_M16ms virtuell dator och använd värdcachelagring för att använda lokal cache överförbrukning av dataflöde.

Virtuella datorer som har konfigurerats för att skalas upp under tider med hög användning bör etablera lagring med tillräckligt med IOPS och dataflöde för att stödja den maximala VM-storleken samtidigt som det totala antalet diskar hålls mindre än eller lika med det maximala antal som stöds av den minsta virtuella datorns SKU som ska användas.

Mer information om begränsningar för diskbegränsning och hur du använder cachelagring för att undvika tak finns i Disk-I/O-tak.

Kommentar

Vissa disktak kan fortfarande leda till tillfredsställande prestanda för användarna. justera och underhålla arbetsbelastningar i stället för att ändra storlek till en större virtuell dator för att balansera hantering av kostnader och prestanda för verksamheten.

Skrivacceleration

Skrivacceleration är en diskfunktion som endast är tillgänglig för de virtuella datorerna i M-serien . Syftet med skrivacceleration är att förbättra I/O-svarstiden för skrivningar mot Azure Premium Storage när du behöver ensiffrig I/O-svarstid på grund av viktiga OLTP-arbetsbelastningar eller informationslagermiljöer med hög volym.

Använd Skrivacceleration för att förbättra skrivfördröjningen till den enhet som är värd för loggfilerna. Använd inte skrivacceleration för SQL Server-datafiler.

Skrivacceleratordiskar delar samma IOPS-gräns som den virtuella datorn. Anslutna diskar får inte överskrida IOPS-gränsen för skrivningsacceleratorer för en virtuell dator.

I följande tabell beskrivs antalet datadiskar och IOPS som stöds per virtuell dator:

VM-SKU	# Skriva acceleratordiskar	Skriva acceleratordiskens IOPS per virtuell dator
M416ms_v2, M416s_v2	16	20000
M128ms, M128s	16	20000
M208ms_v2, M208s_v2	8	10000
M64ms, M64ls, M64s	8	10000
M32ms, M32ls, M32ts, M32s	4	5000
M16ms, M16s	2	2500
M8ms, M8s	1	1250

Det finns flera begränsningar för att använda skrivacceleration. Mer information finns i Begränsningar när du använder skrivaccelerator.

Jämför med Azure Ultra Disk

Den största skillnaden mellan skrivacceleration och Azure ultradiskar är att skrivacceleration är en vm-funktion som endast är tillgänglig för M-serien och Azure Ultra Disks är ett lagringsalternativ. Skrivacceleration är en skrivoptimerad cache med sina egna begränsningar baserat på vm-storleken. Azure Ultra Disks är ett disklagringsalternativ med låg fördröjning för virtuella Azure-datorer.

Använd om möjligt skrivacceleration över ultradiskar för transaktionsloggdisken. För virtuella datorer som inte stöder skrivacceleration men som kräver låg svarstid till transaktionsloggen använder du Azure Ultra Disks.

Övervaka lagringsprestanda

För att utvärdera lagringsbehoven och avgöra hur bra lagringen presterar måste du förstå vad som ska mätas och vad dessa indikatorer innebär.

IOPS (indata/utdata per sekund) är antalet begäranden som programmet gör till lagring per sekund. Mät IOPS med prestandaövervakarens Disk Reads/sec räknare och Disk Writes/sec. OLTP-program (onlinetransaktionsbearbetning) måste driva högre IOPS för att uppnå optimala prestanda. Program som betalningsbearbetningssystem, online-shopping och system för försäljningsställen är alla exempel på OLTP-program.

Dataflöde är mängden data som skickas till den underliggande lagringen, ofta mätt med megabyte per sekund. Mät dataflödet med prestandaövervakarens Disk Read Bytes/sec räknare och Disk Write Bytes/sec. Datalagerhantering optimeras för att maximera dataflödet över IOPS. Program som datalager för analys, rapportering, ETL-arbetsströmmar och andra business intelligence-mål är alla exempel på program för datalagerhantering.

I/O-enhetsstorlekar påverkar IOPS- och dataflödesfunktioner eftersom mindre I/O-storlekar ger högre IOPS och större I/O-storlekar ger högre dataflöde. SQL Server väljer den optimala I/O-storleken automatiskt. Mer information om finns i Optimera IOPS, dataflöde och svarstid för dina program.

Det finns specifika Azure Monitor-mått som är ovärderliga för identifiering av tak på vm- och disknivå samt förbrukning och hälsotillstånd för AzureBlob-cachen. Information om hur du identifierar viktiga räknare som ska läggas till i övervakningslösningen och instrumentpanelen i Azure-portalen finns i Mått för lagringsanvändning.

Kommentar

Azure Monitor erbjuder för närvarande inte mått på disknivå för den tillfälliga temporära enheten (D:\). VM Cachelagrad IOPS-förbrukad procentandel och förbrukad vm-cachelagrad bandbredd i procent återspeglar IOPS och dataflöde från både den tillfälliga temporära enheten (D:\) och cachelagringen av värden tillsammans.

Nästa steg

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

• Snabbchecklista

• Storlek på virtuell dator

• Säkerhet

• HADR-inställningar

• Samla in baslinje

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

• Detaljerad testning av SQL Server-prestanda på virtuella Azure-datorer med TPC-E och TPC_C benchmarks finns i bloggen Optimera OLTP-prestanda.

• 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.