Azure Premium Storage: ontwerp voor hoge prestaties

Van toepassing op: ✔️ Virtuele Linux-machines voor Windows-VM's ✔️ ✔️ Flexibele schaalsets Uniform 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 best practices voor prestaties die van toepassing zijn op technologieën die door uw toepassing worden gebruikt. Ter illustratie van de richtlijnen hebben we SQL Server gebruikt die in Premium Storage wordt uitgevoerd als voorbeeld in dit document.

Hoewel we prestatiescenario's voor de opslaglaag in dit artikel 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. Bovendien optimaliseert u de webserver en toepassingsserver van de SharePoint-farm om de meeste prestaties te verkrijgen.

In dit artikel vindt u antwoord op de volgende veelgestelde vragen over het optimaliseren van toepassingsprestaties 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 in Premium Storage?
  • Hoe kunt u optimaliseren voor IOPS, bandbreedte en latentie?

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

Notitie

Soms is wat een probleem met 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:

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

Lees voordat u begint, als u nog niet eerder met Premium Storage bent, eerst het Type Azure-schijf selecteren voor IaaS-VM's en schaalbaarheidsdoelen voor Premium-pagina-blobopslagaccounts.

Indicatoren voor toepassingsprestaties

We beoordelen of een toepassing goed presteert of geen prestatie-indicatoren gebruikt, zoals hoe snel een toepassing een gebruikersaanvraag verwerkt, hoeveel gegevens een toepassing per aanvraag verwerkt, hoeveel aanvragen een toepassing in een bepaalde periode verwerkt, hoe lang een gebruiker moet wachten om een antwoord te krijgen nadat hij zijn aanvraag heeft ingediend. 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, Het verzamelen van toepassingsvereisten, leert u hoe u deze prestatie-indicatoren voor uw toepassing kunt meten. Verderop in De prestaties van toepassingen optimaliseren leert u meer 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, sequentiële of willekeurige bewerkingen zijn. OLTP-toepassingen (Online Transaction Processing), zoals een onlinedetailwebsite, moeten direct veel gelijktijdige gebruikersaanvragen verwerken. De gebruikersaanvragen worden ingevoegd en bijgewerkt intensieve databasetransacties, die de toepassing snel moet verwerken. Daarom vereisen OLTP-toepassingen 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 De prestaties van toepassingen optimaliseren bespreken we in detail alle factoren die u moet overwegen om 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 standaard-GS5-VM heeft bijvoorbeeld 80.000 IOPS-limiet.

Doorvoer

Doorvoer of bandbreedte is de hoeveelheid gegevens die uw toepassing in een bepaald interval naar de opslagschijven verzendt. Als uw toepassing invoer-/uitvoerbewerkingen uitvoert met grote IO-eenheden, is hoge doorvoer vereist. Datawarehouse-toepassingen geven vaak scanintensieve bewerkingen uit die toegang hebben tot grote hoeveelheden 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 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 op basis van 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.

Relation of IOPS and throughput

Daarom is het belangrijk om de optimale doorvoer en IOPS-waarden te bepalen die uw toepassing nodig heeft. Terwijl u de ene probeert te optimaliseren, wordt de andere ook beïnvloed. In De prestaties van toepassingen 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 deze terug te communiceren met uw toepassing. Premium Storage biedt consistente lage latenties. Premium-schijven zijn ontworpen om latenties van één 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 hogere IOPS en doorvoer te krijgen, heeft dit invloed op de latentie van uw toepassing. Evalueer na het afstemmen van de prestaties van de toepassing altijd de latentie van de toepassing om onverwacht gedrag met hoge latentie te voorkomen.

De volgende besturingsvlakbewerkingen op beheerde schijven kunnen betrekking hebben op de verplaatsing van de schijf van de ene opslaglocatie naar de andere. Dit wordt ingedeeld via een achtergrondkopie van gegevens die enkele uren kunnen duren, meestal minder dan 24 uur, afhankelijk van de hoeveelheid gegevens in 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. Tijdens deze periode is er geen invloed op schrijflatentie.

  • Werk het opslagtype bij.
  • Koppel een schijf los van de ene VM aan een andere.
  • Een beheerde schijf maken 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 hoogwaardige toepassingen die worden uitgevoerd in Azure Premium Storage, is inzicht in de prestatievereisten van uw toepassing. Nadat u 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 leveren. Hoge IOPS is bijvoorbeeld belangrijk voor OLTP-toepassingen die miljoenen transacties in een seconde verwerken. Hoewel hoge doorvoer essentieel is voor datawarehouse-toepassingen die grote hoeveelheden gegevens verwerken in een seconde. Extreem lage latentie is cruciaal voor realtime toepassingen zoals live videostreamingwebsites.

Meet vervolgens de maximale prestatievereisten van uw toepassing gedurende de levensduur. Gebruik de onderstaande voorbeeldcontrolelijst als begin. Noteer de maximale prestatievereisten tijdens normale, piek- en off-hours workloadperioden. Door vereisten voor alle workloadsniveaus te identificeren, kunt u de algehele prestatievereiste van uw toepassing bepalen. De normale workload van een e-commercewebsite is bijvoorbeeld de transacties die gedurende de meeste dagen in een jaar worden uitgevoerd. De piekbelasting van de website zal de transacties zijn die het dient tijdens het vakantieseizoen of speciale verkoopevenementen. De piekworkload wordt doorgaans gedurende een beperkte periode ervaren, maar kan vereisen dat uw toepassing twee of meer keer de normale werking kan schalen. Ontdek de 50 percentiel-, 90 percentiel- en 99 percentielvereisten. Dit helpt bij het filteren van uitbijters 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 moet overwegen om deze getallen te schalen op basis van de verwachte toekomstige groei van uw toepassing. Het is een goed idee om van tevoren groei te plannen, omdat het moeilijker kan zijn om de infrastructuur te wijzigen om de prestaties later te verbeteren.

Als u een bestaande toepassing hebt en naar Premium Storage wilt overstappen, bouwt u eerst de bovenstaande controlelijst voor de bestaande toepassing. Bouw vervolgens een prototype van uw toepassing in Premium Storage en ontwerp de toepassing op basis van richtlijnen die worden beschreven in De prestaties van de toepassing 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 prestatievereisten van uw toepassing te meten, is het gebruik van hulpprogramma's voor prestatiebewaking die worden geleverd door het besturingssysteem van de server. U kunt PerfMon voor Windows en iostat voor Linux gebruiken. Met deze hulpprogramma's worden meteritems 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 workloads, piekuren en off-hours uitvoert.

De PerfMon-tellers zijn beschikbaar voor processor, geheugen en elke logische schijf en fysieke schijf van uw server. Wanneer u Premium Storage-schijven met een virtuele machine gebruikt, zijn de fysieke schijfmeteritems voor elke Premium-opslagschijf en logische-schijfmeteritems voor elk volume dat is gemaakt op de Premium Storage-schijven. U moet de waarden vastleggen voor de schijven waarop uw toepassingsworkload wordt gehost. Als er een een-op-een-toewijzing tussen logische en fysieke schijven is, kunt u verwijzen naar fysieke schijftellers; raadpleeg anders de tellers voor logische schijven. 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 tellers voor schijven, processors en geheugen beschreven:

Prestatiemeteritem Description Perfmon Iostat
IOPS of transacties per seconde Aantal I/O-aanvragen dat per seconde is uitgegeven aan de opslagschijf. Leesbewerkingen per seconde van schijf
Schrijfbewerkingen per seconde
tps
r/s
w/s
Lees- en schrijfbewerkingen van schijven % van de lees- en schrijfbewerkingen die op de schijf worden uitgevoerd. Leestijd van schijfpercentage
% schrijftijd van schijf
r/s
w/s
Doorvoer Hoeveelheid gegevens die per seconde naar de schijf worden gelezen of geschreven. Bytes per seconde lezen van schijf
Bytes per seconde schrijven op schijf
kB_read/s
kB_wrtn/s
Latentie Totale tijd om een IO-schijfaanvraag te voltooien. Gemiddelde schijf sec/gelezen
Gemiddelde schijf sec/write
Wachten
svctm
IO-grootte De grootte van I/O-aanvragen voor de opslagschijven. Gemiddelde schijfbytes/lezen
Gemiddelde schijfbytes/schrijven
avgrq-sz
Wachtrijdiepte Het aantal openstaande I/O-aanvragen dat moet worden gelezen of geschreven naar de opslagschijf. Lengte van huidige schijfwachtrij avgqu-sz
Met maximaal Geheugen 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 % 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 de aard van IO-aanvragen, VM-grootte, schijfgrootte, aantal schijven, schijfcaching, multithreading en wachtrijdiepte. U kunt enkele van deze factoren beheren met knoppen die door het systeem worden geleverd. De meeste toepassingen bieden mogelijk geen optie om de IO-grootte en wachtrijdiepte rechtstreeks te wijzigen. Als u bijvoorbeeld SQL Server gebruikt, kunt u de IO-grootte en wachtrijdiepte niet kiezen. SQL Server kiest de optimale IO-grootte en wachtrijdieptewaarden om de meeste prestaties te verkrijgen. 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 benchmarkinghulpprogramma'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 Virtuele Windows- en Linux-machines.

IOPS, doorvoer en latentie in één oogopslag optimaliseren

De onderstaande tabel bevat een overzicht van prestatiefactoren en de stappen die nodig zijn om IOPS, doorvoer en latentie te optimaliseren. In de secties na deze samenvatting wordt elke factor 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 vereist zeer hoge transacties per secondetarief. Enterprise Datawarehousing-toepassing die grote hoeveelheden gegevens verwerkt. Toepassingen in bijna realtime vereisen directe reacties op gebruikersaanvragen, zoals online gaming.
Prestatiefactoren      
IO-grootte Kleinere IO-grootte levert hogere IOPS op. Grotere IO-grootte om een hogere doorvoer te leveren.  
VM-grootte Gebruik een VM-grootte die IOPS groter biedt dan uw toepassingsvereiste. Gebruik een VM-grootte met een doorvoerlimiet die groter is dan uw toepassingsvereiste. Gebruik een VM-grootte die schaallimieten biedt die groter zijn dan uw toepassingsvereiste.
Schijfgrootte Gebruik een schijfgrootte die IOPS groter biedt dan uw toepassingsvereiste. Gebruik een schijfgrootte met een doorvoerlimiet die groter is dan uw toepassingsvereiste. Gebruik een schijfgrootte die schaallimieten biedt die groter zijn dan uw toepassingsvereiste.
Vm- en schijfschaallimieten De IOPS-limiet van de gekozen VM-grootte moet groter zijn dan het totale aantal IOPS dat wordt aangestuurd door opslagschijven die eraan zijn gekoppeld. De doorvoerlimiet van de gekozen VM-grootte moet groter zijn dan de totale doorvoer die wordt aangestuurd door 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 hogere Lees-IOPS te krijgen.   Schakel ReadOnly Cache in op Premium Storage-schijven met kant-en-klare zware bewerkingen om zeer lage leeslatenties te krijgen.
Schijf-striping Gebruik meerdere schijven en strip ze samen om een gecombineerde hogere IOPS- en doorvoerlimiet op te halen. De gecombineerde limiet per VM moet hoger zijn dan de gecombineerde limieten van gekoppelde Premium-schijven.    
Streepgrootte Kleinere stripegrootte voor willekeurig klein IO-patroon dat wordt gezien in OLTP-toepassingen. Gebruik bijvoorbeeld stripegrootte van 64 kB voor SQL Server OLTP-toepassing. Grotere stripegrootte voor een sequentieel groot IO-patroon dat wordt gezien in Data Warehouse-toepassingen. Gebruik bijvoorbeeld de stripegrootte van 256 kB voor de SQL Server Data Warehouse-toepassing.  
Multithreading Gebruik multithreading om een hoger aantal aanvragen naar Premium Storage te pushen dat leidt tot hogere IOPS en doorvoer. Stel in SQL Server bijvoorbeeld 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 hogere doorvoer op. Kleinere wachtrijdiepte levert lagere latenties op.

Aard van IO-aanvragen

Een IO-aanvraag is een invoer-/uitvoerbewerking die door uw toepassing wordt uitgevoerd. Als u de aard van IO-aanvragen identificeert, willekeurig of opeenvolgend, lezen of schrijven, klein of groot, kunt u de prestatievereisten van uw toepassing bepalen. 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. IOs moeten gelijkmatig worden gedistribueerd om de best mogelijke prestaties te bereiken.

IO-grootte is een van de belangrijkste factoren. De IO-grootte is de grootte van de invoer-/uitvoerbewerkingsaanvraag 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. In de volgende formule ziet u de relatie tussen IOPS, IO-grootte en bandbreedte/doorvoer.
A diagram showing the equation I O P S times I O size equals Throughput.

In sommige toepassingen kunt u de IO-grootte wijzigen, terwijl sommige toepassingen dat niet doen. SQL Server bepaalt bijvoorbeeld de optimale IO-grootte zelf 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 I/O-aanvraaggrootte van de database kunt configureren.

Als u een toepassing gebruikt waarmee 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 deze typen IO-aanvragen wilt verwerken, moet u uw toepassingsinfrastructuur ontwerpen om hogere IOPS te krijgen.
  • Een datawarehousingtoepassing genereert grote en opeenvolgende IO-aanvragen. Als u deze typen IO-aanvragen wilt verwerken, 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 om een hogere bandbreedte/doorvoer te krijgen. 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 met behulp van een P30-schijf. 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 P30-schijf vereist en u een grotere IO-grootte gebruikt, zoals 1024 KB, zijn de resulterende IOPS minder, 200 IOPS. Pas daarom de IO-grootte zodanig af dat deze voldoet aan de IOPS-vereisten van uw toepassing en doorvoer/bandbreedte. 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 wilt ophalen die hoger zijn dan de maximumwaarde van één Premium-opslagschijf, gebruikt u meerdere Premium-schijven die samen zijn gestreept. Strip bijvoorbeeld twee P30-schijven om een gecombineerde IOPS van 10.000 IOPS of een gecombineerde doorvoer van 400 MB per seconde op te halen. Zoals wordt uitgelegd in de volgende sectie, moet u een VM-grootte gebruiken die ondersteuning biedt voor de gecombineerde schijf-IOPS en doorvoer.

Notitie

Wanneer u IOPS of doorvoer verhoogt, neemt de andere ook toe, zorg er dan voor dat u geen doorvoer- of IOPS-limieten van de schijf of VM bereikt wanneer u een van beide verhoogt.

Als u de gevolgen van io-grootte wilt zien voor de prestaties van toepassingen, kunt u benchmarkinghulpprogramma's uitvoeren op uw VM en schijven. Maak meerdere testuitvoeringen en gebruik verschillende IO-grootte voor elke uitvoering om de impact te zien. Raadpleeg het artikel Benchmarking, aan het einde 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 VIRTUELE machine kiezen om uw toepassing te hosten. Premium Storage wordt geleverd met VM-grootten op grote schaal waarmee toepassingen kunnen worden uitgevoerd waarvoor hogere rekenkracht en een hoge I/O-prestaties van de lokale schijf nodig zijn. Deze VM's bieden snellere processors, een hogere geheugen-naar-core-verhouding en een Solid-State Drive (SSD) voor de lokale schijf. Voorbeelden van vm's met hoge schaal die Premium Storage ondersteunen, zijn de VM's uit de DS- en GS-serie.

Vm's met hoge schaal zijn beschikbaar in verschillende grootten met een ander 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 heeft de gekozen VM-grootte invloed op de hoeveelheid verwerking, geheugen en opslagcapaciteit die beschikbaar is voor uw toepassing. Dit is ook van invloed op de kosten voor compute 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
4000 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
5000 IOPS en 50 MB per seconde

Als u een volledige lijst met alle beschikbare Azure VM-grootten wilt weergeven, raadpleegt u Grootten voor virtuele machines in Azure. Kies een VM-grootte die aan de gewenste prestatievereisten voor toepassingen kan voldoen en schalen. Houd bovendien rekening met de volgende belangrijke overwegingen bij het kiezen van VM-grootten.

Schaallimieten
De maximale IOPS-limieten per VM en per schijf verschillen en zijn onafhankelijk van elkaar. Zorg ervoor dat de toepassing IOPS beheert binnen de grenzen van de VIRTUELE machine en de Premium-schijven die eraan zijn gekoppeld. Anders ondervindt de toepassingsprestaties beperking.

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. Daarom worden de prestaties van de toepassing beperkt door de VM-limiet op 3.200 IOPS en worden de prestaties verminderd. Als u deze situatie wilt 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 bedrijfskosten voor het gebruik van Premium Storage lager zijn dan het gebruik van Standard Storage.

Denk bijvoorbeeld aan een toepassing waarvoor 16.000 IOPS is vereist. Voor deze prestaties hebt u een Standard_D14 Azure IaaS-VM nodig, die maximaal IOPS van 16.000 kan bieden met 32 standaardopslagschijven van 1 TB. Elke standaardopslagschijf van 1 TB kan maximaal 500 IOPS bereiken. De geschatte kosten van deze VM per maand bedragen $ 1570. De maandelijkse kosten van 32 standaardopslagschijven bedragen $ 1.638. De geschatte totale maandelijkse kosten bedragen $ 3.208.

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

In de onderstaande tabel ziet u een overzicht van de kosten voor dit scenario voor Standard en Premium Storage.

  Standard Premium
Kosten van VM's 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 VM's 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 grootte van schijven en de bijbehorende mogelijkheden. P4-, P6-, P15-, P60-, P70- en P80-grootten 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 IOP's per schijf 120 120 120 120 240 500 1100 2\.300 5\.000 7\.500 7\.500 16.000 18.000 20.000
Ingerichte doorvoer per schijf 25 MB/sec 25 MB/sec 25 MB/sec 25 MB/sec 50 MB/sec 100 MB/sec 125 MB/sec 150 MB/sec 200 MB/sec 250 MB/sec 250 MB/sec 500 MB/sec 750 MB/sec 900 MB/sec
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/sec 170 MB/sec 170 MB/sec 170 MB/sec 170 MB/sec 170 MB/sec 170 MB/sec 170 MB/sec 1000 MB per seconde* 1000 MB per seconde* 1000 MB per seconde* 1000 MB per seconde* 1000 MB per seconde* 1000 MB per seconde*
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

*Alleen van toepassing op schijven waarvoor bursting op aanvraag 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 uw toepassingsvereiste. Houd rekening met de hieronder vermelde 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 binnen de schaallimieten van de gekozen VM-grootte vallen.

Als een toepassingsvereiste bijvoorbeeld maximaal 250 MB per seconde doorvoer 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 per seconde. Daarom wordt de toepassing beperkt tot 200 MB per seconde vanwege de schijflimiet. Als u deze limiet wilt overwinnen, richt u meer dan één gegevensschijven in op de virtuele machine of wijzigt u de grootte van uw schijven in P40 of P50.

Notitie

Leesbewerkingen die door de cache worden geleverd, worden niet opgenomen in de schijf-IOPS en doorvoer, dus niet onderhevig aan schijflimieten. Cache heeft de 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 er steeds meer leesbewerkingen uit de cache gebruikt. 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. Normaal gesproken is dit twee keer het aantal kernen. Zorg ervoor dat de VM-grootte die u kiest, ondersteuning kan bieden voor het aantal schijven dat nodig is.

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

Vm's met hoge schaal die gebruikmaken van Azure Premium Storage hebben een cachetechnologie met meerdere lagen, BlobCache genoemd. BlobCache maakt gebruik van een combinatie van de host-RAM en lokale SSD voor caching. Deze cache is beschikbaar voor de permanente schijven van Premium Storage en de lokale VM-schijven. Deze cache-instelling is standaard ingesteld op Lezen/Schrijven voor besturingssysteemschijven en ReadOnly voor gegevensschijven die worden gehost in Premium Storage. Als schijfcaching is ingeschakeld op de Premium Storage-schijven, kunnen de vm's op grote schaal 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 dit de besturingssysteemschijf is, wordt de VIRTUELE machine 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 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 nu schijfcaching moet inschakelen op een Premium-schijf of niet, is afhankelijk van het workloadpatroon dat de schijf gaat verwerken. In de onderstaande tabel ziet u de standaardcache-instellingen voor besturingssysteem- en gegevensschijven.

Schijftype Standaardinstelling voor cache
Besturingssysteemschijf ReadWrite
Gegevensschijf ReadOnly

Hieronder ziet u de aanbevolen instellingen voor de schijfcache voor gegevensschijven,

Instelling voor schijfcache aanbeveling over wanneer deze instelling moet worden gebruikt
Geen Configureer hostcache als Geen voor alleen-schrijven en schrijfintensieve schijven.
ReadOnly Configureer hostcache als ReadOnly voor alleen-lezen- en lezen-schrijfschijven.
ReadWrite Configureer de hostcache alleen als ReadWrite als uw toepassing het schrijven van gegevens in de cache naar permanente schijven afhandelt wanneer dat nodig is.

Readonly
Door ReadOnly caching te configureren op Premium Storage-gegevensschijven, kunt u een lage leeslatentie bereiken en zeer hoge Lees-IOPS en doorvoer voor uw toepassing krijgen. Dit is om twee redenen,

  1. Leesbewerkingen die worden uitgevoerd vanuit de cache, die zich in het VM-geheugen en de lokale SSD bevinden, zijn veel sneller dan leesbewerkingen van de gegevensschijf, die zich in de Azure Blob-opslag bevindt.
  2. Premium Storage telt niet de leesbewerkingen uit de cache, naar de schijf-IOPS en doorvoer. Uw toepassing kan daarom hogere totale IOPS en doorvoer bereiken.

Readwrite
Op de besturingssysteemschijven is standaard ReadWrite-caching ingeschakeld. 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 ReadWrite-cache met een toepassing die het persistent maken van de vereiste gegevens niet afhandelt, kan leiden tot gegevensverlies als de VM vastloopt.

Geen
Op dit moment 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.

U kunt deze richtlijnen bijvoorbeeld toepassen op SQL Server die wordt uitgevoerd in Premium Storage door het volgende te doen:

  1. Configureer '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 worden opgehaald uit de cache dan rechtstreeks van de gegevensschijven.
    b. Het verwerken van leesbewerkingen uit de cache betekent dat er extra doorvoer beschikbaar is van Premium-gegevensschijven. SQL Server kan deze extra doorvoer gebruiken voor het ophalen van meer gegevenspagina's en andere bewerkingen, zoals back-up/herstel, batchbelastingen en herbouwen van indexen.
  2. Configureer de cache None op Premium Storage-schijven die als host fungeren voor de logboekbestanden.
    a. Logboekbestanden hebben voornamelijk schrijfbewerkingen. Daarom profiteren ze niet van de ReadOnly-cache.

Prestaties optimaliseren op Linux-VM's

Voor alle Premium SSD's of ultraschijven kunt u mogelijk 'barrières' uitschakelen voor bestandssystemen op de schijf om de prestaties te verbeteren wanneer bekend is dat er geen caches zijn die gegevens kunnen verliezen. Als caching van Azure-schijven 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 worden doorgaans standaard ingeschakeld, maar u kunt barrières uitschakelen met behulp van een van de volgende methoden, afhankelijk van het bestandstype:

  • Gebruik voor reiserFS 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 barrier=1.
  • Gebruik voor XFS de optie nobarrier koppelen 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 hebben echter mogelijk de wijzigingen in een distributierelease met een eerdere kernelversie teruggezet. 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 schijven voor Premium Storage, kunnen de schijven samen worden gestreept 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 pool. Anders kunnen de algehele prestaties van gestreept volume lager zijn dan verwacht, vanwege een ongelijke verdeling van verkeer over de schijven.

Belangrijk: Met de gebruikersinterface van Serverbeheer kunt u het totale aantal kolommen instellen op 8 voor een gestreept 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 staan; geef 16 kolommen op in de parameter NumberOfColumns van de Cmdlet New-VirtualDisk PowerShell.

Gebruik in Linux het hulpprogramma MDADM om schijven samen te stripen. Raadpleeg Software RAID configureren in Linux voor gedetailleerde stappen voor het stripen van schijven in Linux.

Streepgrootte
Een belangrijke configuratie in schijfstriping is de stripegrootte. De stripegrootte of blokgrootte is het kleinste segment gegevens dat door de toepassing kan worden verwerkt op een gestreept volume. De stripegrootte die u configureert, is afhankelijk van het type toepassing en het bijbehorende aanvraagpatroon. Als u de verkeerde stripegrootte kiest, kan dit leiden tot een 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 grootte van de schijfstrip, 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 er naar meer dan één stripe-eenheden worden gezocht om de aanvraag te voltooien. Het cumulatieve effect van dergelijk gedrag kan leiden tot aanzienlijke prestatievermindering. Als de IO-aanvraaggrootte echter kleiner is dan de stripegrootte en als deze willekeurig is, kunnen de IO-aanvragen zich op dezelfde schijf bevinden die een knelpunt veroorzaken en uiteindelijk de IO-prestaties verminderen.

Afhankelijk van het type workload dat uw toepassing uitvoert, kiest u een geschikte stripegrootte. Gebruik een kleinere stripegrootte voor willekeurige kleine IO-aanvragen. Terwijl voor grote opeenvolgende IO-aanvragen een grotere stripegrootte wordt gebruikt. Bekijk de aanbevelingen voor de stripegrootte voor de toepassing die u gaat uitvoeren in Premium Storage. Configureer voor SQL Server de stripegrootte van 64 kB voor OLTP-workloads en 256 kB voor datawarehousingworkloads. Zie best practices voor prestaties voor SQL Server op Virtuele Azure-machines voor meer informatie.

Notitie

U kunt maximaal 32 Premium-opslagschijven op een VM uit de DS-serie en 64 Premium-opslagschijven op een VM uit de GS-serie stripen.

Multithreading

Azure heeft een Premium Storage-platform ontworpen om enorm parallel te zijn. Daarom bereikt een toepassing met meerdere threads veel hogere prestaties dan een toepassing met één thread. Een toepassing met meerdere threads splitst de taken op in meerdere threads en verhoogt de efficiëntie van de uitvoering door gebruik te maken van de VM- en schijfbronnen tot het maximum.

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

Mogelijk kunt u de manier waarop een kant-en-klare toepassing één threading of multithreading 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. Er kunnen query's worden uitgevoerd en indexen worden gebouwd met behulp van meerdere threads. Voor een query die bestaat uit het samenvoegen van grote tabellen en het sorteren van gegevens voordat u terugkeert naar de gebruiker, gebruikt SQL Server waarschijnlijk meerdere threads. Een gebruiker kan echter niet bepalen of SQL Server een query uitvoert met éé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 dat SQL Server kan gebruiken bij parallelle verwerking. U kunt MAXDOP configureren voor afzonderlijke query's of indexbewerkingen. Dit is handig als u resources van uw systeem wilt verdelen voor een kritieke toepassing voor prestaties.

Stel dat uw toepassing met BEHULP van 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 dat geval kunt u de MAXDOP-waarde van de indexbewerking instellen op een hogere waarde 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 bepaalt hoeveel threads SQL Server voor elke bewerking zal gebruiken. U kunt bepalen hoeveel processors er maximaal zijn toegewezen voor multithreading.

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

Wachtrijdiepte

De wachtrijdiepte of wachtrijlengte of wachtrijgrootte is het aantal in behandeling zijnde IO-aanvragen in het systeem. De waarde van wachtrijdiepte bepaalt hoeveel IO-bewerkingen uw toepassing kan uitlijnen, die de opslagschijven verwerken. Dit is van invloed op alle drie de prestatie-indicatoren voor toepassingen die we in dit artikel hebben besproken: viz., 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 threading. Als de wachtrijdiepte klein is, zelfs als de toepassing meerdere threads bevat, zijn er onvoldoende aanvragen opgesteld voor gelijktijdige uitvoering.

Normaal gesproken staat u niet toe dat u de wachtrijdiepte van de plank kunt wijzigen, omdat als deze onjuist is ingesteld, er meer kwaad dan goed wordt gedaan. Toepassingen stellen de juiste waarde van wachtrijdiepte in om de optimale prestaties te verkrijgen. Het is echter belangrijk om dit concept te begrijpen, zodat u prestatieproblemen met uw toepassing kunt oplossen. U kunt ook de effecten van wachtrijdiepte bekijken 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 parallelle uitvoering) in SQL Server, zoals uitgelegd in de vorige sectie. MAXDOP is een manier om de wachtrijdiepte en multithreading te beïnvloeden, hoewel de waarde wachtrijdiepte van SQL Server niet rechtstreeks wordt gewijzigd.

Hoge wachtrijdiepte
Een hoge wachtrijdiepte belijnt meer bewerkingen op de schijf. 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 IOS'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 maximale doorvoer bereiken met 8-16+ openstaande IOS's per gekoppelde schijf. Als een wachtrijdiepte één is, pusht de toepassing niet voldoende IOS naar het systeem en verwerkt deze minder hoeveelheid in een bepaalde periode. Met andere woorden, minder doorvoer.

Stel bijvoorbeeld in SQL Server de MAXDOP-waarde voor een query in op '4' geeft SQL Server aan dat deze maximaal vier kernen kan gebruiken om de query uit te voeren. SQL Server bepaalt wat de beste waarde voor de diepte van de wachtrij en het aantal kernen voor de queryuitvoering is.

Optimale wachtrijdiepte
Zeer hoge waarde voor wachtrijdiepte heeft ook de nadelen. Als de waarde voor de wachtrijdiepte te hoog is, probeert de toepassing zeer hoge IOPS te sturen. Tenzij de toepassing permanente schijven met voldoende ingerichte IOPS heeft, kan dit een negatieve invloed hebben op de latentie van toepassingen. In de volgende formule ziet u de relatie tussen IOPS, latentie en wachtrijdiepte.
A diagram showing the equation I O P S times latency equals Queue Depth.

U moet Queue Depth 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 latenties. Als de latentie van de toepassing bijvoorbeeld 1 milliseconden moet zijn, is de wachtrijdiepte vereist om 5.000 IOPS te bereiken, QD = 5000 x 0,001 = 5.

Wachtrijdiepte voor gestreept volume
Behoud voor een gestreept volume een hoge wachtrijdiepte, zodat elke schijf afzonderlijk een piekwachtrijdiepte heeft. Denk bijvoorbeeld aan een toepassing die een wachtrijdiepte van 2 pusht en er vier schijven in de stripe staan. De twee IO-aanvragen worden naar twee schijven verzonden 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.
A diagram showing the equation Q D per Disk times number of columns per volume equals Q D of Striped Volume.

Beperking

Azure Premium Storage richt het opgegeven aantal IOPS en doorvoer in, afhankelijk van de VM-grootten en schijfgrootten die u kiest. Wanneer uw toepassing IOPS of doorvoer probeert te sturen boven deze limieten van wat de VIRTUELE machine of schijf kan verwerken, wordt deze beperkt door Premium Storage. Dit manifesteert in de vorm van verminderde prestaties in uw toepassing. Dit kan leiden tot hogere latentie, lagere doorvoer of lagere IOPS. Als Premium Storage niet wordt beperkt, kan uw toepassing volledig mislukken door te overschrijden wat de resources kunnen bereiken. Om prestatieproblemen vanwege beperking te voorkomen, moet u altijd voldoende resources inrichten voor uw toepassing. Denk na over 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:

Meer informatie over de beschikbare schijftypen:

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