Azure Premium Storage: ontwerp voor hoge prestaties

Van toepassing op: ✔️ Linux-VM's ✔️ Windows-VM's ✔️ Flexibele schaalsets ✔️ Uniforme schaalsets

Dit artikel bevat richtlijnen voor het bouwen van toepassingen met hoge prestaties met behulp van Azure Premium Storage. U kunt de instructies in dit document gebruiken in combinatie met aanbevolen procedures voor prestaties die van toepassing zijn op technologieën die door uw toepassing worden gebruikt. Ter illustratie van de richtlijnen hebben we in dit document SQL Server gebruikt die op Premium Storage worden uitgevoerd.

Hoewel we in dit artikel prestatiescenario's voor de opslaglaag aanpakken, moet u de toepassingslaag optimaliseren. Als u bijvoorbeeld een SharePoint-farm host in Azure Premium Storage, kunt u de SQL Server voorbeelden uit dit artikel gebruiken om de databaseserver te optimaliseren. Daarnaast optimaliseert u de webserver en toepassingsserver van de SharePoint-farm voor de beste prestaties.

Dit artikel helpt bij het beantwoorden van de volgende veelgestelde vragen over het optimaliseren van de prestaties van toepassingen in Azure Premium Storage,

• Hoe kunt u de prestaties van uw toepassing meten?
• Waarom ziet u geen verwachte hoge prestaties?
• Welke factoren zijn van invloed op de prestaties van uw toepassing op Premium Storage?
• Hoe beïnvloeden deze factoren de prestaties van uw toepassing op Premium Storage?
• Hoe kunt u optimaliseren voor IOPS, bandbreedte en latentie?

We hebben deze richtlijnen specifiek voor Premium Storage gegeven, omdat workloads die worden uitgevoerd op Premium Storage zeer prestatiegevoelig zijn. We hebben waar nodig voorbeelden gegeven. U kunt enkele van deze richtlijnen ook toepassen op toepassingen die worden uitgevoerd op IaaS-VM's met Standard Storage-schijven.

Notitie

Soms is wat een probleem met de schijfprestaties lijkt te zijn, eigenlijk een netwerkknelpunt. In deze situaties moet u de netwerkprestaties optimaliseren.

Als u uw schijf wilt benchmarken, raadpleegt u onze artikelen over het benchmarken van een schijf:

• Voor Linux: benchmark voor uw toepassing in Azure Disk Storage
• Voor Windows: Benchmarking van een schijf.

Als uw VM versnelde netwerken ondersteunt, moet u ervoor zorgen dat deze is ingeschakeld. Als deze niet is ingeschakeld, kunt u deze inschakelen op reeds geïmplementeerde VM's in Zowel Windows als Linux.

Lees voordat u begint, als u niet eerder met Premium Storage hebt, eerst de optie Selecteer een Azure-schijftype voor IaaS-VM's en schaalbaarheidsdoelen voor blobopslagaccounts op de Premium-pagina.

Prestatie-indicatoren voor toepassingen

We beoordelen of een toepassing goed presteert of niet met behulp van prestatie-indicatoren, zoals, hoe snel een toepassing een gebruikersaanvraag verwerkt, hoeveel gegevens een toepassing per aanvraag verwerkt, hoeveel aanvragen een toepassing verwerkt in een bepaalde periode, hoe lang een gebruiker moet wachten om een antwoord te krijgen na het indienen van de aanvraag. De technische termen voor deze prestatie-indicatoren zijn IOPS, doorvoer of bandbreedte en latentie.

In deze sectie bespreken we de algemene prestatie-indicatoren in de context van Premium Storage. In de volgende sectie, Toepassingsvereisten verzamelen, leert u hoe u deze prestatie-indicatoren voor uw toepassing kunt meten. Verderop in Toepassingsprestaties optimaliseren krijgt u meer informatie over de factoren die van invloed zijn op deze prestatie-indicatoren en aanbevelingen om deze te optimaliseren.

IOPS

IOPS, of Invoer-/uitvoerbewerkingen per seconde, is het aantal aanvragen dat uw toepassing in één seconde naar de opslagschijven verzendt. Een invoer-/uitvoerbewerking kan lezen of schrijven, opeenvolgend of willekeurig zijn. OLTP-toepassingen (Online Transaction Processing), zoals een online retailwebsite, moeten veel gelijktijdige gebruikersaanvragen onmiddellijk verwerken. De gebruikersaanvragen zijn het invoegen en bijwerken van intensieve databasetransacties, die de toepassing snel moet verwerken. Daarom vereisen OLTP-toepassingen een zeer hoge IOPS. Dergelijke toepassingen verwerken miljoenen kleine en willekeurige IO-aanvragen. Als u een dergelijke toepassing hebt, moet u de toepassingsinfrastructuur ontwerpen om te optimaliseren voor IOPS. In Toepassingsprestaties optimaliseren bespreken we in detail alle factoren waarmee u rekening moet houden om een hoge IOPS te krijgen.

Wanneer u een premium opslagschijf koppelt aan uw schaalbare VM, biedt Azure u een gegarandeerd aantal IOPS op basis van de schijfspecificatie. Een P50-schijf is bijvoorbeeld goed voor 7500 IOPS. Voor elke schaalbare VM geldt ook een specifieke IOPS-limiet, afhankelijk van de grootte van de VM. Een standard GS5-VM heeft bijvoorbeeld een limiet van 80.000 IOPS.

Doorvoer

Doorvoer of bandbreedte is de hoeveelheid gegevens die uw toepassing in een opgegeven interval naar de opslagschijven verzendt. Als uw toepassing invoer-/uitvoerbewerkingen uitvoert met grote IO-eenheden, is een hoge doorvoer vereist. Datawarehouse-toepassingen hebben de neiging om scanintensieve bewerkingen uit te voeren die toegang hebben tot grote delen van gegevens tegelijk en vaak bulkbewerkingen uitvoeren. Met andere woorden, dergelijke toepassingen vereisen een hogere doorvoer. Als u een dergelijke toepassing hebt, moet u de infrastructuur ervan ontwerpen om de doorvoer te optimaliseren. In de volgende sectie bespreken we in detail de factoren die u moet afstemmen om dit te bereiken.

Wanneer u een Premium Storage-schijf koppelt aan een grootschalige VM, richt Azure de doorvoer in volgens die schijfspecificatie. Een P50-schijf biedt bijvoorbeeld een schijfdoorvoer van250 MB per seconde. Voor elke schaalbare VM geldt ook een specifieke doorvoerlimiet, afhankelijk van de grootte van de VM. Een standaard GS5 VM heeft bijvoorbeeld een maximale doorvoer van 2000 MB per seconde.

Er is een relatie tussen doorvoer en IOPS, zoals wordt weergegeven in de onderstaande formule.

Daarom is het belangrijk om de optimale doorvoer- en IOPS-waarden te bepalen die uw toepassing vereist. Als u de ene probeert te optimaliseren, wordt ook de andere beïnvloed. In Toepassingsprestaties optimaliseren bespreken we meer informatie over het optimaliseren van IOPS en doorvoer.

Latentie

Latentie is de tijd die een toepassing nodig heeft om één aanvraag te ontvangen, deze naar de opslagschijven te verzenden en het antwoord naar de client te verzenden. Dit is een kritieke meting van de prestaties van een toepassing, naast IOPS en doorvoer. De latentie van een Premium Storage-schijf is de tijd die nodig is om de informatie voor een aanvraag op te halen en terug te geven aan uw toepassing. Premium Storage biedt consistente lage latenties. Premium-schijven zijn ontworpen om latentie van milliseconden te bieden voor de meeste IO-bewerkingen. Als u ReadOnly-hostcaching inschakelt op Premium Storage-schijven, kunt u een veel lagere leeslatentie krijgen. We bespreken Schijfcaching in meer detail in Schijfcaching.

Wanneer u uw toepassing optimaliseert om een hogere IOPS en doorvoer te krijgen, heeft dit invloed op de latentie van uw toepassing. Na het afstemmen van de prestaties van de toepassing, evalueert u altijd de latentie van de toepassing om onverwacht gedrag met hoge latentie te voorkomen.

De volgende besturingsvlakbewerkingen op Managed Disks kunnen verplaatsing van de schijf van de ene opslaglocatie naar een andere omvatten. Dit wordt georganiseerd via het kopiëren op de achtergrond van gegevens. Dit kan enkele uren duren, meestal minder dan 24 uur, afhankelijk van de hoeveelheid gegevens op de schijven. Gedurende die tijd kan uw toepassing een hogere leeslatentie ervaren dan normaal, omdat sommige leesbewerkingen kunnen worden omgeleid naar de oorspronkelijke locatie en het langer kan duren om te voltooien. Er is geen invloed op de schrijflatentie tijdens deze periode.

• Werk het opslagtype bij.
• Koppel een schijf los en koppel deze van de ene VM aan een andere.
• Maak een beheerde schijf op basis van een VHD.
• Een beheerde schijf maken op basis van een momentopname.
• Niet-beheerde schijven converteren naar beheerde schijven.

Controlelijst voor prestatietoepassingen voor schijven

De eerste stap bij het ontwerpen van toepassingen met hoge prestaties die worden uitgevoerd op Azure Premium Storage is het begrijpen van de prestatievereisten van uw toepassing. Nadat u de prestatievereisten hebt verzameld, kunt u uw toepassing optimaliseren om de meest optimale prestaties te bereiken.

In de vorige sectie hebben we de algemene prestatie-indicatoren, IOPS, doorvoer en latentie uitgelegd. U moet bepalen welke van deze prestatie-indicatoren essentieel zijn voor uw toepassing om de gewenste gebruikerservaring te bieden. Hoge IOPS zijn bijvoorbeeld het belangrijkst voor OLTP-toepassingen die miljoenen transacties in een seconde verwerken. Hoge doorvoer is echter essentieel voor Data Warehouse toepassingen die in een seconde grote hoeveelheden gegevens verwerken. Extreem lage latentie is van cruciaal belang voor realtime toepassingen zoals websites voor livevideostreaming.

Meet vervolgens de maximale prestatievereisten van uw toepassing gedurende de levensduur. Gebruik de voorbeeldcontrolelijst hieronder als begin. Noteer de maximale prestatievereisten tijdens normale workloadperioden, piekuren en buiten kantooruren. Door vereisten voor alle workloadsniveaus te identificeren, kunt u de algehele prestatievereiste van uw toepassing bepalen. De normale werkbelasting van een e-commercewebsite bestaat bijvoorbeeld uit de transacties die deze gedurende de meeste dagen in een jaar bedient. De piekbelasting van de website is de transacties die tijdens de feestdagen of speciale verkoopevenementen worden uitgevoerd. De piekworkload treedt meestal op voor een beperkte periode, maar kan vereisen dat uw toepassing twee of meer keer de normale werking schalen. Ontdek de vereisten voor 50 percentiel, 90 percentiel en 99 percentiel. Dit helpt bij het uitfilteren van uitschieters in de prestatievereisten en u kunt uw inspanningen richten op het optimaliseren van de juiste waarden.

Controlelijst voor toepassingsprestaties

Prestatievereisten	50 Percentiel	90 Percentiel	99 Percentiel
Met maximaal Transacties per seconde
% leesbewerkingen
% schrijfbewerkingen
% willekeurige bewerkingen
% sequentiële bewerkingen
IO-aanvraaggrootte
Gemiddelde doorvoer
Met maximaal Doorvoer
Min. Latentie
Gemiddelde latentie
Met maximaal CPU
Gemiddelde CPU
Met maximaal Geheugen
Gemiddeld geheugen
Wachtrijdiepte

Notitie

U kunt overwegen deze aantallen te schalen op basis van de verwachte toekomstige groei van uw toepassing. Het is een goed idee om de groei van tevoren te plannen, omdat het later moeilijker kan zijn om de infrastructuur te wijzigen om de prestaties te verbeteren.

Als u een bestaande toepassing hebt en wilt overstappen op Premium Storage, bouwt u eerst de controlelijst hierboven voor de bestaande toepassing. Bouw vervolgens een prototype van uw toepassing op Premium Storage en ontwerp de toepassing op basis van richtlijnen die worden beschreven in Toepassingsprestaties optimaliseren. In het volgende artikel worden de hulpprogramma's beschreven die u kunt gebruiken om de prestatiemetingen te verzamelen.

Prestatiemeteritems voor het meten van de prestatievereisten van toepassingen

De beste manier om de prestatievereisten van uw toepassing te meten, is door hulpprogramma's voor prestatiebewaking te gebruiken die worden geleverd door het besturingssysteem van de server. U kunt PerfMon voor Windows en iostat voor Linux gebruiken. Met deze hulpprogramma's worden tellers vastgelegd die overeenkomen met elke meting die in de bovenstaande sectie wordt uitgelegd. U moet de waarden van deze tellers vastleggen wanneer uw toepassing de normale, piek- en werkbelastingen buiten kantooruren uitvoert.

De PerfMon-tellers zijn beschikbaar voor processor, geheugen en elke logische schijf en fysieke schijf van uw server. Wanneer u Premium Storage-schijven gebruikt met een VM, zijn de fysieke schijfitems voor elke Premium-opslagschijf en zijn de logische schijftellers voor elk volume dat op de Premium Storage-schijven wordt gemaakt. U moet de waarden vastleggen voor de schijven die als host fungeren voor uw toepassingsworkload. Als er een een-op-een-toewijzing is tussen logische en fysieke schijven, kunt u verwijzen naar fysieke schijftellers; anders verwijzen naar de logische schijftellers. In Linux genereert de iostat-opdracht een rapport over CPU- en schijfgebruik. Het rapport schijfgebruik bevat statistieken per fysiek apparaat of partitie. Als u een databaseserver hebt met de bijbehorende gegevens en logboeken op afzonderlijke schijven, verzamelt u deze gegevens voor beide schijven. In de onderstaande tabel worden de tellers voor schijven, processors en geheugen beschreven:

Prestatiemeteritem	Beschrijving	Perfmon	iostat
IOPS of transacties per seconde	Aantal I/O-aanvragen dat per seconde naar de opslagschijf wordt verzonden.	Schijfleesbewerkingen per seconde Schrijfbewerkingen per seconde	tps r/s w/s
Schijflees- en schrijfbewerkingen	% van de lees- en schrijfbewerkingen die op de schijf zijn uitgevoerd.	Percentage leestijd schijf % schrijftijd schijf	r/s w/s
Doorvoer	Hoeveelheid gegevens die per seconde van de schijf worden gelezen of naar de schijf worden geschreven.	Leesbytes per seconde van schijf Schrijfbytes per seconde op schijf	kB_read/s kB_wrtn/s
Latentie	Totale tijd voor het voltooien van een schijf-IO-aanvraag.	Gemiddelde seconde/leestijd van schijf Gemiddelde schijf sec/schrijfbewerking	Wachten svctm
IO-grootte	Problemen met de grootte van I/O-aanvragen voor de opslagschijven.	Gemiddelde bytes/leestijd van schijf Gemiddelde schijfbytes/schrijfbewerking	avgrq-sz
Wachtrijdiepte	Aantal openstaande I/O-aanvragen die wachten om te worden gelezen van of geschreven naar de opslagschijf.	Wachtrijlengte huidige schijf	avgqu-sz
Met maximaal Geheugen	De hoeveelheid geheugen die nodig is om de toepassing soepel uit te voeren	Percentage toegewezen bytes in gebruik	vmstat gebruiken
Met maximaal CPU	Hoeveelheid CPU die nodig is om de toepassing soepel uit te voeren	Percentage processortijd	%util

Meer informatie over iostat en PerfMon.

Toepassingsprestaties optimaliseren

De belangrijkste factoren die van invloed zijn op de prestaties van een toepassing die wordt uitgevoerd op Premium Storage zijn aard van IO-aanvragen, VM-grootte, schijfgrootte, aantal schijven, schijfcaching, multithreading en wachtrijdiepte. U kunt sommige van deze factoren beheren met knoppen die door het systeem worden geleverd. De meeste toepassingen bieden u mogelijk geen optie om de IO-grootte en wachtrijdiepte rechtstreeks te wijzigen. Als u bijvoorbeeld SQL Server gebruikt, kunt u de IO-grootte en de wachtrijdiepte niet kiezen. SQL Server kiest de optimale IO-grootte en wachtrijdieptewaarden om de beste prestaties te krijgen. Het is belangrijk om inzicht te krijgen in de effecten van beide typen factoren op de prestaties van uw toepassing, zodat u de juiste resources kunt inrichten om te voldoen aan de prestatiebehoeften.

Raadpleeg in deze sectie de controlelijst voor toepassingsvereisten die u hebt gemaakt om te bepalen hoeveel u nodig hebt om de prestaties van uw toepassing te optimaliseren. Op basis hiervan kunt u bepalen welke factoren uit deze sectie u moet afstemmen. Als u de effecten van elke factor op de prestaties van uw toepassing wilt zien, voert u benchmarkhulpprogramma's uit op de installatie van uw toepassing. Raadpleeg het artikel Benchmarking, gekoppeld aan het einde, voor stappen voor het uitvoeren van algemene benchmarkhulpprogramma's op Windows- en Linux-VM's.

IOPS, doorvoer en latentie in één oogopslag optimaliseren

De onderstaande tabel bevat een overzicht van de prestatiefactoren en de stappen die nodig zijn om IOPS, doorvoer en latentie te optimaliseren. In de secties na deze samenvatting wordt elke factor veel gedetailleerder beschreven.

Zie Grootten voor virtuele machines in Azure voor meer informatie over VM-grootten en over de IOPS, doorvoer en latentie die beschikbaar zijn voor elk type VM.

	IOPS	Doorvoer	Latentie
Voorbeeldscenario	Enterprise OLTP-toepassing die zeer hoge transacties per seconde vereist.	Enterprise Datawarehousing-toepassing die grote hoeveelheden gegevens verwerkt.	Bijna realtime toepassingen die direct reageren op aanvragen van gebruikers, zoals onlinegames.
Prestatiefactoren
IO-grootte	Een kleinere IO-grootte levert hogere IOPS op.	Grotere IO-grootte levert een hogere doorvoer op.
VM-grootte	Gebruik een VM-grootte die IOPS biedt die groter is dan de vereisten van uw toepassing.	Gebruik een VM-grootte met een doorvoerlimiet die groter is dan de vereiste van uw toepassing.	Gebruik een VM-grootte die schaallimieten biedt die groter zijn dan de vereiste van uw toepassing.
Schijfgrootte	Gebruik een schijfgrootte die IOPS biedt die groter is dan de vereiste van uw toepassing.	Gebruik een schijfgrootte met een doorvoerlimiet die groter is dan de vereiste van uw toepassing.	Gebruik een schijfgrootte die schaallimieten biedt die groter zijn dan de vereiste van uw toepassing.
Vm- en schijfschaallimieten	De IOPS-limiet van de gekozen VM-grootte moet groter zijn dan de totale IOPS die wordt aangestuurd door opslagschijven die eraan zijn gekoppeld.	De doorvoerlimiet van de gekozen VM-grootte moet groter zijn dan de totale doorvoer op basis van Premium Storage-schijven die eraan zijn gekoppeld.	Schaallimieten van de gekozen VM-grootte moeten groter zijn dan de totale schaallimieten van gekoppelde Premium Storage-schijven.
Schijfcaching	Schakel ReadOnly-cache in op Premium Storage-schijven met leesintensieve bewerkingen om een hogere Lees-IOPS te krijgen.		Schakel ReadOnly Cache in op Premium Storage-schijven met zware leesbewerkingen om een zeer lage leeslatentie te krijgen.
Schijf-striping	Gebruik meerdere schijven en streep ze samen om een gecombineerde hogere IOPS- en doorvoerlimiet te krijgen. De gecombineerde limiet per VM moet hoger zijn dan de gecombineerde limieten van gekoppelde Premium-schijven.
Streepgrootte	Kleinere streepgrootte voor willekeurig klein I/O-patroon in OLTP-toepassingen. Gebruik bijvoorbeeld een streepgrootte van 64 kB voor SQL Server OLTP-toepassing.	Grotere streepgrootte voor sequentiële grote I/O-patronen in Data Warehouse toepassingen. Gebruik bijvoorbeeld een stripegrootte van 256 kB voor SQL Server datawarehouse-toepassing.
Multithreading	Gebruik multithreading om een hoger aantal aanvragen naar Premium Storage te pushen, wat leidt tot een hogere IOPS en doorvoer. Stel bijvoorbeeld op SQL Server een hoge MAXDOP-waarde in om meer CPU's toe te wijzen aan SQL Server.
Wachtrijdiepte	Grotere wachtrijdiepte levert hogere IOPS op.	Grotere wachtrijdiepte levert een hogere doorvoer op.	Een kleinere wachtrijdiepte resulteert in lagere latenties.

Aard van IO-aanvragen

Een IO-aanvraag is een eenheid van invoer-/uitvoerbewerking die door uw toepassing wordt uitgevoerd. Het identificeren van de aard van IO-aanvragen, willekeurig of opeenvolgend, lezen of schrijven, klein of groot, helpt u bij het bepalen van de prestatievereisten van uw toepassing. Het is belangrijk om inzicht te hebben in de aard van IO-aanvragen om de juiste beslissingen te nemen bij het ontwerpen van uw toepassingsinfrastructuur. IO's moeten gelijkmatig worden verdeeld om de best mogelijke prestaties te bereiken.

IO-grootte is een van de belangrijkste factoren. De IO-grootte is de grootte van de aanvraag voor invoer-/uitvoerbewerking die door uw toepassing wordt gegenereerd. De IO-grootte heeft een aanzienlijke invloed op de prestaties, met name op de IOPS en bandbreedte die de toepassing kan bereiken. De volgende formule toont de relatie tussen IOPS, IO-grootte en bandbreedte/doorvoer.

In sommige toepassingen kunt u hun IO-grootte wijzigen, terwijl sommige toepassingen dat niet doen. SQL Server bepaalt bijvoorbeeld zelf de optimale IO-grootte en biedt gebruikers geen knoppen om deze te wijzigen. Aan de andere kant biedt Oracle een parameter met de naam DB_BLOCK_SIZE waarmee u de grootte van de I/O-aanvraag van de database kunt configureren.

Als u een toepassing gebruikt, waardoor u de IO-grootte niet kunt wijzigen, gebruikt u de richtlijnen in dit artikel om de prestatie-KPI te optimaliseren die het meest relevant is voor uw toepassing. Bijvoorbeeld:

• Een OLTP-toepassing genereert miljoenen kleine en willekeurige IO-aanvragen. Als u dit type IO-aanvragen wilt afhandelen, moet u uw toepassingsinfrastructuur ontwerpen voor een hogere IOPS.
• Een datawarehousingtoepassing genereert grote en sequentiële IO-aanvragen. Als u dit type IO-aanvragen wilt afhandelen, moet u uw toepassingsinfrastructuur ontwerpen om een hogere bandbreedte of doorvoer te krijgen.

Als u een toepassing gebruikt, waarmee u de IO-grootte kunt wijzigen, gebruikt u deze vuistregel voor de IO-grootte, naast andere prestatierichtlijnen,

• Kleinere IO-grootte om hogere IOPS te krijgen. Bijvoorbeeld 8 KB voor een OLTP-toepassing.
• Grotere IO-grootte voor een hogere bandbreedte/doorvoer. Bijvoorbeeld 1024 kB voor een datawarehouse-toepassing.

Hier volgt een voorbeeld van hoe u de IOPS en doorvoer/bandbreedte voor uw toepassing kunt berekenen. Overweeg een toepassing die een P30-schijf gebruikt. De maximale IOPS en doorvoer/bandbreedte die een P30-schijf kan bereiken, is respectievelijk 5000 IOPS en 200 MB per seconde. Als uw toepassing nu de maximale IOPS van de P30-schijf vereist en u een kleinere IO-grootte gebruikt, zoals 8 KB, is de resulterende bandbreedte 40 MB per seconde. Als uw toepassing echter de maximale doorvoer/bandbreedte van de P30-schijf vereist en u een grotere IO-grootte gebruikt, zoals 1024 KB, is de resulterende IOPS minder, 200 IOPS. Stem daarom de IO-grootte zo af dat deze voldoet aan de IOPS- en doorvoer-/bandbreedtevereiste van uw toepassing. De volgende tabel bevat een overzicht van de verschillende IO-grootten en de bijbehorende IOPS en doorvoer voor een P30-schijf.

Toepassingsvereiste	I/O-grootte	IOPS	Doorvoer/bandbreedte
Max. IOPS	8 kB	5\.000	40 MB per seconde
Maximale doorvoer	1024 kB	200	200 MB per seconde
Maximale doorvoer + hoge IOPS	64 kB	3,200	200 MB per seconde
Maximale IOPS + hoge doorvoer	32 kB	5\.000	160 MB per seconde

Als u IOPS en bandbreedte hoger wilt krijgen dan de maximale waarde van één Premium Storage-schijf, gebruikt u meerdere premium-schijven die samen zijn gestreept. Stripe bijvoorbeeld twee P30-schijven om een gecombineerde IOPS van 10.000 IOPS of een gecombineerde doorvoer van 400 MB per seconde te krijgen. Zoals uitgelegd in de volgende sectie, moet u een VM-grootte gebruiken die ondersteuning biedt voor de gecombineerde schijf-IOPS en doorvoer.

Notitie

Als u de IOPS of doorvoer verhoogt, moet u ervoor zorgen dat u de doorvoer- of IOPS-limieten van de schijf of VM niet bereikt wanneer u een van beide verhoogt.

Als u de gevolgen van de IO-grootte voor de prestaties van toepassingen wilt zien, kunt u benchmarkinghulpprogramma's uitvoeren op uw VM en schijven. Maak meerdere testuitvoeringen en gebruik een andere IO-grootte voor elke uitvoering om de impact te bekijken. Raadpleeg het artikel Benchmarking, dat aan het einde is gekoppeld, voor meer informatie.

Vm-grootten op grote schaal

Wanneer u begint met het ontwerpen van een toepassing, is een van de eerste dingen die u moet doen, een VM kiezen om uw toepassing te hosten. Premium Storage wordt geleverd met vm-grootten met een hoge schaal waarmee toepassingen kunnen worden uitgevoerd die een hogere rekenkracht en een hoge I/O-prestaties op de lokale schijf vereisen. Deze VM's bieden snellere processors, een hogere geheugen-tot-core-verhouding en een Solid-State Drive (SSD) voor de lokale schijf. Voorbeelden van grootschalige VM's die Premium Storage ondersteunen, zijn de VM's uit de DS- en GS-serie.

Grootschalige VM's zijn beschikbaar in verschillende grootten met een verschillend aantal CPU-kernen, geheugen, besturingssysteem en tijdelijke schijfgrootte. Elke VM-grootte heeft ook het maximum aantal gegevensschijven dat u aan de virtuele machine kunt koppelen. Daarom is de gekozen VM-grootte van invloed op de hoeveelheid verwerkings-, geheugen- en opslagcapaciteit die beschikbaar is voor uw toepassing. Dit is ook van invloed op de kosten voor rekenkracht en opslag. Hieronder ziet u bijvoorbeeld de specificaties van de grootste VM-grootte in een DS-serie en een GS-serie:

VM-grootte	CPU-kernen	Geheugen	VM-schijfgrootten	Met maximaal gegevensschijven	Cachegrootte	IOPS	IO-limieten voor bandbreedtecache
Standard_DS14	16	112 GB	BESTURINGSSYSTEEM = 1023 GB Lokale SSD = 224 GB	32	576 GB	50.000 IOPS 512 MB per seconde	4.000 IOPS en 33 MB per seconde
Standard_GS5	32	448 GB	BESTURINGSSYSTEEM = 1023 GB Lokale SSD = 896 GB	64	4224 GB	80.000 IOPS 2000 MB per seconde	5.000 IOPS en 50 MB per seconde

Raadpleeg Grootten voor virtuele machines in Azure voor een volledige lijst met alle beschikbare vm-grootten van Azure. Kies een VM-grootte die aan de gewenste prestatievereisten voor toepassingen kan voldoen en schalen. Houd daarnaast rekening met de volgende belangrijke overwegingen bij het kiezen van VM-grootten.

Schaallimieten
De maximale IOPS-limieten per VM en per schijf zijn verschillend en onafhankelijk van elkaar. Zorg ervoor dat de toepassing IOPS aanjat binnen de limieten van de VM en de premium-schijven die eraan zijn gekoppeld. Anders ondervindt de toepassingsprestaties beperkingen.

Stel dat een toepassingsvereiste maximaal 4000 IOPS is. Hiervoor richt u een P30-schijf in op een DS1-VM. De P30-schijf kan maximaal 5.000 IOPS leveren. De DS1-VM is echter beperkt tot 3.200 IOPS. Als gevolg hiervan worden de prestaties van de toepassing beperkt door de VM-limiet van 3.200 IOPS en zijn de prestaties verslechterd. Om deze situatie te voorkomen, kiest u een VM- en schijfgrootte die beide voldoen aan de toepassingsvereisten.

Kosten van bewerking
In veel gevallen is het mogelijk dat uw totale bewerkingskosten voor het gebruik van Premium Storage lager zijn dan bij het gebruik van Standard Storage.

Denk bijvoorbeeld aan een toepassing die 16.000 IOPS vereist. Als u deze prestaties wilt bereiken, hebt u een Standard_D14 Azure IaaS-VM nodig, die een maximum IOPS van 16.000 kan geven met 32 standaardopslagschijven van 1 TB. Elke standaardopslagschijf van 1 TB kan maximaal 500 IOPS bereiken. De geschatte kosten van deze VM per maand zijn $ 1570. De maandelijkse kosten van 32 standaardopslagschijven zijn $ 1638. De geschatte totale maandelijkse kosten zijn $ 3.208.

Als u echter dezelfde toepassing op Premium Storage host, hebt u een kleinere VM-grootte en minder Premium Storage-schijven nodig, waardoor de totale kosten worden verminderd. Een Standard_DS13 VM kan voldoen aan de vereiste 16.000 IOPS met behulp van vier P30-schijven. De DS13-VM heeft een maximum IOPS van 25.600 en elke P30-schijf heeft een maximum IOPS van 5.000. Over het algemeen kan deze configuratie 5.000 x 4 = 20.000 IOPS bereiken. De geschatte kosten van deze VM per maand zijn $ 1.003. De maandelijkse kosten van vier P30 Premium-opslagschijven zijn $ 544,34. De geschatte totale maandelijkse kosten zijn $ 1544.

De onderstaande tabel bevat een overzicht van de uitsplitsing van de kosten van dit scenario voor Standard en Premium Storage.

	Standard	Premium
Kosten van VM per maand	$ 1.570,58 (Standard_D14)	$ 1.003,66 (Standard_DS13)
Kosten van schijven per maand	$ 1.638,40 (32 x 1 TB schijven)	$ 544,34 (4 x P30-schijven)
Totale kosten per maand	$ 3.208,98	$ 1.544,34

Linux-distributies

Met Azure Premium Storage krijgt u hetzelfde prestatieniveau voor VIRTUELE machines met Windows en Linux. We ondersteunen veel varianten van Linux-distributies. Zie Linux-distributies die zijn goedgekeurd in Azure voor meer informatie. Het is belangrijk te weten dat verschillende distributies beter geschikt zijn voor verschillende typen workloads. U ziet verschillende prestatieniveaus, afhankelijk van de distributie waarop uw workload wordt uitgevoerd. Test de Linux-distributies met uw toepassing en kies de distributie die het beste werkt.

Wanneer u Linux met Premium Storage uitvoert, controleert u de meest recente updates over vereiste stuurprogramma's om hoge prestaties te garanderen.

Premium Storage-schijfgrootten

Azure Premium Storage biedt verschillende grootten, zodat u er een kunt kiezen die het beste bij uw behoeften past. Elke schijfgrootte heeft een andere schaallimiet voor IOPS, bandbreedte en opslag. Kies de juiste Premium Storage schijfgrootte, afhankelijk van de toepassingsvereisten en de vm-grootte op grote schaal. In de onderstaande tabel ziet u de schijvengrootten en hun mogelijkheden. De grootten P4, P6, P15, P60, P70 en P80 worden momenteel alleen ondersteund voor Managed Disks.

Premium SSD-groottes	P1	P2	P3	P4	P6	P10	P15	P20	P30	P40	P50	P60	P70	P80
Schijfgrootte in GiB	4	8	16	32	64	128	256	512	1\.024	2048	4,096	8\.192	16.384	32.767
Ingerichte basis-IOPS per schijf	120	120	120	120	240	500	1100	2\.300	5\.000	7\.500	7\.500	16.000	18.000	20.000
**Uitgebreide ingerichte IOPS per schijf	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	8,000	16.000	20.000	20.000	20.000	20.000
Ingerichte basisdoorvoer per schijf	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
**Uitgebreide ingerichte doorvoer per schijf	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	N.v.t.	300 MB/s	600 MB/s	900 MB/s	900 MB/s	900 MB/s	900 MB/s
Max. burst-IOP's per schijf	3500	3500	3500	3500	3500	3500	3500	3500	30,000*	30,000*	30,000*	30,000*	30,000*	30,000*
Max. burst-doorvoer per schijf	170 MB/s	170 MB/s	170 MB/s	170 MB/s	170 MB/s	170 MB/s	170 MB/s	170 MB/s	1000 MB/s*	1000 MB/s*	1000 MB/s*	1000 MB/s*	1000 MB/s*	1000 MB/s*
Max. burst-duur	30 min	30 min	30 min	30 min	30 min	30 min	30 min	30 min	Onbeperkt*	Onbeperkt*	Onbeperkt*	Onbeperkt*	Onbeperkt*	Onbeperkt*
Kan worden gereserveerd	Nee	Nee	Nee	Nee	Nee	Nee	Nee	Nee	Ja, maximaal één jaar	Ja, maximaal één jaar	Ja, maximaal één jaar	Ja, maximaal één jaar	Ja, maximaal één jaar	Ja, maximaal één jaar

*Is alleen van toepassing op schijven waarvoor bursting op aanvraag is ingeschakeld.

** Alleen van toepassing op schijven waarvoor performance plus (preview) is ingeschakeld.

Hoeveel schijven u kiest, is afhankelijk van de gekozen schijfgrootte. U kunt één P50-schijf of meerdere P10-schijven gebruiken om te voldoen aan de vereisten van uw toepassing. Houd rekening met de onderstaande overwegingen bij het maken van de keuze.

Schaallimieten (IOPS en doorvoer)
De IOPS- en doorvoerlimieten van elke Premium-schijfgrootte verschillen en zijn onafhankelijk van de VM-schaallimieten. Zorg ervoor dat de totale IOPS en doorvoer van de schijven zich binnen de schaallimieten van de gekozen VM-grootte bevinden.

Als een toepassingsvereiste bijvoorbeeld een doorvoer van maximaal 250 MB per seconde is en u een DS4-VM met één P30-schijf gebruikt. De DS4-VM kan een doorvoer van maximaal 256 MB per seconde geven. Een enkele P30-schijf heeft echter een doorvoerlimiet van 200 MB/sec. Als gevolg hiervan wordt de toepassing beperkt tot 200 MB/sec vanwege de schijflimiet. Als u deze limiet wilt omzeilen, richt u meer dan één gegevensschijven in op de VM of wijzigt u de grootte van uw schijven in P40 of P50.

Notitie

Leesbewerkingen die door de cache worden geleverd, zijn niet opgenomen in de schijf-IOPS en doorvoer en zijn daarom niet onderhevig aan schijflimieten. Cache heeft een afzonderlijke IOPS- en doorvoerlimiet per VM.

In eerste instantie zijn uw lees- en schrijfbewerkingen bijvoorbeeld respectievelijk 60 MB per seconde en 40 MB per seconde. Na verloop van tijd wordt de cache opgewarmd en worden steeds meer leesbewerkingen uit de cache verwerkt. Vervolgens kunt u een hogere schrijfdoorvoer van de schijf krijgen.

Aantal schijven
Bepaal het aantal schijven dat u nodig hebt door de toepassingsvereisten te beoordelen. Elke VM-grootte heeft ook een limiet voor het aantal schijven dat u aan de virtuele machine kunt koppelen. Dit is meestal tweemaal het aantal kernen. Zorg ervoor dat de VM-grootte die u kiest, het aantal benodigde schijven kan ondersteunen.

Premium Storage-schijven kennen betere prestatiemogelijkheden dan Standard Storage-schijven. Als u uw toepassing migreert van azure IaaS-VM met behulp van Standard Storage naar Premium Storage, hebt u waarschijnlijk minder Premium-schijven nodig om dezelfde of hogere prestaties voor uw toepassing te bereiken.

Schijfcaching

Grootschalige VM's die gebruikmaken van Azure Premium Storage hebben een cachetechnologie met meerdere lagen met de naam BlobCache. BlobCache maakt gebruik van een combinatie van host-RAM en lokale SSD voor caching. Deze cache is beschikbaar voor de Premium Storage permanente schijven en de lokale VM-schijven. Deze cache-instelling is standaard ingesteld op Lezen/schrijven voor besturingssysteemschijven en ReadOnly voor gegevensschijven die worden gehost op Premium Storage. Als schijfcaching is ingeschakeld op de Premium Storage schijven, kunnen de grootschalige VM's extreem hoge prestatieniveaus bereiken die de onderliggende schijfprestaties overschrijden.

Waarschuwing

Disk Caching wordt niet ondersteund voor schijven van 4 TiB en groter. Als er meerdere schijven aan uw VM zijn gekoppeld, biedt elke schijf die kleiner is dan 4 TiB ondersteuning voor caching.

Als u de cache-instelling van een Azure-schijf wijzigt, wordt de doelschijf losgekoppeld en opnieuw gekoppeld. Als het de schijf van het besturingssysteem is, wordt de VM opnieuw opgestart. Stop alle toepassingen en services die kunnen worden beïnvloed door deze onderbreking voordat u de schijfcache-instelling wijzigt. Als u deze aanbevelingen niet volgt, kan dit leiden tot beschadiging van de gegevens.

Raadpleeg het blogbericht Inside Azure Premium Storage voor meer informatie over de werking van BlobCache.

Het is belangrijk om cache in te schakelen op de juiste set schijven. Of u schijfcaching op een Premium-schijf moet inschakelen of niet, is afhankelijk van het workloadpatroon dat door de schijf wordt verwerkt. In de onderstaande tabel ziet u de standaardcache-instellingen voor besturingssysteem- en gegevensschijven.

Schijftype	Standaardcache-instelling
Besturingssysteemschijf	ReadWrite
Gegevensschijf	ReadOnly

Hieronder volgen de aanbevolen instellingen voor de schijfcache voor gegevensschijven,

Instelling voor schijfcaching	aanbeveling voor het gebruik van deze instelling
Geen	Configureer host-cache als Geen voor alleen-schrijven en schrijfintensieve schijven.
ReadOnly	Configureer host-cache als ReadOnly voor alleen-lezen en alleen-lezen-schrijven schijven.
ReadWrite	Configureer host-cache alleen als ReadWrite als uw toepassing het schrijven van gegevens in de cache naar permanente schijven goed verwerkt wanneer dat nodig is.

Readonly
Als u Alleen-lezencache configureert op Premium Storage gegevensschijven, kunt u een lage leeslatentie bereiken en een zeer hoge Lees-IOPS en doorvoer voor uw toepassing krijgen. Dit heeft twee redenen:

1. Leesbewerkingen die worden uitgevoerd vanuit de cache, die zich op het VM-geheugen en de lokale SSD bevindt, zijn veel sneller dan leesbewerkingen van de gegevensschijf, die zich in de Azure-blobopslag bevindt.
2. Premium Storage telt de leesbewerkingen die vanuit de cache worden geleverd, niet mee voor de schijf-IOPS en doorvoer. Daarom kan uw toepassing een hogere totale IOPS en doorvoer bereiken.

Readwrite
Standaard is ReadWrite-caching ingeschakeld voor de besturingssysteemschijven. We hebben onlangs ook ondersteuning toegevoegd voor ReadWrite-caching op gegevensschijven. Als u ReadWrite-caching gebruikt, moet u een juiste manier hebben om de gegevens van de cache naar permanente schijven te schrijven. SQL Server verwerkt bijvoorbeeld het schrijven van gegevens in de cache naar de permanente opslagschijven zelf. Het gebruik van De ReadWrite-cache met een toepassing die het behouden van de vereiste gegevens niet verwerkt, kan leiden tot gegevensverlies als de VM vastloopt.

Geen
Momenteel wordt Geen alleen ondersteund op gegevensschijven. Het wordt niet ondersteund op besturingssysteemschijven. Als u Geen instelt op een besturingssysteemschijf, wordt dit intern overschreven en ingesteld op ReadOnly.

Als voorbeeld kunt u deze richtlijnen toepassen op SQL Server die worden uitgevoerd op Premium Storage door het volgende te doen:

1. Configureer de 'ReadOnly'-cache op Premium Storage-schijven die gegevensbestanden hosten.
   a. De snelle leesbewerkingen uit de cache verlagen de SQL Server querytijd, omdat gegevenspagina's veel sneller uit de cache worden opgehaald in vergelijking met rechtstreeks van de gegevensschijven.
   b. Het leveren van leesbewerkingen vanuit de cache betekent dat er extra doorvoer beschikbaar is vanaf Premium-gegevensschijven. SQL Server kunt deze extra doorvoer gebruiken om meer gegevenspagina's en andere bewerkingen op te halen, zoals back-up/herstel, batchgewijs laden en indexherbouwen.
2. Configureer de cache 'Geen' op Premium Storage-schijven die als host fungeren voor de logboekbestanden.
   a. Logboekbestanden hebben voornamelijk schrijfintensieve bewerkingen. Daarom profiteren ze niet van de ReadOnly-cache.

Prestaties op Linux-VM's optimaliseren

Voor alle Premium SSD's of ultraschijven kunt u mogelijk 'barrières' voor bestandssystemen op de schijf uitschakelen om de prestaties te verbeteren wanneer bekend is dat er geen caches zijn die gegevens kunnen verliezen. Als Azure-schijfcaching is ingesteld op ReadOnly of None, kunt u barrières uitschakelen. Maar als caching is ingesteld op ReadWrite, moeten barrières ingeschakeld blijven om de duurzaamheid van schrijfbewerkingen te garanderen. Barrières zijn doorgaans standaard ingeschakeld, maar u kunt barrières uitschakelen met behulp van een van de volgende methoden, afhankelijk van het bestandssysteemtype:

• Voor reiserFS gebruikt u de optie barrier=none mount om barrières uit te schakelen. Als u expliciet barrières wilt inschakelen, gebruikt u barrier=flush.
• Voor ext3/ext4 gebruikt u de koppelingsoptie barrier=0 om barrières uit te schakelen. Als u expliciet barrières wilt inschakelen, gebruikt u barrière=1.
• Gebruik voor XFS de optie nobarrier mount om barrières uit te schakelen. Als u expliciet barrières wilt inschakelen, gebruikt u barrière. Vanaf versie 4.10 van de mainline Linux-kernel zorgt het ontwerp van het XFS-bestandssysteem altijd voor duurzaamheid. Het uitschakelen van barrières heeft geen effect en de optie 'nobarrier' is afgeschaft. Sommige Linux-distributies kunnen echter de wijzigingen in een distributierelease met een eerdere kernelversie hebben gebackporteerd. Neem contact op met uw distributieleverancier voor de status in de distributie en versie die u uitvoert.

Schijfstriping

Wanneer een grootschalige VM is gekoppeld aan verschillende permanente premium-opslagschijven, kunnen de schijven samen worden gestript om hun IOPS, bandbreedte en opslagcapaciteit samen te voegen.

In Windows kunt u Opslagruimten gebruiken om schijven samen te stripen. U moet één kolom configureren voor elke schijf in een groep. Anders kunnen de algehele prestaties van striped volume lager zijn dan verwacht, vanwege een ongelijke verdeling van het verkeer over de schijven.

Belangrijk: met Serverbeheer ui kunt u het totale aantal kolommen instellen op 8 voor een striped volume. Wanneer u meer dan acht schijven koppelt, gebruikt u PowerShell om het volume te maken. Met PowerShell kunt u het aantal kolommen instellen dat gelijk is aan het aantal schijven. Als er bijvoorbeeld 16 schijven in één stripeset zitten; geef 16 kolommen op in de parameter NumberOfColumns van de PowerShell-cmdlet New-VirtualDisk .

In Linux gebruikt u het hulpprogramma MDADM om schijven samen te stripen. Raadpleeg Software RAID configureren op Linux voor gedetailleerde stappen voor het stripen van schijven in Linux.

Streepgrootte
Een belangrijke configuratie in schijfstriping is de stripegrootte. De streepgrootte of blokgrootte is het kleinste stukje gegevens dat de toepassing kan adresseren op een striped volume. De streepgrootte die u configureert, is afhankelijk van het type toepassing en het aanvraagpatroon. Als u de verkeerde stripegrootte kiest, kan dit leiden tot onjuiste I/O-uitlijning, wat leidt tot verminderde prestaties van uw toepassing.

Als een IO-aanvraag die door uw toepassing wordt gegenereerd, bijvoorbeeld groter is dan de schijfstripe, schrijft het opslagsysteem deze over de grenzen van stripe-eenheden op meer dan één schijf. Wanneer het tijd is om toegang te krijgen tot die gegevens, moet deze meerdere stripe-eenheden zoeken om de aanvraag te voltooien. Het cumulatieve effect van dergelijk gedrag kan leiden tot aanzienlijke prestatievermindering. Aan de andere kant, als de grootte van de IO-aanvraag kleiner is dan stripe-grootte en als deze willekeurig van aard is, kunnen de IO-aanvragen op dezelfde schijf worden opgeteld, wat een knelpunt veroorzaakt en uiteindelijk de IO-prestaties verslechtert.

Afhankelijk van het type workload dat door uw toepassing wordt uitgevoerd, kiest u een geschikte streepgrootte. Gebruik voor willekeurige kleine I/O-aanvragen een kleinere stripegrootte. Terwijl voor grote sequentiële IO-aanvragen een grotere stripe-grootte wordt gebruikt. Meer informatie over de aanbevelingen voor de streepgrootte voor de toepassing die u op Premium Storage gaat uitvoeren. Voor SQL Server configureert u de stripegrootte van 64 KB voor OLTP-workloads en 256 KB voor datawarehousingworkloads. Zie Best practices voor prestaties voor SQL Server op Azure-VM's voor meer informatie.

Notitie

U kunt maximaal 32 Premium Storage-schijven op een VM uit de DS-serie en 64 Premium Storage-schijven op een VM uit de GS-serie samenvoegen.

Multithreading

Azure heeft Premium Storage platform ontworpen om enorm parallel te zijn. Daarom levert een toepassing met meerdere threads veel betere prestaties dan een toepassing met één thread. Een toepassing met meerdere threads splitst de taken op over meerdere threads en verhoogt de efficiëntie van de uitvoering door maximaal gebruik te maken van de VM- en schijfresources.

Als uw toepassing bijvoorbeeld wordt uitgevoerd op een VM met één kern met behulp van twee threads, kan de CPU schakelen tussen de twee threads om efficiëntie te bereiken. Terwijl de ene thread op een schijf-IO wacht om te voltooien, kan de CPU overschakelen naar de andere thread. Op deze manier kunnen twee threads meer bereiken dan één thread zou doen. Als de VM meer dan één kern heeft, wordt de uitvoeringstijd verder verkort, omdat elke kern taken parallel kan uitvoeren.

Mogelijk kunt u de manier waarop een kant-en-klare toepassing één threading of multi-threading implementeert, niet wijzigen. SQL Server kan bijvoorbeeld multi-CPU en multi-core verwerken. SQL Server bepaalt echter onder welke voorwaarden een of meer threads worden gebruikt om een query te verwerken. Het kan query's uitvoeren en indexen bouwen met behulp van multithreading. Voor een query waarbij grote tabellen worden gekoppeld en gegevens worden gesorteerd voordat ze terugkeren naar de gebruiker, gebruikt SQL Server waarschijnlijk meerdere threads. Een gebruiker kan echter niet bepalen of SQL Server een query uitvoert met behulp van één thread of meerdere threads.

Er zijn configuratie-instellingen die u kunt wijzigen om deze multithreading of parallelle verwerking van een toepassing te beïnvloeden. In het geval van SQL Server is dit bijvoorbeeld de maximale mate van parallelle uitvoering. Met deze instelling met de naam MAXDOP kunt u het maximum aantal processors configureren SQL Server kunt gebruiken bij parallelle verwerking. U kunt MAXDOP configureren voor afzonderlijke query's of indexbewerkingen. Dit is handig als u de resources van uw systeem wilt verdelen voor een prestatiekritieke toepassing.

Stel dat uw toepassing met SQL Server tegelijkertijd een grote query en een indexbewerking uitvoert. Laten we ervan uitgaan dat u wilt dat de indexbewerking beter presteert in vergelijking met de grote query. In een dergelijk geval kunt u de MAXDOP-waarde van de indexbewerking zo instellen dat deze hoger is dan de MAXDOP-waarde voor de query. Op deze manier heeft SQL Server meer processors die kunnen worden gebruikt voor de indexbewerking in vergelijking met het aantal processors dat kan worden toegewezen aan de grote query. Houd er rekening mee dat u niet het aantal threads bepaalt dat SQL Server voor elke bewerking gebruikt. U kunt het maximum aantal processors bepalen dat wordt toegewezen voor multithreading.

Meer informatie over graden van parallellisme in SQL Server. Ontdek instellingen die van invloed zijn op multithreading in uw toepassing en hun configuraties om de prestaties te optimaliseren.

Wachtrijdiepte

De wachtrijdiepte of wachtrijlengte of wachtrijgrootte is het aantal I/O-aanvragen in behandeling in het systeem. De waarde van de wachtrijdiepte bepaalt hoeveel IO-bewerkingen uw toepassing kan uitlijnen, welke worden verwerkt door de opslagschijven. Dit is van invloed op alle drie de prestatie-indicatoren van toepassingen die we in dit artikel hebben besproken, namelijk IOPS, doorvoer en latentie.

Wachtrijdiepte en multithreading zijn nauw verwant. De waarde wachtrijdiepte geeft aan hoeveel multithreading kan worden bereikt door de toepassing. Als de wachtrijdiepte groot is, kan de toepassing meer bewerkingen gelijktijdig uitvoeren, met andere woorden, meer multithreading. Als de wachtrijdiepte klein is, zijn er onvoldoende aanvragen opgesteld voor gelijktijdige uitvoering, hoewel de toepassing meerdere threads heeft.

Normaal gesproken kunt u met off-the-shelf-toepassingen de wachtrijdiepte niet wijzigen, omdat deze meer kwaad dan goed zal doen als deze onjuist is ingesteld. Toepassingen stellen de juiste waarde van de wachtrijdiepte in voor optimale prestaties. Het is echter belangrijk om dit concept te begrijpen, zodat u prestatieproblemen met uw toepassing kunt oplossen. U kunt ook de effecten van de wachtrijdiepte observeren door benchmarkhulpprogramma's op uw systeem uit te voeren.

Sommige toepassingen bieden instellingen om de wachtrijdiepte te beïnvloeden. De instelling MAXDOP (maximale mate van parallellisme) in SQL Server in de vorige sectie uitgelegd. MAXDOP is een manier om de wachtrijdiepte en multithreading te beïnvloeden, hoewel de waarde voor wachtrijdiepte van SQL Server niet rechtstreeks wordt gewijzigd.

Hoge wachtrijdiepte
Een hoge wachtrijdiepte lijnt meer bewerkingen op de schijf uit. De schijf kent de volgende aanvraag in de wachtrij van tevoren. Daarom kan de schijf bewerkingen vooraf plannen en deze in een optimale volgorde verwerken. Omdat de toepassing meer aanvragen naar de schijf verzendt, kan de schijf meer parallelle IO's verwerken. Uiteindelijk kan de toepassing hogere IOPS bereiken. Omdat de toepassing meer aanvragen verwerkt, neemt de totale doorvoer van de toepassing ook toe.

Normaal gesproken kan een toepassing een maximale doorvoer bereiken met 8-16+ openstaande IO's per gekoppelde schijf. Als een wachtrijdiepte één is, pusht de toepassing niet voldoende IO's naar het systeem en worden er minder hoeveelheden verwerkt in een bepaalde periode. Met andere woorden, minder doorvoer.

Als u bijvoorbeeld in SQL Server de MAXDOP-waarde voor een query instelt op '4', wordt SQL Server geïnformeerd dat er maximaal vier kernen kunnen worden gebruikt om de query uit te voeren. SQL Server bepaalt wat de beste waarde voor wachtrijdiepte is en het aantal kernen voor het uitvoeren van de query.

Optimale wachtrijdiepte
Zeer hoge waarde voor de wachtrijdiepte heeft ook nadelen. Als de waarde van de wachtrijdiepte te hoog is, probeert de toepassing zeer hoge IOPS aan te drijven. Tenzij de toepassing permanente schijven heeft met voldoende ingerichte IOPS, kan dit een negatieve invloed hebben op de latentie van toepassingen. De volgende formule toont de relatie tussen IOPS, latentie en wachtrijdiepte.

U moet Wachtrijdiepte niet configureren voor een hoge waarde, maar voor een optimale waarde, die voldoende IOPS voor de toepassing kan leveren zonder dat dit van invloed is op latentie. Als de latentie van de toepassing bijvoorbeeld 1 milliseconde moet zijn, is de wachtrijdiepte die nodig is om 5000 IOPS te bereiken, QD = 5000 x 0,001 = 5.

Wachtrijdiepte voor gestreept volume
Houd voor een striped volume een voldoende hoge wachtrijdiepte aan, zodat elke schijf afzonderlijk een piekwachtrijdiepte heeft. Denk bijvoorbeeld aan een toepassing die een wachtrijdiepte van 2 pusht en er zijn vier schijven in de stripe. De twee I/O-aanvragen gaan naar twee schijven en de resterende twee schijven zijn inactief. Configureer daarom de wachtrijdiepte zodanig dat alle schijven bezet kunnen zijn. De onderstaande formule laat zien hoe u de wachtrijdiepte van gestreepte volumes kunt bepalen.

Beperking

Azure Premium Storage richt het opgegeven aantal IOPS en doorvoer in, afhankelijk van de VM-grootten en schijfgrootten die u kiest. Telkens wanneer uw toepassing IOPS of doorvoer probeert aan te drijven boven deze limieten van wat de VM of schijf kan verwerken, beperkt Premium Storage deze. Dit wordt gemanifesteerd in de vorm van verminderde prestaties in uw toepassing. Dit kan een hogere latentie, een lagere doorvoer of een lagere IOPS betekenen. Als Premium Storage niet beperkt, kan uw toepassing volledig mislukken door te overschrijden wat de resources kunnen bereiken. Om prestatieproblemen als gevolg van beperking te voorkomen, moet u dus altijd voldoende resources voor uw toepassing inrichten. Neem rekening met wat we hebben besproken in de secties VM-grootten en Schijfgrootten hierboven. Benchmarking is de beste manier om erachter te komen welke resources u nodig hebt om uw toepassing te hosten.

Volgende stappen

Als u uw schijf wilt benchmarken, raadpleegt u onze artikelen over het benchmarken van een schijf:

• Voor Linux: benchmark voor uw toepassing in Azure Disk Storage
• Voor Windows: Benchmarking van een schijf.

Meer informatie over de beschikbare schijftypen:

• Voor Linux: selecteer een schijftype
• Voor Windows: selecteer een schijftype

Lees voor SQL Server gebruikers artikelen over best practices voor prestaties voor SQL Server:

• Best practices voor prestaties voor SQL Server in Azure Virtual Machines
• Azure Premium Storage biedt de hoogste prestaties voor SQL Server in Azure VM