Azure Premium Storage: Design för höga prestanda
Gäller för: ✔️ Virtuella Linux-datorer ✔️ med virtuella Windows-datorer ✔️ – flexibla skalningsuppsättningar ✔️ Enhetliga skalningsuppsättningar
Den här artikeln innehåller riktlinjer för att skapa högpresterande program med hjälp av Azure Premium Storage. Du kan använda instruktionerna i det här dokumentet i kombination med bästa praxis för prestanda som gäller för tekniker som används av ditt program. För att illustrera riktlinjerna använder vi SQL Server som körs på Premium Storage som exempel i det här dokumentet.
Vi tar upp prestandascenarier för lagringsskiktet i den här artikeln, men du måste optimera programskiktet. Om du till exempel är värd för en SharePoint-servergrupp på Premium Storage kan du använda SQL Server-exemplen från den här artikeln för att optimera databasservern. Du kan också optimera SharePoint-servergruppens webbserver 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å Premium Storage:
- Hur kan du mäta 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 indata-/utdataåtgärder per sekund (IOPS), bandbredd och svarstid?
Vi tillhandahåller dessa riktlinjer specifikt för Premium Storage eftersom arbetsbelastningar som körs på Premium Storage är mycket prestandakänsliga. Vi tillhandahåller exempel där det är lämpligt. Du kan också tillämpa några av dessa riktlinjer på program som körs på virtuella IaaS-datorer (infrastruktur som en tjänst) med standardlagringsdiskar.
Kommentar
Ibland är det som verkar vara ett problem med diskprestanda faktiskt en flaskhals i nätverket. I dessa situationer bör du optimera nätverksprestandan.
Om du vill jämföra disken kan du läsa följande artiklar:
- För Linux: Benchmark-prestanda för ditt program på Azure Disk Storage
- För Windows: Benchmarka en disk
Om den virtuella datorn stöder accelererat nätverk kontrollerar du att den är aktiverad. Om den inte är aktiverad kan du aktivera den på redan distribuerade virtuella datorer på både Windows och Linux.
Innan du börjar, om du är nybörjare på Premium Storage, läser du först Välj en Azure-disktyp för virtuella IaaS-datorer och skalbarhetsmål för premium-sidbloblagringskonton.
Indikatorer för programprestanda
Vi utvärderar om ett program presterar bra eller inte med hjälp av 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 ett program bearbetar under en viss tidsperiod.
- Hur länge en användare måste vänta för att få ett svar efter att ha skickat sin begäran.
De tekniska villkoren för dessa prestandaindikatorer är IOPS, dataflöde eller bandbredd och svarstid.
I det här avsnittet diskuterar vi de vanliga prestandaindikatorerna i samband med Premium Storage. I avsnittet Checklista för prestandaprogram för diskar får du lära dig hur du mäter dessa prestandaindikatorer för ditt program. Senare i Optimera programprestanda får du lära dig om de faktorer som påverkar dessa prestandaindikatorer och rekommendationer för att optimera dem.
IOPS
IOPS är antalet begäranden som programmet skickar till lagringsdiskar på en sekund. En indata-/utdataåtgärd kan läsas eller skrivas, sekventiellt eller slumpmässigt. 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.
OLTP-program hanterar miljontals små och slumpmässiga I/O-begäranden. Om du har ett sådant program måste du utforma programinfrastrukturen för att optimera för IOPS. Mer information om alla faktorer att tänka på för att få hög IOPS finns i Optimera programprestanda.
När du ansluter en premiumlagringsdisk till din storskaliga virtuella dator tillhandahåller Azure ett garanterat antal IOPS enligt diskspecifikationen. Till exempel etablerar en P50-disk 7 500 IOPS. Varje storskalig VM-storlek har också en specifik IOPS-gräns som den kan upprätthålla. Till exempel, en Standard GS5-VM har en gräns på 80 000 IOPS.
Genomflöde
Dataflöde eller bandbredd är mängden data som programmet skickar till lagringsdiskarna inom ett angivet intervall. Om programmet utför indata-/utdataåtgärder med stora I/O-enhetsstorlekar kräver det högt dataflöde. Datalagerprogram 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 de faktorer som du måste justera för att uppnå den här optimeringen.
När du kopplar en Premium Storage-disk till en storskalig virtuell dator etablerar Azure dataflöde enligt den diskspecifikationen. Till exempel etablerar en P50-disk ett diskflöde på 250 MB/sek. Varje storskalig VM-storlek har också en specifik dataflödesgräns som den kan upprätthålla. Standard GS5 VM har till exempel ett maximalt dataflöde på 2 000 MB/s.
Det finns en relation mellan dataflöde och IOPS, som du ser i följande formel.
Det är viktigt att fastställa det optimala dataflödet och de IOPS-värden som programmet kräver. När du försöker optimera den ena påverkas den andra också. Mer information om hur du optimerar IOPS och dataflöde finns i Optimera programprestanda.
Svarstid
Svarstiden är den tid det tar för ett program att ta emot en enda begäran, skicka den till lagringsdiskar och skicka svaret till klienten. Svarstid ä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 kommunicera den tillbaka till ditt program. Premium Storage ger konsekvent låga svarstider. Premium-diskar är utformade för att tillhandahålla ensiffriga svarstider för millisekunder för de flesta I/O-åtgärder. Om du aktiverar ReadOnly-värdcachelagring på Premium Storage-diskar kan du få mycket lägre svarstid för läsning. Mer information om diskcachelagring finns i Diskcachelagring.
När du optimerar ditt program för att få högre IOPS och dataflöde påverkar det programmets svarstid. När du har justerat programmets prestanda utvärderar du programmets svarstid för att undvika oväntat beteende med långa svarstider.
Vissa kontrollplansåtgärder på hanterade diskar kan flytta disken från en lagringsplats till en annan. Att flytta disken mellan lagringsplatser samordnas via en bakgrundskopia av data, vilket kan ta flera timmar att slutföra. Vanligtvis är tiden mindre än 24 timmar beroende på mängden data på diskarna. Under den tiden kan programmet få högre läsfördröjning än vanligt eftersom vissa läsningar kan omdirigeras till den ursprungliga platsen och ta längre tid att slutföra.
Under en bakgrundskopia påverkas inte skrivfördröjningen för de flesta disktyper. För Premium SSD v2 och Ultra Disks, om disken har en 4K-sektorstorlek, får den högre läsfördröjning. Om disken har en sektorstorlek på 512e får den högre svarstid för läsning och skrivning.
Följande kontrollplansåtgärder kan flytta disken mellan lagringsplatser och orsaka ökad svarstid:
- Uppdatera lagringstypen.
- Koppla från och anslut 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å Premium Storage är att förstå programmets prestandakrav. När du har samlat in prestandakrav kan du optimera ditt program för att uppnå bästa möjliga prestanda.
I föregående avsnitt förklarade vi de vanliga prestandaindikatorerna: IOPS, dataflöde och svarstid. Du måste identifiera vilka av dessa prestandaindikatorer som är viktiga för ditt program för att leverera önskad användarupplevelse. Till exempel är hög IOPS viktigast för OLTP-program som bearbetar miljontals transaktioner på en sekund. Högt dataflöde är viktigt för datalagerprogram som bearbetar stora mängder data på en sekund. Extremt låg svarstid är avgörande för realtidsprogram som livevideoströmningswebbplatser.
Mät sedan programmets maximala prestandakrav under hela dess livslängd. Använd följande exempelchecklista som start. Registrera de maximala prestandakraven under normala arbetsbelastningsperioder, toppar och lågtimmarsperioder. Genom att identifiera krav för alla arbetsbelastningsnivåer kan du fastställa programmets övergripande prestandakrav.
Till exempel är den normala arbetsbelastningen för en e-handelswebbplats de transaktioner som den hanterar under de flesta dagar på ett år. Den högsta arbetsbelastningen på webbplatsen är de transaktioner som den betjänar under semesterperioder eller speciella försäljningsevenemang. Den högsta arbetsbelastningen upplevs vanligtvis under en begränsad period, men kan kräva att ditt program skalar två eller flera gånger sin normala åtgärd. Ta reda på kraven på 50 percentil, 90 percentil och 99 percentil. Den här informationen hjälper dig att filtrera bort avvikande värden i prestandakraven och du kan fokusera på att optimera för rätt värden.
Checklista för prestandakrav för program
| Prestandakrav | 50 percentil | 90 percentil | 99 percentil |
|---|---|---|---|
| Maximalt antal transaktioner per sekund | |||
| % läsåtgärder | |||
| % skrivåtgärder | |||
| % slumpmässiga åtgärder | |||
| % sekventiella åtgärder | |||
| Storlek på I/O-begäran | |||
| Genomsnittligt dataflöde | |||
| Maximalt dataflöde | |||
| Minsta svarstid | |||
| Genomsnittlig svarstid | |||
| Maximal processoranvändning | |||
| Genomsnittlig CPU | |||
| Högsta mängd minne | |||
| Genomsnittligt minne | |||
| Ködjup |
Kommentar
Överväg att skala dessa tal baserat på förväntad framtida tillväxt för ditt program. Det är en bra idé att planera för tillväxt i förväg eftersom det kan vara svårare att ändra infrastrukturen för att förbättra prestanda senare.
Om du har ett befintligt program och vill flytta till Premium Storage skapar du först föregående checklista för det befintliga programmet. Skapa sedan en prototyp av ditt program på Premium Storage och utforma programmet baserat på riktlinjer som beskrivs i Optimera programprestanda. I nästa artikel beskrivs de verktyg som du kan använda för att samla in prestandamätningarna.
Räknare för att mäta programprestandakrav
Det bästa sättet att mäta prestandakraven för ditt program är att använda PerfMonövervakningsverktyg 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 föregående avsnitt. Du måste samla in värdena för dessa räknare när programmet kör sina normala arbetsbelastningar, toppar och lågtimmarsarbetsbelastningar.
Räknarna PerfMon är tillgängliga för processor, minne och varje logisk disk och fysisk disk på servern. När du använder Premium Storage-diskar med en virtuell dator är de fysiska diskräknarna för varje premiumlagringsdisk och logiska diskräknare för varje volym som skapas på Premium Storage-diskarna. Du måste samla in 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. I annat fall refererar du till de logiska diskräknarna.
I Linux iostat genererar kommandot en cpu- och diskanvändningsrapport. Rapporten för diskanvändning innehåller 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 följande tabell beskrivs räknare för diskar, processorer och minne.
| Räknare | beskrivning | PerfMon | iostat |
|---|---|---|---|
| IOPS eller transaktioner per sekund | Antal I/O-begäranden som utfärdats till lagringsdisken/s | Diskläsningar/s Diskskrivningar/s |
Tps r/s w/s |
| Diskläsningar och diskskrivningar | % av läs- och skrivåtgärder som utförs på disken | Lästid för % disk % diskskrivningstid |
r/s w/s |
| Genomflöde | Mängd data som lästs från eller skrivits till disken/s | Diskläsningsbyte per sekund Diskskrivningsbyte per sekund |
kB_read/s kB_wrtn/s |
| Svarstid | Total tid för att slutföra en disk-I/O-begäran | Genomsnittlig diskse/läsning Genomsnittlig diskse/skrivning |
invänta svctm |
| I/O-storlek | Storleken på problem med I/O-begäran till lagringsdiskarna | Genomsnittlig diskbyte/läsning Genomsnittliga diskbyte/skrivning |
avgrq-sz |
| Ködjup | Antal utestående I/O-begäranden som väntar på att läsas från eller skrivas till lagringsdisken | Aktuell diskkölängd | avgqu-sz |
| Högsta mängd minne | Mängden minne som krävs för att köra programmet smidigt | % bekräftade byte som används | Använda vmstat |
| Maximal processoranvändning | Mängden cpu som krävs för att köra programmet smidigt | % processortid | %util |
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, multitrådning och ködjup. Du kan styra några av dessa faktorer med rattar 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 SQL Server kan du inte välja I/O-storlek och ködjup. SQL Server väljer de optimala värdena för I/O-storlek och ködjup 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 läser du checklistan för programkrav som du skapade för att identifiera hur mycket du behöver för att optimera programmets prestanda. Baserat på checklistan kan du avgöra vilka faktorer i det här avsnittet du behöver justera.
Om du vill se hur varje faktor påverkar programmets prestanda kör du benchmarking-verktyg i programkonfigurationen. Anvisningar för hur du kör vanliga benchmarking-verktyg på virtuella Windows- och Linux-datorer finns i benchmarking-artiklarna i slutet av det här dokumentet.
Optimera IOPS, dataflöde och svarstid snabbt
I följande tabell sammanfattas prestandafaktorer och de steg som krävs för att optimera IOPS, dataflöde och svarstid. Avsnitten i den här sammanfattningen beskriver varje faktor mer ingående.
Mer information om VM-storlekar och om IOPS, dataflöde och svarstid för varje typ av virtuell dator finns i Storlekar för virtuella datorer i Azure.
| Prestandafaktorer | IOPS | Dataflöde | Svarstid |
|---|---|---|---|
| Exempelscenario | Enterprise OLTP-program som kräver mycket höga transaktioner per sekund. | Program för lagring av företagsdata bearbetar stora mängder data. | Nästan realtidsprogram som kräver omedelbara svar på användarbegäranden, till exempel onlinespel. |
| Prestandafaktorer | |||
| I/O-storlek | Mindre I/O-storlek ger högre IOPS. | Större I/O-storlek ger högre dataflöde. | |
| Storlek på virtuell dator | Använd en VM-storlek som erbjuder IOPS som är större än ditt programkrav. | Använd en VM-storlek med en dataflödesgräns som är större än ditt programkrav. | Använd en VM-storlek som erbjuder skalningsgränser som är större än ditt programkrav. |
| Diskstorlek | Använd en diskstorlek som erbjuder IOPS som är större än ditt programkrav. | Använd en diskstorlek med en dataflödesgräns som är större än ditt programkrav. | Använd en diskstorlek som erbjuder skalningsgränser som är större än ditt programkrav. |
| Vm- och diskskalningsgränser | IOPS-gränsen för den valda VM-storleken ska vara större än den totala IOPS som drivs av de lagringsdiskar som är anslutna till den. | Dataflödesgränsen för den valda VM-storleken bör vara större än det totala dataflödet som drivs av de premiumlagringsdiskar som är anslutna till den. | Skalningsgränserna för den valda VM-storleken måste vara större än de totala skalningsgränserna för de anslutna Premium Storage-diskarna. |
| Diskcachelagring | Aktivera ReadOnly-cache på Premium Storage-diskar med läsintensiva åtgärder för att få högre läs-IOPS. | Aktivera ReadOnly-cache på Premium Storage-diskar med läsintensiva åtgärder för att få mycket låga svarstider för läsning. | |
| Disklistning | Använd flera diskar och strecka dem tillsammans för att få en kombinerad högre IOPS- och dataflödesgräns. Den kombinerade gränsen per virtuell dator bör vara högre än de kombinerade gränserna för anslutna Premium-diskar. | ||
| Randstorlek | Mindre randstorlek för slumpmässigt litet I/O-mönster som visas i OLTP-program. Använd till exempel en randstorlek på 64 KB för ett SQL Server OLTP-program. | Större randstorlek för sekventiellt stort I/O-mönster som visas i program för informationslager. Använd till exempel en randstorlek på 256 KB för ett SQL Server-informationslagerprogram. | |
| Flertrådskörning | Använd multitrådning för att skicka ett högre antal begäranden till Premium Storage för att leda till högre IOPS och dataflöde. På SQL Server anger du till exempel ett högt MAXDOP-värde för att allokera fler processorer till SQL Server. | ||
| Ködjup | Större ködjup ger högre IOPS. | Större ködjup ger högre dataflöde. | Mindre ködjup ger lägre svarstider. |
Typ av I/O-begäranden
En I/O-begäran är en enhet för indata/utdata som programmet utför. Att identifiera typen av I/O-begäranden, slumpmässiga eller sekventiella, läsa eller skriva, små eller stora, hjälper dig att fastställa prestandakraven för ditt program. Det är viktigt att förstå arten av I/O-begäranden för att fatta rätt beslut när du utformar din programinfrastruktur. I/Os måste distribueras jämnt för att uppnå bästa möjliga prestanda.
I/O-storlek är en av de viktigaste faktorerna. I/O-storleken är storleken på den begäran om indata/utdata som genereras av ditt program. I/O-storleken påverkar prestanda avsevärt, särskilt på den 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. Sql Server avgör till exempel den optimala I/O-storleken och ger inte användarna några rattar för att ändra den. Oracle tillhandahåller å andra sidan en parameter som heter DB_BLOCK_SIZE, som du kan använda för att konfigurera I/O-begärandestorleken för databasen.
Om du använder ett program, som inte tillåter att du ändrar I/O-storlek, använder du riktlinjerna i den här artikeln för att optimera den prestanda-KPI som är mest relevant för ditt program. Till exempel:
- Ett OLTP-program genererar miljontals små och slumpmässiga I/O-begäranden. Om du vill 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. Om du vill hantera dessa typer av I/O-begäranden måste du utforma programinfrastrukturen för att få 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.
Överväg ett program som använder en P30-disk. Den maximala IOPS och dataflöde/bandbredd som en P30-disk kan uppnå är 5 000 IOPS respektive 200 MB/s. Om ditt program kräver maximal IOPS från P30-disken och du använder en mindre I/O-storlek, till exempel 8 kB, är den resulterande bandbredden 40 MB/s. Om ditt program kräver maximalt dataflöde/bandbredd från en P30-disk och du använder en större I/O-storlek, till exempel 1 024 kB, är den resulterande IOPS mindre, till exempel 200 IOPS.
Justera I/O-storleken så att den uppfyller både programmets krav på 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.
| Programkrav | I/O-storlek | IOPS | Dataflöde/bandbredd |
|---|---|---|---|
| Maximalt antal IOPS | 8 kB | 5 000 | 40 MB/s |
| Maximalt dataflöde | 1 024 KB | 200 | 200 MB/sek. |
| Maximalt dataflöde + hög IOPS | 64 KB | 3,200 | 200 MB/sek. |
| Maximalt IOPS + högt dataflöde | 32 kB | 5 000 | 160 MB/s |
Om du vill få IOPS och bandbredd högre än det maximala värdet för en enda premiumlagringsdisk använder du flera premiumdiskar som är randiga tillsammans. Till exempel strecka två P30-diskar för att få en kombinerad IOPS på 10 000 IOPS eller ett kombinerat dataflöde på 400 MB/s. Som beskrivs i nästa avsnitt måste du använda en VM-storlek som stöder det kombinerade disk-IOPS och dataflödet.
Kommentar
När du ökar antingen IOPS eller dataflödet ökar även det andra. Kontrollera att du inte når dataflödet eller IOPS-gränserna för disken eller den virtuella datorn när du ökar något av dem.
Om du vill se effekterna av I/O-storlek på programmets prestanda kan du köra benchmarking-verktyg på din virtuella dator 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-artiklarna i slutet av det här dokumentet.
Vm-storlekar 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 storskaliga VM-storlekar 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 SSD (Solid State Drive) för den lokala disken. Exempel på storskaliga virtuella datorer som stöder premiumlagring är virtuella datorer i DS- och GS-serien.
Storskaliga virtuella datorer finns i olika storlekar med ett annat antal processorkärnor, minne, operativsystem och tillfällig diskstorlek. Varje VM-storlek har också ett maximalt antal datadiskar som du kan ansluta till den virtuella datorn. Den valda vm-storleken påverkar hur mycket bearbetning, minne och lagringskapacitet som är tillgängliga för ditt program. Det påverkar även beräknings- och lagringskostnaden. Följande specifikationer är till exempel för den största VM-storleken i en DS-serie och en GS-serie.
| Storlek på virtuell dator | Processorkärnor | Minne | VM-diskstorlekar | Maximalt antal datadiskar | Cachestorlek | IOPS | I/O-gränser för bandbreddscache |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | OS = 1 023 GB Lokal SSD = 224 GB |
32 | 576 GB | 50 000 IOPS 512 MB/s |
4 000 IOPS och 33 MB/s |
| Standard_GS5 | 32 | 448 GB | OS = 1 023 GB Lokal SSD = 896 GB |
64 | 4224 GB | 80 000 IOPS 2 000 MB/s |
5 000 IOPS och 50 MB/s |
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 skala efter dina önskade programprestandakrav. Ta även 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 disk är olika och oberoende av varandra. Kontrollera att programmet kör IOPS inom gränserna för den virtuella datorn och de premiumdiskar som är anslutna till den. Annars kan programprestandan begränsas.
Anta till exempel att ett programkrav är högst 4 000 IOPS. För att uppnå den här nivån 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. För att förhindra den här situationen väljer du en virtuell dator och en diskstorlek som båda uppfyller programkraven.
Kostnad för drift
I många fall är det möjligt att den totala kostnaden för att använda Premium Storage är lägre än att använda standardlagring.
Anta till exempel att ett program kräver 16 000 IOPS. För att uppnå den här prestandan behöver du en Standard_D14 virtuell Azure IaaS-dator, vilket kan ge en maximal IOPS på 16 000 med 32 standardlagringsdiskar på 1 TB. Varje 1 TB standardlagringsdisk kan uppnå högst 500 IOPS.
- Den uppskattade kostnaden för den här virtuella datorn per månad är 1 570 USD.
- Den månatliga kostnaden för 32 standardlagringsdiskar är 1 638 USD.
- Den uppskattade totala månadskostnaden är 3 208 USD.
Om du var värd för samma program på Premium Storage behöver du en mindre VM-storlek och färre premiumlagringsdiskar, vilket minskar den totala kostnaden. En Standard_DS13 virtuell dator kan uppfylla IOPS-kravet på 16 000 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. Totalt sett kan den här konfigurationen 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.
- Den månatliga kostnaden för fyra P30 Premium-lagringsdiskar är 544,34 USD.
- Den uppskattade totala månadskostnaden är 1 544 USD.
I följande tabell sammanfattas kostnadsuppdelningen för det här scenariot för standardlagring och premiumlagring.
| Månadskostnad | Standard | Premium |
|---|---|---|
| Kostnad för virtuell dator per månad | 1 570,58 USD (Standard_D14) | $1,003.66 (Standard_DS13) |
| Kostnad för diskar per månad | 1 638,40 USD (32 x 1 TB diskar) | $544.34 (4 x P30 diskar) |
| Total kostnad per månad | $3,208.98 | $1,544.34 |
Linux-distributioner
Med 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 godkänts i Azure.
Olika distributioner passar bättre för olika typer av arbetsbelastningar. Du ser olika prestandanivåer beroende på vilken distribution som din arbetsbelastning körs på. Testa Linux-distributionerna med ditt program och välj det som fungerar bäst.
När du kör Linux med Premium Storage kontrollerar du de senaste uppdateringarna om nödvändiga drivrutiner för att säkerställa höga prestanda.
Premium Storage-diskstorlekar
Premium Storage erbjuder olika storlekar så att du kan välja en som passar dina behov bäst. Varje diskstorlek har en annan skalningsgräns för IOPS, bandbredd och lagring. Välj rätt premiumlagringsdiskstorlek beroende på programkraven och den storskaliga VM-storleken. I följande tabell visas diskstorlekarna och deras funktioner. P4-, P6-, P15-, P60-, P70- och P80-storlekar stöds för närvarande endast för hanterade diskar.
| Premium SSD-storlekar | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | p60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Diskstorlek i GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2 048 | 4,096 | 8,192 | 16,384 | 32 767 |
| Basetablerad IOPS per disk | 120 | 120 | 120 | 120 | 240 | 500 | 1 100 | 2 300 | 5 000 | 7 500 | 7 500 | 16 000 | 18 000 | 20 000 |
| **Utökad etablerad IOPS per disk | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | 8,000 | 16 000 | 20 000 | 20 000 | 20 000 | 20 000 |
| Grundläggande etablerat dataflöde per disk | 25 MB/s | 25 MB/s | 25 MB/s | 25 MB/s | 50 MB/s | 100 MB/s | 125 MB/s | 150 MB/s | 200 MB/s | 250 MB/s | 250 MB/s | 500 MB/s | 750 MB/s | 900 MB/s |
| **Utökat etablerat dataflöde per disk | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | Saknas | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
| Maximal burst-IOPS per disk | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 3 500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| Maximalt dataflöde för burst per disk | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 1 000 MB/s* | 1 000 MB/s* | 1 000 MB/s* | 1 000 MB/s* | 1 000 MB/s* | 1 000 MB/s* |
| Maximal varaktighet för burst | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Obegränsad* | Obegränsad* | Obegränsad* | Obegränsad* | Obegränsad* | Obegränsad* |
| Berättigad till reservation | Nej | Nej | Nej | Nej | Nej | Nej | Nej | Nej | Ja, upp till ett år | Ja, upp till ett år | Ja, upp till ett år | Ja, upp till ett år | Ja, upp till ett år | Ja, upp till ett år |
*Gäller endast för diskar med burst-aktivering på begäran.
** Gäller endast för diskar med prestanda plus (förhandsversion) aktiverat.
Hur många diskar du väljer beror på vilken diskstorlek som valts. Du kan använda en enda P50-disk eller flera P10-diskar för att uppfylla dina programkrav. Ta hänsyn till de överväganden som anges här när du gör valet.
Skalningsgränser (IOPS och dataflöde)
IOPS- och dataflödesgränserna för varje premiumdiskstorlek skiljer sig och är 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 dataflöde och du använder en virtuell DS4-dator med en enda P30-disk kan den virtuella DS4-datorn ge upp till 256 MB/sek dataflöde. En enskild P30-disk har dock en dataflödesgräns på 200 MB/s. Programmet är därför begränsat till 200 MB/s på grund av diskgränsen. Du kan lösa den här gränsen genom att etablera mer än en datadisk till den virtuella datorn eller ändra storlek på diskarna till P40 eller P50.
Kommentar
Läsningar som hanteras av cachen ingår inte i diskens IOPS och dataflöde, så de omfattas inte av diskgränser. Cacheminnet har sin separata IOPS- och dataflödesgräns per virtuell dator.
Till exempel är dina läsningar och skrivningar till en början 60 MB/s respektive 40 MB/s. Med tiden värms cachen upp och hanterar mer och mer av läsningarna från cacheminnet. Sedan kan du få högre skrivdataflöde från disken.
Antal diskar
Fastställa hur många diskar du behöver genom att utvärdera programkraven. Varje VM-storlek har också en gräns för antalet diskar som du kan ansluta till den virtuella datorn. Vanligtvis är den här mängden dubbelt så många kärnor. Se till att den vm-storlek du väljer kan stödja det antal diskar som behövs.
Kom ihåg att premiumlagringsdiskarna har högre prestanda jämfört med standardlagringsdiskar. Om du migrerar ditt program från en virtuell Azure IaaS-dator med standardlagring till premiumlagring behöver du förmodligen färre premiumdiskar för att uppnå samma eller högre prestanda för ditt program.
Diskcachelagring
Storskaliga virtuella datorer som använder Premium Storage har en cachelagringsteknik med flera nivåer som kallas BlobCache. BlobCache använder en kombination av värd-RAM och lokal SSD för cachelagring. Den här cachen är tillgänglig för premiumlagringsbeständiga diskar och lokala diskar för virtuella datorer. Som standard är den här cacheinställningen inställd på ReadWrite för OS-diskar och ReadOnly för datadiskar som finns på Premium Storage. Med diskcachelagring aktiverat på premiumlagringsdiskarna kan de storskaliga virtuella datorerna uppnå extremt höga prestandanivåer som överskrider den underliggande diskprestandan.
Varning
Diskcachelagring stöds inte för diskar 4 TiB och större. Om flera diskar är anslutna till den virtuella datorn har varje disk som är mindre än 4 TiB stöd för cachelagring.
När du ändrar cacheinställningen för en Azure-disk så frånkopplas och återansluts måldisken. Om det är operativsystemdisken startas den virtuella datorn om. Stoppa alla program och tjänster som kan påverkas av den här störningen innan du ändrar diskcacheinställningen. Om du inte följer dessa rekommendationer kan det leda till att data skadas.
Mer information om hur BlobCache fungerar finns i blogginlägget i Azure Premium Storage .
Det är viktigt att aktivera cachelagring på rätt uppsättning diskar. Om du ska aktivera diskcachelagring på en Premium-disk eller inte beror på arbetsbelastningsmönstret som disken hanterar. I följande tabell visas standardinställningarna för cache för operativsystem och datadiskar.
| Disktyp | Standardinställning för cache |
|---|---|
| OS-disk | Skriv upp |
| Datadisk | Skrivskyddat |
Vi rekommenderar följande inställningar för diskcache för datadiskar.
| Inställning för diskcachelagring | Rekommendation för när du ska använda den här inställningen |
|---|---|
| Ingen | Konfigurera värdcache som Ingen för skrivskyddade och skrivintensiva diskar. |
| Skrivskyddat | Konfigurera värdcache som ReadOnly för skrivskyddade diskar och skrivskyddade diskar. |
| Skriv upp | Konfigurera endast värdcache som ReadWrite om programmet hanterar skrivning av cachelagrade data till beständiga diskar vid behov. |
Skrivskyddat
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 av två skäl:
- Läsningar som utförs från cacheminnet, som finns på den virtuella datorns minne och lokala SSD, är snabbare än läsningar från datadisken, som finns i Azure Blob Storage.
- Premium Storage räknar inte de läsningar som hanteras från cachen mot diskens IOPS och dataflöde. Därför kan ditt program uppnå högre total IOPS och dataflöde.
Skriv upp
Som standard har OS-diskarna ReadWrite-cachelagring 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 cacheminne till beständiga diskar. SQL Server hanterar till exempel att skriva cachelagrade data till de beständiga lagringsdiskarna på egen hand. Om du använder ReadWrite-cacheminnet med ett program som inte hanterar kvarstående 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ätter den här inställningen internt och anger den till ReadOnly.
Du kan till exempel tillämpa dessa riktlinjer på SQL Server som körs på Premium Storage genom att följa dessa steg:
- Konfigurera ReadOnly-cachen på premiumlagringsdiskar som är värdar för datafiler.
- De snabba läsningarna från cachen sänker SQL Server-frågetiden eftersom datasidor hämtas snabbare från cacheminnet jämfört med direkt från datadiskarna.
- Att hantera läsningar från cache innebär att det finns mer dataflöde tillgängligt från Premium-datadiskar. SQL Server kan använda det här extra dataflödet för att hämta fler datasidor och andra åtgärder som säkerhetskopiering/återställning, batchinläsningar och återskapade index.
- Konfigurera Ingen cache på premiumlagringsdiskar som är värdar för loggfilerna.
- Loggfiler har främst skrivintensiva åtgärder, så de drar inte nytta av ReadOnly-cachen .
Optimera prestanda på virtuella Linux-datorer
För alla Premium SSD:er eller Ultra Disks kanske du kan inaktivera hinder 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 Cachelagring av Azure-diskar är inställt på ReadOnly eller None kan du inaktivera hinder. Men om cachelagring är inställt på ReadWrite bör hinder förbli aktiverade för att säkerställa skrivbarhet. Hinder är vanligtvis aktiverade som standard, men du kan inaktivera hinder med någon av följande metoder beroende på filsystemtypen:
- reiserFS: Använd alternativet barrier=none mount för att inaktivera hinder. Använd barrier=flush för att uttryckligen aktivera hinder.
- ext3/ext4: Använd monteringsalternativet barrier=0 för att inaktivera hinder. Använd barrier=1 för att uttryckligen aktivera hinder.
- XFS: Använd nobarrier-monteringsalternativet för att inaktivera hinder. Använd barriär för att uttryckligen aktivera hinder. Från och med version 4.10 av Huvudlinjens Linux-kernel garanterar designen av XFS-filsystemet alltid hållbarhet. Inaktivering av hinder har ingen effekt och nobarrier-alternativet är inaktuellt. Vissa Linux-distributioner kan dock ha backporterat ändringarna till en distributionsversion med en tidigare kernelversion. Kontakta distributionsleverantören för att få statusen i den distribution och version som du kör.
Disklistning
När en storskalig virtuell dator är ansluten med flera beständiga premiumlagringsdiskar kan diskarna skalas ihop för att aggregera sina IOPS, bandbredd och lagringskapacitet.
I Windows kan du använda Lagringsutrymmen för att strecka diskar tillsammans. Du måste konfigurera en kolumn för varje disk i en pool. Annars kan den totala prestandan för randiga volymer vara lägre än förväntat på grund av ojämn fördelning av trafiken mellan diskarna.
Med hjälp av användargränssnittet för Serverhanteraren kan du ange det totala antalet kolumner upp till 8 för en randig volym. När du ansluter fler än åtta diskar använder du PowerShell för att skapa volymen. Genom att använda PowerShell kan du ange antalet kolumner som är lika med antalet diskar. Om det till exempel finns 16 diskar i en enskild stripe-uppsättning anger du 16 kolumner i parametern NumberOfColumns för PowerShell-cmdleten New-VirtualDisk .
I Linux använder du MDADM-verktyget för att strecka diskar tillsammans. Anvisningar om hur du gör stripe-diskar i Linux finns i Konfigurera Software RAID på Linux.
Randstorlek
En viktig konfiguration i disklistning är randstorleken. Randstorleken eller blockstorleken är det minsta datasegmentet som ett program kan hantera på en randig volym. Den randstorlek som du konfigurerar beror på typen av program och dess begärandemönster. Om du väljer fel randstorlek kan det leda till I/O-feljustering, vilket leder till försämrad prestanda för ditt program.
Om till exempel en I/O-begäran som genereras av ditt program är större än diskrandstorleken skriver lagringssystemet den över randenhetsgränser på mer än en disk. När det är dags att komma åt dessa data måste den söka över mer ä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 I/O-begärandestorleken är mindre än randstorleken, och om den är slumpmässig till sin natur, kan I/O-begäranden läggas till på samma disk, vilket orsakar en flaskhals och i slutändan försämrar I/O-prestandan.
Beroende på vilken typ av arbetsbelastning programmet körs väljer du en lämplig randstorlek. För slumpmässiga små I/O-begäranden använder du en mindre randstorlek. För stora sekventiella I/O-begäranden använder du en större randstorlek. Ta reda på rekommendationerna för stripe-storlek för programmet som du kommer att köra på Premium Storage. För SQL Server konfigurerar du en randstorlek på 64 KB för OLTP-arbetsbelastningar och 256 KB för datalagerarbetsbelastningar. Mer information finns i Metodtips för prestanda för SQL Server på virtuella Azure-datorer.
Kommentar
Du kan strecka ihop högst 32 premiumlagringsdiskar på en virtuell dator i DS-serien och 64 premiumlagringsdiskar på en virtuell dator i GS-serien.
Flertrådskörning
Azure har utformat premiumlagringsplattformen så att den är massivt parallell. Därför får ett flertrådat program högre prestanda än ett entrådat program. Ett flertrådat program delar upp sina uppgifter i flera trådar och ökar effektiviteten i körningen genom att använda den virtuella datorn och diskresurserna maximalt.
Om ditt program till exempel körs på en virtuell dator med en enda 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 åstadkomma 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 program utanför hyllan implementerar enkel trådning eller multitrådning. SQL Server kan till exempel hantera flera processorer och flera kärnor. SQL Server bestämmer dock under vilka villkor den använder 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 multitrådning. För en fråga som omfattar anslutning av stora tabeller och sortering av data innan du återgår till användaren använder SQL Server troligen flera trådar. En användare kan inte styra om SQL Server kör en fråga med hjälp av en enda tråd eller flera trådar.
Det finns konfigurationsinställningar som du kan ändra för att påverka multitrådning eller parallell bearbetning av ett program. För SQL Server är det till exempel konfigurationen max degree of parallelism . Med den här inställningen med namnet MAXDOP kan du konfigurera det maximala antalet processorer som SQL Server kan använda vid parallell bearbetning. Du kan konfigurera MAXDOP för enskilda frågor eller indexåtgärder. Den här funktionen är fördelaktig när du vill balansera resurser i systemet för ett prestandakritiskt program.
Anta till exempel att ditt program som använder SQL Server kör en stor fråga och en indexåtgärd samtidigt. Anta att du ville att indexåtgärden skulle vara mer högpresterande jämfört med den stora frågan. I så fall kan du ange att MAXDOP-värdet för indexåtgärden ska vara högre än MAXDOP-värdet för frågan. På så sätt har SQL Server fler processorer än den kan använda för indexåtgärden jämfört med antalet processorer som den kan ägna åt den stora frågan. Kom ihåg att du inte styr antalet trådar som SQL Server använder för varje åtgärd. Du kan styra det maximala antalet processorer som är dedikerade för multitrådning.
Läs mer om parallellitetsgrader i SQL Server. Ta reda på hur sådana inställningar påverkar multitrådning i ditt program och deras konfigurationer för att optimera prestanda.
Ködjup
Ködjupet eller 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 som programmet kan rada upp, vilket lagringsdiskar bearbetar. Den påverkar alla tre programprestandaindikatorer som beskrivs i den här artikeln: IOPS, dataflöde och svarstid.
Ködjup och multitrådning är nära relaterade. Värdet för ködjup anger hur mycket multitrådning som kan uppnås av programmet. Om ködjupet är stort kan programmet köra fler åtgärder samtidigt, med andra ord mer multitrådning. Om ködjupet är litet, även om programmet är flertrådat, har det inte tillräckligt med begäranden uppradade för samtidig körning.
Vanligtvis tillåter inte program utanför hyllan att du ändrar ködjupet, för om det är felaktigt inställt gör det mer skada än nytta. Program anger rätt värde för ködjup för att få optimala prestanda. Det är 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 benchmarkingverktyg på systemet.
Vissa program tillhandahåller inställningar för att påverka ködjupet. Till exempel förklaras MAXDOP-inställningen i SQL Server i föregående avsnitt. MAXDOP är ett sätt att påverka ködjup och multitrådning, även om det inte direkt ändrar ködjupvärdet 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/Os. I slutändan kan programmet uppnå högre IOPS. Eftersom programmet bearbetar fler begäranden ökar även programmets totala dataflöde.
Vanligtvis kan ett program uppnå maximalt dataflöde med 8 till 16+ utestående I/Os per ansluten disk. Om ett ködjup är ett, skickar programmet inte tillräckligt med I/Os till systemet, och det bearbetar en mindre mängd under en viss period. Med andra ord mindre dataflöde.
I SQL Server anger du till exempel MAXDOP-värdet för en fråga för att 4 informera SQL Server om att den kan använda upp till fyra kärnor för att köra frågan. SQL Server avgör det bästa ködjupvärdet och antalet kärnor för frågekörningen.
Optimalt ködjup
Ett 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ögt IOPS. Om programmet inte har beständiga diskar med tillräcklig etablerad IOPS kan ett mycket högt ködjupvärde påverka programfördröjningen 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 millisekunder är ködjupet som krävs för att uppnå 5 000 IOPS QD = 5 000 x 0,001 = 5.
Ködjup för randig volym
För en randig volym behåller du ett tillräckligt stort ködjup så att varje disk har ett maximalt ködjup individuellt. Tänk dig till exempel ett program som skickar ett ködjup på 2 och det finns fyra diskar i remsan. De två I/O-begäranden går till två diskar och de återstående två diskarna är inaktiva. Konfigurera därför ködjupet så att alla diskar kan vara upptagna. Följande formel visar hur du fastställer ködjupet för randiga volymer.
Begränsning
Premium Storage etablerar ett angivet antal IOPS och dataflöde beroende på vm-storlekar och diskstorlekar som du väljer. När ditt program försöker köra IOPS eller dataflöde över dessa gränser för vad den virtuella datorn eller disken kan hantera begränsar Premium Storage det. Resultatet är försämrad prestanda i ditt program, vilket kan innebära högre svarstid, lägre dataflöde eller lägre IOPS.
Om premiumlagringen 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 alltid etablera tillräckligt med resurser för ditt program. Ta hänsyn till vad vi diskuterade i föregående avsnitt om VM-storlekar och diskstorlekar. 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 jämföra disken kan du läsa följande artiklar:
- För Linux: Benchmark-prestanda för ditt program på Azure Disk Storage
- För Windows: Benchmarka 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 artiklarna om metodtips för prestanda för SQL Server: