Azure Premium Storage: design för höga prestanda

Gäller för: ✔️ Virtuella Linux-datorer ✔️ Windows virtuella datorer:heavy_check_mark: Flexibla skalningsuppsättningar:heavy_check_mark: Enhetliga skalningsuppsättningar

Den här artikeln innehåller riktlinjer för att skapa högpresterande program med Azure Premium Storage. Du kan använda anvisningarna i det här dokumentet i kombination med metodtips för prestanda som gäller för tekniker som används av ditt program. För att illustrera riktlinjerna har vi använt SQL Server körs på Premium Storage som exempel i det här dokumentet.

Vi tar upp prestandascenarier för Storage i den här artikeln, men du måste optimera programlagret. Om du till exempel är värd för en SharePoint servergrupp i Azure Premium Storage kan du använda exemplen SQL Server den här artikeln för att optimera databasservern. Optimera dessutom servergruppens SharePoint server och programserver för att få bästa möjliga prestanda.

Den här artikeln hjälper dig att besvara följande vanliga frågor om hur du optimerar programprestanda på Azure Premium Storage,

• Hur mäter jag programmets prestanda?
• Varför ser du inte förväntade höga prestanda?
• Vilka faktorer påverkar programmets prestanda på Premium Storage?
• Hur påverkar dessa faktorer programmets prestanda på Premium Storage?
• Hur kan du optimera för IOPS, bandbredd och svarstid?

Vi har tillhandahållit dessa riktlinjer specifikt för Premium Storage eftersom arbetsbelastningar som körs på Premium Storage är mycket prestandakänsliga. Vi har tillhandahållit exempel där det är lämpligt. Du kan också använda några av dessa riktlinjer för program som körs på virtuella IaaS-datorer med Standard Storage diskar.

Innan du börjar, om du är nybörjare på Premium Storage bör du först läsa Välj en Azure-disktyp för virtuella IaaS-datorer och Skalbarhetsmål för bloblagringskonton på premiumsidan.

Programprestandaindikatorer

Vi utvärderar om ett program presterar bra eller inte använder prestandaindikatorer som hur snabbt ett program bearbetar en användarbegäran, hur mycket data ett program bearbetar per begäran, hur många begäranden som är en programbearbetning under en viss tidsperiod, hur länge en användare måste vänta på att få ett svar efter att ha skickat sin begäran. De tekniska termerna för dessa prestandaindikatorer är IOPS, dataflöde eller bandbredd och svarstid.

I det här avsnittet diskuterar vi vanliga prestandaindikatorer i samband med Premium Storage. I följande avsnitt, Samla in programkrav, lär du dig att mäta dessa prestandaindikatorer för ditt program. Senare i Optimera programprestanda får du lära dig mer om de faktorer som påverkar dessa prestandaindikatorer och rekommendationer för att optimera dem.

IOPS

IOPS, eller Indata-/utdataåtgärder per sekund, är antalet begäranden som ditt program skickar till lagringsdiskarna på en sekund. En indata-/utdataåtgärd kan vara läs- eller skrivåtgärd, sekventiell eller slumpmässig. OLTP-program (Online Transaction Processing) som en onlinebutikswebbplats måste bearbeta många samtidiga användarbegäranden omedelbart. Användarbegäranden är infognings- och uppdateringsintensiva databastransaktioner, som programmet måste bearbeta snabbt. Därför kräver OLTP-program mycket hög IOPS. Sådana program hanterar miljontals små och slumpmässiga I/O-begäranden. Om du har ett sådant program måste du utforma programinfrastrukturen så att den optimeras för IOPS. I det senare avsnittet Optimera programprestanda diskuterar vi i detalj alla faktorer som du måste överväga för att få hög IOPS.

När du kopplar en premiumlagringsdisk till en virtuell dator på hög nivå tilldelar Azure ett garanterat antal IOPS enligt diskspecifikationen. Exempel: en P50-disk ger 7500 IOPS. Varje storlek för virtuella datorer på hög nivå har en specifik IOPS-gräns. En virtuell Standard GS5-dator har till exempel en gräns på 80 000 IOPS.

Dataflöde

Dataflöde eller bandbredd är den mängd data som programmet skickar till lagringsdiskarna inom ett angivet intervall. Om ditt program utför indata-/utdataåtgärder med stora I/O-enhetsstorlekar krävs ett högt dataflöde. Informationslagerprogram brukar utfärda genomsökningsintensiva åtgärder som har åtkomst till stora delar av data i taget och ofta utför massåtgärder. Med andra ord kräver sådana program högre dataflöde. Om du har ett sådant program måste du utforma dess infrastruktur för att optimera dataflödet. I nästa avsnitt diskuterar vi i detalj de faktorer som du måste justera för att uppnå detta.

När du kopplar en Premium Storage-disk till en virtuell dator i hög skala tillhandahåller Azure dataflöde enligt diskspecifikationen. Till exempel tilldelas en P50-disk ett dataflöde på 250 MB per sekund per disk. Varje storlek för virtuella datorer på hög nivå har en specifik gräns för genomflödet. Till exempel, den virtuella datorn Standard GS5 har en maximal genomströmning på 2 000 MB per sekund.

Det finns en relation mellan dataflöde och IOPS enligt formeln nedan.

Därför är det viktigt att fastställa det optimala dataflödet och de IOPS-värden som krävs för ditt program. När du försöker optimera den ena påverkas även den andra. I ett senare avsnitt optimera programprestanda kommer vi att diskutera mer information om hur du optimerar IOPS och dataflöde.

Svarstid

Svarstiden är den tid det tar ett program att ta emot en enskild begäran, skicka den till lagringsdiskarna och skicka svaret till klienten. Detta är ett kritiskt mått på ett programs prestanda utöver IOPS och dataflöde. Svarstiden för en Premium Storage-disk är den tid det tar att hämta informationen för en begäran och skicka tillbaka den till ditt program. Premium Storage ger konsekvent korta svarstider. Premium Diskar är utformade för att tillhandahålla ensiffriga millisekunders svarstider för de flesta I/O-åtgärder. Om du aktiverar ReadOnly-cachelagring på premiumlagringsdiskar kan du få mycket kortare läsfördröjning. Vi kommer att diskutera Cachelagring i detalj i senare avsnitt om hur du optimerar programprestanda.

När du optimerar programmet för att få högre IOPS och dataflöde påverkar det programmets svarstid. När du har justerat programmets prestanda bör du alltid utvärdera programmets svarstid för att undvika oväntade beteenden med hög latens.

Följande kontrollplansåtgärder på Managed Disks kan omfatta förflyttning av disken från en Storage plats till en annan. Detta samordnas via bakgrundskopia av data som kan ta flera timmar att slutföra, vanligtvis mindre än 24 timmar beroende på mängden data i diskarna. Under den tiden kan det ta längre tid att läsa programmet än vanligt eftersom vissa läsningar kan omdirigeras till den ursprungliga platsen och det kan ta längre tid att slutföra. Skrivfördröjningen påverkas inte under den här perioden.

• Uppdatera lagringstypen.
• Koppla från och koppla en disk från en virtuell dator till en annan.
• Skapa en hanterad disk från en virtuell hårddisk.
• Skapa en hanterad disk från en ögonblicksbild.
• Konvertera ohanterade diskar till hanterade diskar.

Checklista för prestandaprogram för diskar

Det första steget i att utforma högpresterande program som körs på Azure Premium Storage är att förstå programmets prestandakrav. När du har samlat in prestandakrav kan du optimera programmet för att uppnå bästa möjliga prestanda.

I föregående avsnitt förklaras vanliga prestandaindikatorer, IOPS, dataflöde och svarstid. Du måste identifiera vilka av dessa prestandaindikatorer som är viktiga för ditt program för att ge önskad användarupplevelse. Hög IOPS är till exempel viktigast för OLTP-program som bearbetar miljontals transaktioner på en sekund. Högt dataflöde är viktigt för Data Warehouse program som bearbetar stora mängder data på en sekund. Extremt låg latens är avgörande för realtidsprogram som webbplatser med direktsänd videoströmning.

Mät sedan programmets maximala prestandakrav under hela dess livslängd. Använd exempelchecklistan nedan som en början. Registrera de maximala prestandakraven under normala, högsta och låg belastningsperioder för arbetsbelastningar. Genom att identifiera kraven för alla arbetsbelastningar kan du fastställa programmets övergripande prestandakrav. Den normala arbetsbelastningen för en e-handelswebbplats är till exempel de transaktioner som den fungerar under de flesta dagar under ett år. Den högsta arbetsbelastningen på webbplatsen är de transaktioner som den betjänar under helgperioden eller särskilda försäljningshändelser. Den högsta arbetsbelastningen uppstår vanligtvis under en begränsad period, men kan kräva att ditt program skalar två eller flera gånger sin normala drift. Ta reda på kraven på 50 percentiler, 90 percentiler och 99 percentiler. Detta hjälper till att filtrera bort eventuella avvikande värden i prestandakraven och du kan fokusera ditt arbete på att optimera för rätt värden.

Checklista för programprestandakrav

Om du har ett befintligt program och vill flytta till Premium Storage skapar du först checklistan ovan för det befintliga programmet. Skapa sedan en prototyp av ditt program på Premium Storage och utforma programmet baserat på riktlinjerna som beskrivs i Optimera programprestanda i ett senare avsnitt i det här dokumentet. I nästa artikel beskrivs de verktyg som du kan använda för att samla in prestandamått.

Räknare för att mäta prestandakrav för program

Det bästa sättet att mäta prestandakraven för ditt program är att använda verktyg för prestandaövervakning som tillhandahålls av serverns operativsystem. Du kan använda PerfMon för Windows och iostat för Linux. Dessa verktyg samlar in räknare som motsvarar varje mått som beskrivs i avsnittet ovan. Du måste samla in värdena för dessa räknare när programmet kör sina normala arbetsbelastningar, toppar och arbetsbelastningar utanför arbetstid.

PerfMon-räknarna är tillgängliga för processor, minne och varje logisk disk och fysisk disk på servern. När du använder premiumlagringsdiskar med en virtuell dator är de fysiska diskräknarna för varje Premium Storage-disk och logiska diskräknare för varje volym som skapas på premiumlagringsdiskarna. Du måste avbilda värdena för de diskar som är värdar för din programarbetsbelastning. Om det finns en en-till-en-mappning mellan logiska och fysiska diskar kan du referera till fysiska diskräknare. referera annars till de logiska diskräknarna. I Linux genererar iostat-kommandot en rapport för processor- och diskanvändning. Rapporten för diskanvändning visar statistik per fysisk enhet eller partition. Om du har en databasserver med dess data och loggar på separata diskar samlar du in dessa data för båda diskarna. I tabellen nedan beskrivs räknare för diskar, processorer och minne:

Läs mer om iostat och PerfMon.

Optimera programprestanda

De viktigaste faktorerna som påverkar prestanda för ett program som körs på Premium Storage är typen av I/O-begäranden, VM-storlek, Diskstorlek, Antal diskar, diskcachelagring, flertråding och ködjup. Du kan styra några av dessa faktorer med reglage som tillhandahålls av systemet. De flesta program kanske inte ger dig möjlighet att ändra I/O-storlek och ködjup direkt. Om du till exempel använder en SQL Server kan du inte välja I/O-storlek och ködjup. SQL Server väljer den optimala I/O-storleken och ködjupvärdena för att få bästa möjliga prestanda. Det är viktigt att förstå effekterna av båda typerna av faktorer på programmets prestanda, så att du kan etablera lämpliga resurser för att uppfylla prestandabehoven.

I det här avsnittet går du till checklistan för programkrav som du har skapat för att identifiera hur mycket du behöver för att optimera programmets prestanda. Baserat på det kommer du att kunna avgöra vilka faktorer i det här avsnittet som du behöver finjustera. Om du vill se effekterna av varje faktor på programmets prestanda kör du prestandatestningsverktyg i programkonfigurationen. Se artikeln Prestandatestning, som är länkad i slutet, för anvisningar om hur du kör vanliga prestandatestverktyg på Windows och virtuella Linux-datorer.

Optimera IOPS, dataflöde och svarstid på ett ögonblick

I tabellen nedan sammanfattas prestandafaktorer och de steg som krävs för att optimera IOPS, dataflöde och svarstid. Avsnitten efter den här sammanfattningen beskriver att varje faktor är mycket mer djupgående.

Mer information om VM-storlekar och IOPS, dataflöde och svarstider för varje typ av virtuell dator finns i Storlekar för virtuella datorer i Azure.

Typ av I//S-begäranden

En I/O-begäran är en åtgärdsenhet för indata/utdata som ditt program kommer att utföra. Genom att identifiera typen av I/O-begäranden, slumpmässiga eller sekventiella, läsa eller skriva, små eller stora, kan du fastställa programmets prestandakrav. Det är viktigt att förstå vilken typ av I/O-begäranden som krävs för att fatta rätt beslut när du utformar din programinfrastruktur. I/O måste distribueras jämnt för att uppnå bästa möjliga prestanda.

I/O-storleken är en av de viktigaste faktorerna. I/O-storleken är storleken på begäran om indata-/utdataåtgärd som genereras av ditt program. I/O-storleken har en betydande inverkan på prestanda, särskilt för IOPS och bandbredd som programmet kan uppnå. Följande formel visar relationen mellan IOPS, I/O-storlek och bandbredd/dataflöde.

I vissa program kan du ändra deras I/O-storlek, medan vissa program inte gör det. Till exempel SQL Server den optimala I/O-storleken och ger inte användarna några knappar för att ändra den. Oracle tillhandahåller å andra sidan en parameter med namnet DB BLOCK SIZE _ (DB-BLOCKSTORLEK) _ som du kan använda för att konfigurera databasens I/O-begärandestorlek.

Om du använder ett program, som inte tillåter att du ändrar I/O-storleken, använder du riktlinjerna i den här artikeln för att optimera prestanda-KPI:et som är mest relevant för ditt program. Exempel:

• Ett OLTP-program genererar miljontals små och slumpmässiga I/O-begäranden. För att hantera dessa typer av I/O-begäranden måste du utforma programinfrastrukturen för att få högre IOPS.
• Ett datalagerprogram genererar stora och sekventiella I/O-begäranden. För att hantera dessa typer av I/O-begäranden måste du utforma programinfrastrukturen så att den får högre bandbredd eller dataflöde.

Om du använder ett program som gör att du kan ändra I/O-storleken använder du den här tumregeln för I/O-storleken utöver andra prestandariktlinjer.

• Mindre I/O-storlek för att få högre IOPS. Till exempel 8 kB för ett OLTP-program.
• Större I/O-storlek för att få högre bandbredd/dataflöde. Till exempel 1 024 kB för ett informationslagerprogram.

Här är ett exempel på hur du kan beräkna IOPS och dataflöde/bandbredd för ditt program. Tänk dig ett program som använder en P30-disk. Det maximala IOPS och dataflöde/bandbredd som en P30-disk kan uppnå är 5 000 IOPS respektive 200 MB per sekund. Om ditt program nu kräver maximalt IOPS från P30-disken och du använder en mindre I/O-storlek som 8 kB, blir den resulterande bandbredden som du kan få 40 MB per sekund. Men om programmet kräver maximalt dataflöde/bandbredd från P30-disken och du använder en större I/O-storlek som 1 024 kB blir resulterande IOPS mindre än 200 IOPS. Justera därför I/O-storleken så att den uppfyller både programmets krav för IOPS och dataflöde/bandbredd. I följande tabell sammanfattas de olika I/O-storlekarna och deras motsvarande IOPS och dataflöde för en P30-disk.

Om du vill få ett högre IOPS och bandbredd än det högsta värdet för en enskild Premium Storage-disk använder du flera premiumdiskar stripade tillsammans. Du kan till exempel strimlar två P30-diskar för att få en kombinerad IOPS på 10 000 IOPS eller ett kombinerat dataflöde på 400 MB per sekund. Som förklaras i nästa avsnitt måste du använda en VM-storlek som stöder kombinerat disk-IOPS och dataflöde.

Om du vill se effekterna av I/V-storlek på programprestanda kan du köra prestandatestningsverktyg på dina virtuella datorer och diskar. Skapa flera testkörningar och använd olika I/O-storlek för varje körning för att se effekten. Mer information finns i benchmarking-artikeln, som är länkad i slutet.

Storlekar på virtuella datorer i hög skala

När du börjar utforma ett program är en av de första sakerna att göra att välja en virtuell dator som värd för ditt program. Premium Storage levereras med vm-storlekar i hög skala som kan köra program som kräver högre beräkningskraft och hög I/O-prestanda för lokala diskar. Dessa virtuella datorer ger snabbare processorer, ett högre förhållande mellan minne och kärna och en Solid-State (SSD) för den lokala disken. Exempel på virtuella datorer i hög skala Premium Storage virtuella datorer i DS- och GS-serien.

Virtuella datorer med hög skalning är tillgängliga i olika storlekar med olika antal processorkärnor, minne, operativsystem och tillfällig diskstorlek. Varje VM-storlek har också det maximala antalet datadiskar som du kan ansluta till den virtuella datorn. Den valda VM-storleken påverkar därför hur mycket bearbetnings-, minnes- och lagringskapacitet som är tillgänglig för ditt program. Det påverkar även kostnaden för compute Storage databehandling. Nedan visas till exempel specifikationerna för den största vm-storleken i en DS-serie och en GS-serie:

En fullständig lista över alla tillgängliga storlekar för virtuella Azure-datorer finns i Storlekar för virtuella datorer i Azure. Välj en VM-storlek som kan uppfylla och skalas enligt dina önskade programprestandakrav. Dessutom bör du ta hänsyn till följande viktiga överväganden när du väljer VM-storlekar.

Skalningsgränser
De maximala IOPS-gränserna per virtuell dator och per disk är olika och oberoende av varandra. Kontrollera att programmet kör IOPS inom gränserna för den virtuella datorn samt de premiumdiskar som är anslutna till den. Annars kommer programprestanda att uppleva begränsning.

Anta till exempel att ett programkrav är högst 4 000 IOPS. För att uppnå detta etablerar du en P30-disk på en virtuell DS1-dator. P30-disken kan leverera upp till 5 000 IOPS. Den virtuella DS1-datorn är dock begränsad till 3 200 IOPS. Programprestandan begränsas därför av VM-gränsen på 3 200 IOPS och prestandan försämras. Du kan förhindra detta genom att välja en virtuell dator och diskstorlek som båda uppfyller programkraven.

Driftkostnad
I många fall är det möjligt att den totala kostnaden för drift med Premium Storage är lägre än om du använder Standard Storage.

Tänk dig till exempel ett program som kräver 16 000 IOPS. För att uppnå den här prestandan behöver du en virtuell _ Standard D14 Azure IaaS-dator som kan ge en maximal IOPS på 16 000 med 32 standardlagringsdiskar på 1 TB. Varje standardlagringsdisk på 1 TB kan uppnå högst 500 IOPS. Den uppskattade kostnaden för den här virtuella datorn per månad är 1 570 USD. Månadskostnaden för 32 standardlagringsdiskar är 1 638 USD. Den uppskattade totala månadskostnaden är 3 208 USD.

Men om du har samma program på Premium Storage behöver du en mindre VM-storlek och färre premiumlagringsdiskar, vilket minskar den totala kostnaden. En virtuell _ Standard DS13-dator kan uppfylla kravet på 16 000 IOPS med hjälp av fyra P30-diskar. Den virtuella DS13-datorn har en maximal IOPS på 25 600 och varje P30-disk har en maximal IOPS på 5 000. Den här konfigurationen kan totalt uppnå 5 000 x 4 = 20 000 IOPS. Den uppskattade kostnaden för den här virtuella datorn per månad är 1 003 USD. Månadskostnaden för fyra P30 Premium Storage-diskar är 544,34 USD. Den uppskattade totala månadskostnaden är 1 544 USD.

I tabellen nedan sammanfattas kostnadsuppdelningen för det här scenariot för Standard och Premium Storage.

Linux-distributioner

Med Azure Premium Storage får du samma prestandanivå för virtuella datorer som kör Windows och Linux. Vi stöder många varianter av Linux-distributioner. Mer information finns i Linux-distributioner som stöds på Azure. Det är viktigt att notera att olika distributioner passar bättre för olika typer av arbetsbelastningar. Du ser olika prestandanivåer beroende på vilken distribution arbetsbelastningen körs på. Testa Linux-distributionerna med ditt program och välj den som fungerar bäst.

När du kör Linux Premium Storage bör du kontrollera de senaste uppdateringarna om nödvändiga drivrutiner för att säkerställa hög prestanda.

Premium för lagringsdiskar

Azure Premium Storage erbjuder en mängd olika storlekar så att du kan välja en som passar dina behov bäst. Varje diskstorlek har olika skalningsgräns för IOPS, bandbredd och lagring. Välj rätt storlek Premium Storage diskstorlek beroende på programkraven och storleken på den virtuella datorn i hög skala. Tabellen nedan visar diskstorlekarna och deras funktioner. Storlekarna P4, P6, P15, P60, P70 och P80 stöds för närvarande endast för Managed Disks.

*Gäller endast för diskar med burst-ning på begäran aktiverat.

Hur många diskar du väljer beror på vilken diskstorlek du väljer. Du kan använda en enda P50-disk eller flera P10-diskar för att uppfylla dina programkrav. Ta hänsyn till överväganden som anges nedan när du gör valet.

Skalningsgränser (IOPS och dataflöde)
IOPS- och dataflödesgränserna för varje Premium diskstorlek är olika och oberoende av VM-skalningsgränserna. Kontrollera att det totala IOPS- och dataflödet från diskarna ligger inom skalningsgränserna för den valda VM-storleken.

Om ett programkrav till exempel är högst 250 MB/sek och du använder en virtuell DS4-dator med en enda P30-disk. Den virtuella DS4-datorn kan ge upp till 256 MB/sek dataflöde. En enskild P30-disk har dock en dataflödesgräns på 200 MB/s. Programmet begränsas därför till 200 MB/sek på grund av diskgränsen. Du kan lösa den här gränsen genom att etablera fler än en datadisk till den virtuella datorn eller ändra storlek på diskarna till P40 eller P50.

Antal diskar
Fastställ hur många diskar du behöver genom att utvärdera programkraven. Varje VM-storlek har också en gräns för hur många diskar som du kan ansluta till den virtuella datorn. Detta är vanligtvis dubbelt så många kärnor. Se till att den VM-storlek du väljer har stöd för det antal diskar som behövs.

Kom ihåg Premium Storage diskarna har högre prestanda jämfört med Standard Storage diskar. Om du migrerar ditt program från en virtuell Azure IaaS-dator med standard-Storage till Premium Storage behöver du därför förmodligen färre premiumdiskar för att uppnå samma eller högre prestanda för ditt program.

Diskcachelagring

Virtuella datorer i hög skala som använder Azure Premium Storage har en cachelagringsteknik på flera nivåer som heter BlobCache. BlobCache använder en kombination av värd-RAM och lokal SSD för cachelagring. Det här cacheminnet är tillgängligt för Premium Storage beständiga diskar och lokala VM-diskar. Som standard är den här cacheinställningen inställd på Läsa/skriva för OS-diskar och ReadOnly för datadiskar som finns på Premium Storage. När diskcachelagring är aktiverat Premium Storage diskarna kan de virtuella datorerna med hög skalning uppnå extremt höga prestandanivåer som överskrider de underliggande diskprestandan.

Mer information om hur BlobCache fungerar finns i blogginlägget Inside Azure Premium Storage (I Azure-portalen).

Det är viktigt att aktivera cachelagring på rätt uppsättning diskar. Om du ska aktivera diskcachelagring på en premiumdisk eller inte beror på vilket arbetsbelastningsmönster disken kommer att hantera. Tabellen nedan visar standardinställningarna för cachelagring för os- och datadiskar.

Följande är de rekommenderade diskcacheinställningarna för datadiskar,

Readonly
Genom att konfigurera ReadOnly-cachelagring på Premium Storage-datadiskar kan du uppnå låg läsfördröjning och få mycket hög läs-IOPS och dataflöde för ditt program. Det här beror på två orsaker:

1. Läsningar som utförs från cachen, som finns på VM-minnet och lokal SSD, är mycket snabbare än läsningar från datadisken, som finns i Azure Blob Storage.
2. Premium Storage räknar inte de läsningar som betjänas från cachen mot diskens IOPS och dataflöde. Därför kan ditt program uppnå högre totalt IOPS och dataflöde.

ReadWrite
Som standard har OS-diskarna cachelagring med ReadWrite aktiverat. Vi har nyligen lagt till stöd för ReadWrite-cachelagring på datadiskar också. Om du använder ReadWrite-cachelagring måste du ha ett korrekt sätt att skriva data från cachen till beständiga diskar. Till exempel SQL Server skrivning av cachelagrade data till beständiga lagringsdiskar på egen hand. Om readWrite-cache används med ett program som inte hanterar ständiga data kan det leda till dataförlust om den virtuella datorn kraschar.

Ingen
För närvarande stöds Ingen endast på datadiskar. Det stöds inte på OS-diskar. Om du ställer in Ingen på en OS-disk åsidosätts detta internt och ställer in det på ReadOnly.

Du kan till exempel tillämpa dessa riktlinjer för att SQL Server körs Premium Storage genom att göra följande:

1. Konfigurera "ReadOnly"-cache på premiumlagringsdiskar som är värdar för datafiler.
   a. De snabba läsningarna från cachen sänker SQL Server eftersom datasidor hämtas mycket snabbare från cachen jämfört med direkt från datadiskarna.
   b. Att betjäna läsningar från cachen innebär att det finns ytterligare dataflöde tillgängligt från premiumdatadiskar. SQL Server kan använda det här ytterligare dataflödet för att hämta fler datasidor och andra åtgärder som säkerhetskopiering/återställning, batchinbelastningar och återskapning av index.
2. Konfigurera "Ingen"-cache på premiumlagringsdiskar som är värdar för loggfilerna.
   a. Loggfiler har främst skrivtunga åtgärder. Därför drar de inte nytta av ReadOnly-cachen.

Optimera prestanda på virtuella Linux-datorer

För alla Premium-HÅRDDISKAR eller ultradiskar kan du inaktivera "barriärer" för filsystem på disken för att förbättra prestanda när det är känt att det inte finns några cacheminnen som kan förlora data. Om Azure-diskcachelagring är inställt på ReadOnly eller None (Skrivskyddade) eller None (Ingen) kan du inaktivera barriärer. Men om cachelagring är inställt på ReadWrite bör hinder vara aktiverade för att säkerställa skrivbarhet. Barriärer är vanligtvis aktiverade som standard, men du kan inaktivera barriärer med någon av följande metoder beroende på filsystemtypen:

• För reiserFS använder du monteringsalternativet barrier=none för att inaktivera barriärer. Om du uttryckligen vill aktivera barriärer använder du barrier=flush.
• För ext3/ext4 använder du monteringsalternativet barrier=0 för att inaktivera barriärer. Om du vill aktivera barriärer explicit använder du barrier=1.
• För XFS använder du monteringsalternativet nobarrier för att inaktivera barriärer. Använd barriär för att uttryckligen aktivera barriärer. Från och med version 4.10 av den huvudsakliga Linux-kerneln garanterar utformningen av XFS-filsystemet alltid hållbarhet. Inaktivering av barriärer har ingen effekt och alternativet "nobarrier" är inaktuellt. Vissa Linux-distributioner kan dock ha bakåtportat ändringarna i en distribution med en tidigare kernelversion. Kontrollera med distributionsleverantören om statusen i den distribution och version som du kör.

Diskstrimning

När en virtuell dator i hög skala är ansluten till flera beständiga diskar för premiumlagring kan diskarna strimlades ihop för att aggregera sina IOP:er, bandbredd och lagringskapacitet.

På Windows kan du använda Lagringsutrymmen för att strimlar diskar tillsammans. Du måste konfigurera en kolumn för varje disk i en pool. Annars kan den övergripande prestandan för stripe-volymen vara lägre än förväntat på grund av ojämn distribution av trafik mellan diskarna.

Viktigt! Serverhanteraren användargränssnittet kan du ange det totala antalet kolumner upp till 8 för en stripe-volym. När du ansluter fler än åtta diskar använder du PowerShell för att skapa volymen. Med PowerShell kan du ange antalet kolumner som motsvarar antalet diskar. Om det till exempel finns 16 diskar i en enda stripe-uppsättning; ange 16 kolumner i parametern NumberOfColumns för PowerShell-cmdleten New-VirtualDisk.

I Linux använder du MDADM-verktyget för att strimlar diskar tillsammans. Detaljerade anvisningar om stripingdiskar på Linux finns i Konfigurera programvaru-RAID på Linux.

Stripe-storlek
En viktig konfiguration i diskstrimning är stripe-storleken. Stripe-storleken eller blockstorleken är det minsta dataformat som programmet kan hantera på en stripe-volym. Vilken stripe-storlek du konfigurerar beror på typen av program och dess begärandemönster. Om du väljer fel stripe-storlek kan det leda till I/O-justering, vilket leder till försämrad prestanda för ditt program.

Om en I/O-begäran som genereras av ditt program till exempel är större än diskstrimsstorleken skriver lagringssystemet den över stripe-enhetens gränser på mer än en disk. När det är dags att komma åt dessa data måste de söka i fler än en stripe-enhet för att slutföra begäran. Den kumulativa effekten av ett sådant beteende kan leda till betydande prestandaförsämring. Å andra sidan, om storleken på I/O-begäran är mindre än stripe-storleken, och om den är slumpmässig till sin natur, kan I/O-begärandena läggas till på samma disk, vilket orsakar en flaskhals och i slutändan försämrar I/O-prestandan.

Välj en lämplig stripe-storlek beroende på vilken typ av arbetsbelastning som ditt program kör. För slumpmässiga små I/O-begäranden använder du en mindre stripe-storlek. För stora sekventiella I/O-begäranden används en större stripe-storlek. Ta reda på rekommendationerna om stripe-storlek för det program som du kommer att köra på Premium Storage. Du SQL Server en stripe-storlek på 64 kB för OLTP-arbetsbelastningar och 256 kB för arbetsbelastningar i informationslager. Mer information finns i Metodtips för prestanda SQL Server virtuella Azure-datorer.

Flertråding

Azure har utformat Premium Storage plattform för att vara massivt parallell. Därför ger ett flertrådat program mycket högre prestanda än ett program med en tråd. Ett flertrådat program delar upp sina uppgifter över flera trådar och ökar effektiviteten för körningen genom att använda den virtuella datorn och diskresurserna till max.

Om ditt program till exempel körs på en virtuell dator med en kärna med två trådar kan processorn växla mellan de två trådarna för att uppnå effektivitet. Medan en tråd väntar på att en disk-I/O ska slutföras kan processorn växla till den andra tråden. På så sätt kan två trådar utföra mer än en enda tråd. Om den virtuella datorn har mer än en kärna minskar körningstiden ytterligare eftersom varje kärna kan köra uppgifter parallellt.

Du kanske inte kan ändra hur ett off-the-shelf-program implementerar entråding eller flertråding. Till exempel SQL Server kan hantera flera processorer och flera kärnor. Men SQL Server under vilka villkor den ska använda en eller flera trådar för att bearbeta en fråga. Den kan köra frågor och skapa index med hjälp av flertrådskörning. För en fråga som involverar sammanfogning av stora tabeller och sortering av data innan de återgår till användaren SQL Server använda flera trådar. En användare kan dock inte styra om SQL Server kör en fråga med en enda tråd eller flera trådar.

Det finns konfigurationsinställningar som du kan ändra för att påverka den här flertrådsbearbetningen eller den parallella bearbetningen av ett program. Om det till exempel SQL Server är det den högsta graden av parallellitetskonfiguration. Med den här inställningen maxdop kan du konfigurera det maximala antalet processorer SQL Server kan använda vid parallell bearbetning. Du kan konfigurera MAXDOP för enskilda frågor eller indexåtgärder. Detta är bra när du vill balansera resurser i systemet för ett prestandakritiskt program.

Säg till exempel att ditt program SQL Server kör en stor fråga och en indexåtgärd på samma gång. Låt oss anta att du ville att indexåtgärden skulle prestera bättre jämfört med den stora frågan. I sådana fall kan du ange MAXDOP-värdet för indexåtgärden till högre än MAXDOP-värdet för frågan. På så SQL Server fler processorer som den kan utnyttja för indexåtgärden jämfört med antalet processorer som den kan dedikera till den stora frågan. Kom ihåg att du inte styr hur många trådar SQL Server ska använda för varje åtgärd. Du kan styra det maximala antalet processorer som är dedikerade för flertråding.

Läs mer om grader av parallellitet i SQL Server. Ta reda på sådana inställningar som påverkar flertrådsing i ditt program och deras konfigurationer för att optimera prestanda.

Ködjup

Ködjupet, kölängden eller köstorleken är antalet väntande I/O-begäranden i systemet. Värdet för ködjupet avgör hur många I/O-åtgärder programmet kan rada upp, vilket lagringsdiskarna bearbetar. Den påverkar alla tre programprestandaindikatorer som vi har diskuterat i den här artikeln, viz., IOPS, dataflöde och svarstid.

Ködjup och flertråding är nära relaterade. Värdet ködjup anger hur mycket flertråding som kan uppnås av programmet. Om ködjupet är stort kan programmet köra fler åtgärder samtidigt, med andra ord fler flertrådsoperationer. Om ködjupet är litet, även om programmet är flertrådigt, har det inte tillräckligt med begäranden för samtidig körning.

Normalt tillåter inte program att du ändrar ködjupet, eftersom det, om det anges felaktigt, gör mer skada än nytta. Program ställer in rätt värde för ködjup för att få optimala prestanda. Det är dock viktigt att förstå det här konceptet så att du kan felsöka prestandaproblem med ditt program. Du kan också se effekterna av ködjup genom att köra prestandatestningsverktyg i systemet.

Vissa program innehåller inställningar som påverkar ködjupet. Till exempel kan inställningen MAXDOP (maximal grad av parallellitet) i SQL Server förklaras i föregående avsnitt. MAXDOP är ett sätt att påverka ködjup och flertrådsing, även om det inte direkt ändrar värdet för ködjup för SQL Server.

Högt ködjup
Ett högt ködjup radar upp fler åtgärder på disken. Disken känner till nästa begäran i kön i förväg. Disken kan därför schemalägga åtgärder i förväg och bearbeta dem i en optimal sekvens. Eftersom programmet skickar fler begäranden till disken kan disken bearbeta mer parallella I/O:er. I slutänden kommer programmet att kunna uppnå högre IOPS. Eftersom programmet bearbetar fler begäranden ökar även programmets totala dataflöde.

Normalt kan ett program uppnå maximalt dataflöde med 8–16+ utestående I/O:er per ansluten disk. Om ett ködjup är ett, push-ar programmet inte tillräckligt med I/O:er till systemet och det bearbetar mindre mängd under en viss period. Med andra ord mindre dataflöde.

I till exempel SQL Server anger MAXDOP-värdet för en fråga till "4" att SQL Server kan använda upp till fyra kärnor för att köra frågan. SQL Server avgör vad som är det bästa ködjupvärdet och antalet kärnor för frågekörningen.

Optimalt ködjup
Mycket högt ködjupvärde har också sina nackdelar. Om ködjupvärdet är för högt försöker programmet köra mycket hög IOPS. Om programmet inte har beständiga diskar med tillräckligt med etablerade IOPS kan detta påverka programmets svarstider negativt. Följande formel visar relationen mellan IOPS, svarstid och ködjup.

Du bör inte konfigurera ködjup till något högt värde, utan till ett optimalt värde som kan leverera tillräckligt med IOPS för programmet utan att påverka svarstiderna. Om programmets svarstid till exempel måste vara 1 millisekund, krävs det ködjup som krävs för att uppnå 5 000 IOPS, QD = 5 000 x 0,001 = 5.

Ködjup för stripe-volym
För stripe-volymer bör ködjupet vara tillräckligt högt så att varje disk har ett enskilt ködjup med hög belastning. Tänk dig till exempel ett program som push-erar ett ködjup på 2 och det finns fyra diskar i remsan. De två I/O-begärandena går till två diskar och återstående två diskar är inaktiva. Konfigurera därför ködjupet så att alla diskar kan vara upptagna. Formeln nedan visar hur du fastställer ködjupet för stripe-volymer.

Begränsning

Azure Premium Storage anger det angivna antalet IOPS och dataflöde beroende på vilka VM-storlekar och diskstorlekar du väljer. Varje gång ditt program försöker köra IOPS eller dataflöde över gränserna för vad den virtuella datorn eller disken kan hantera, Premium Storage begränsar det. Detta manifest i form av försämrad prestanda i ditt program. Detta kan innebära längre svarstider, lägre dataflöde eller lägre IOPS. Om Premium Storage inte begränsar kan programmet misslyckas helt genom att överskrida vad dess resurser kan uppnå. För att undvika prestandaproblem på grund av begränsning måste du därför alltid etablera tillräckligt med resurser för ditt program. Ta hänsyn till det vi har diskuterat i avsnitten om VM-storlekar och diskstorlekar ovan. Benchmarking är det bästa sättet att ta reda på vilka resurser du behöver för att vara värd för ditt program.

Nästa steg

Om du vill prestandatesta disken kan du läsa våra artiklar om prestandatestning av en disk:

• För Linux: Benchmark-prestanda för ditt program på Azure Disk Storage
• För Windows: Prestandatestning av en disk.

Läs mer om tillgängliga disktyper:

• För Linux: Välj en disktyp
• För Windows: Välj en disktyp

För SQL Server användare kan du läsa artiklar om metodtips för prestanda för SQL Server:

• Metodtips för prestanda för SQL Server i Azure Virtual Machines
• Azure Premium Storage ger högsta prestanda för SQL Server virtuella Azure-datorer