Azure Premium Storage: ontwerp voor hoge prestaties

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

In dit artikel worden prestatiescenario's voor Storage laag beschreven, maar u moet de toepassingslaag optimaliseren. Als u bijvoorbeeld een SharePoint Farm op Azure Premium Storage host, kunt u de SQL Server-voorbeelden in dit artikel gebruiken om de databaseserver te optimaliseren. Daarnaast optimaliseert u de SharePoint webserver en toepassingsserver van farm om de meeste prestaties te krijgen.

In dit artikel vindt u antwoorden op de volgende veelvoorkomende vragen over het optimaliseren van toepassingsprestaties in Azure Premium Storage,

  • De prestaties van uw toepassing meten
  • Waarom ziet u geen verwachte hoge prestaties?
  • Welke factoren zijn van invloed op de prestaties van uw 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, omdat workloads die worden uitgevoerd op Premium Storage zeer prestatiegevoelig zijn. Waar van toepassing hebben we 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 een probleem met de schijfprestaties een knelpunt in het netwerk. In deze situaties moet u de netwerkprestaties optimaliseren.

Als u een benchmark voor uw schijf wilt gebruiken, bekijkt u onze artikelen over het benchmarken 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 op zowel Windows als Linux.

Lees voordat u begint, als u nog geen Premium Storage, eerst Azure-schijftype selecteren voor IaaS-VM's en schaalbaarheidsdoelen voor Premium-pagina-blobopslagaccounts.

Indicatoren voor toepassingsprestaties

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 verwerkt per aanvraag, hoeveel aanvragen een toepassing in een bepaalde periode verwerkt, hoe lang een gebruiker moet wachten om een reactie te krijgen nadat de aanvraag is 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, Toepassingsvereisten verzamelen, leert u hoe u deze prestatie-indicatoren meet voor uw toepassing. Later in Optimizeing Application Performance (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 verstuurt. Een invoer-/uitvoerbewerking kan lezen of schrijven, sequentieel of willekeurig zijn. OLTP-toepassingen (Online Transaction Processing), zoals een onlinewinkelwebsite, 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 I/O-aanvragen. Als u een dergelijke toepassing hebt, moet u de toepassingsinfrastructuur ontwerpen om te optimaliseren voor IOPS. In de latere sectie Optimalisatie van toepassingsprestaties worden alle factoren besproken die u moet overwegen 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 stuurt. Als uw toepassing invoer-/uitvoerbewerkingen met grote I/O-eenheden voert, is een hoge doorvoer vereist. Datawarehouse-toepassingen voeren vaak scanintensieve bewerkingen uit die tegelijkertijd toegang hebben tot grote delen van gegevens 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, wordt de doorvoer in Azure op basis van die schijfspecificatie ingemaakt. 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.

Relatie van IOPS en doorvoer

Daarom is het belangrijk om de optimale doorvoer en IOPS-waarden te bepalen die uw toepassing vereist. Wanneer u een optimalisatie probeert uit te proberen, wordt de andere ook beïnvloed. In een latere sectie, Optimalisatie van toepassingsprestaties, wordt meer informatie besproken 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 essentiële 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 sturen naar uw toepassing. Premium Storage biedt consistente lage latentie. Premium Schijven zijn ontworpen om latentie van slechts enkele milliseconden te bieden voor de meeste I/O-bewerkingen. Als u LezenOnly-host-caching op Premium Storage-schijven inschakelen, kunt u een veel lagere leeslatentie krijgen. Schijfprestaties worden uitgebreid Caching in latere sectie over Het optimaliseren van toepassingsprestaties.

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

De volgende besturingsvlakbewerkingen op Managed Disks mogelijk verplaatsing van de schijf van de ene Storage locatie naar een andere. Dit wordt uitgevoerd via een achtergrondkopie van gegevens die enkele uren in beslag kunnen nemen, 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 leesgegevens kunnen worden omgeleid naar de oorspronkelijke locatie en het langer kan duren om te voltooien. Er is geen invloed op de schrijflatentie gedurende deze periode.

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

Controlelijst voor prestatietoepassing voor schijven

De eerste stap bij het ontwerpen van hoogwaardige toepassingen die worden uitgevoerd op Azure Premium Storage is inzicht in de prestatievereisten van uw toepassing. Nadat u prestatievereisten hebt verzameld, kunt u uw toepassing optimaliseren voor de beste prestaties.

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 is bijvoorbeeld het belangrijkst voor OLTP-toepassingen die miljoenen transacties in een seconde verwerken. Hoewel hoge doorvoer essentieel is voor het Data Warehouse toepassingen die grote hoeveelheden gegevens in een seconde verwerken. Extreem lage latentie is van cruciaal belang voor realtime toepassingen zoals websites voor live videostreaming.

Meet vervolgens de maximale prestatievereisten van uw toepassing gedurende de levensduur. Gebruik de voorbeeldcontrolelijst hieronder als start. De maximale prestatievereisten registreren tijdens normale, piek- en daluren workloadperioden. Door de vereisten voor alle workloadniveaus te identificeren, kunt u de algehele prestatievereiste van uw toepassing bepalen. De normale workload van een e-commercewebsite zijn bijvoorbeeld de transacties die gedurende de meeste dagen in een jaar worden gebruikt. De piekworkload van de website zijn de transacties die worden gebruikt tijdens feestdagen of speciale verkoopgebeurtenissen. De piekworkload wordt doorgaans voor een beperkte periode ervaren, maar kan vereisen dat uw toepassing twee of meer keer de normale werking ervan schaalt. Ontdek de vereisten voor 50 percentiel, 90 percentiel en 99 percentiel. Zo kunt u eventuele uitschieters in de prestatievereisten wegfilteren en kunt u zich richten op het optimaliseren voor de juiste waarden.

Controlelijst voor vereisten voor toepassingsprestaties

Prestatievereisten 50 percentiel 90 percentiel 99 percentiel
Met maximaal Transacties per seconde
% leesbewerkingen
% schrijfbewerkingen
% willekeurige bewerkingen
% sequentiële bewerkingen
Grootte van I/O-aanvraag
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 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 verplaatsen naar Premium Storage, moet u eerst de bovenstaande controlelijst voor de bestaande toepassing maken. Bouw vervolgens een prototype van uw toepassing op Premium Storage en ontwerp de toepassing op basis van de richtlijnen die worden beschreven in Optimalisatie van toepassingsprestaties in een latere sectie van dit document. In het volgende artikel worden de hulpprogramma's beschreven die u kunt gebruiken om de prestatiemetingen te verzamelen.

Prestatiemeters voor toepassingen meten

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 gebruiken voor Windows en imostt voor Linux. Deze hulpprogramma's leggen tellers vast die overeenkomen met elke meting die in de bovenstaande sectie wordt uitgelegd. U moet de waarden van deze tellers vastleggen wanneer de normale workloads, piek- en buitenuren van uw toepassing worden uitgevoerd.

De PerfMon-tellers zijn beschikbaar voor de processor, het geheugen en, elke logische schijf en fysieke schijf van uw server. Wanneer u Premium Storage-schijven met een VM gebruikt, zijn de fysieke schijftellers voor elke Premium Storage-schijf en logische schijftellers voor elk volume dat is gemaakt op de Premium Storage-schijven. U moet de waarden vastleggen voor de schijven die uw toepassingsworkload hosten. 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 opdracht ibaret een rapport over CPU- en schijfgebruik. Het rapport schijfgebruik bevat statistieken per fysiek apparaat of partitie. Als u een databaseserver hebt met de 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 Beschrijving Perfmon I door
IOPS of transacties per seconde Aantal I/O-aanvragen dat is uitgegeven aan de opslagschijf per seconde. Lees- en lees lezen per seconde van schijf
Schrijf- en schrijf sec.
Tps
r/s
w/s
Lees- en schrijf- en schrijfingen op schijf % van de lees- en schrijfbewerkingen die op de schijf worden uitgevoerd. Leestijd % schijf
% schrijftijd schijf
r/s
w/s
Doorvoer De hoeveelheid gegevens die per seconde van de schijf wordt gelezen of naar de schijf wordt geschreven. Gelezen bytes per seconde schijf
Geschreven bytes per seconde schijf
kB_read/s
kB_wrtn/s
Latentie Totale tijd voor het voltooien van een I/O-aanvraag voor de schijf. Gemiddelde schijf sec/lezen
Gemiddelde schijf sec/write
Wachten
svctm
I/O-grootte De grootte van I/O-aanvragen heeft betrekking op de opslagschijven. Gemiddelde schijf bytes/lezen
Gemiddelde schijf bytes/schrijven
avgrq-sz
Wachtrijdiepte Aantal openstaande I/O-aanvragen dat wacht op lezen van of naar de opslagschijf worden geschreven. Wachtrijlengte huidige schijf avgqu-sz
Maximaal geheugen De hoeveelheid geheugen die nodig is om de toepassing probleemloos uit te voeren Percentage toegewezen bytes in gebruik VMstat gebruiken
Max. CPU De hoeveelheid CPU die nodig is om de toepassing soepel uit te voeren % processortijd %util

Meer informatie over imostt en PerfMon.

Prestaties van toepassingen optimaliseren

De belangrijkste factoren die van invloed zijn op de prestaties van een toepassing die wordt uitgevoerd op Premium Storage zijn aard van I/O-aanvragen, VM-grootte, schijfgrootte, aantal schijven, schijf caching, multithreading en wachtrijdiepte. U kunt een aantal van deze factoren bepalen met knoppen die door het systeem worden geleverd. De meeste toepassingen bieden u mogelijk geen optie om de I/O-grootte en wachtrijdiepte rechtstreeks te wijzigen. Als u bijvoorbeeld een SQL Server, kunt u de I/O-grootte en wachtrijdiepte niet kiezen. SQL Server kiest de optimale I/O-grootte en wachtrijdieptewaarden om de meeste 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 van deze informatie kunt u bepalen welke factoren in deze sectie u moet afstemmen. Als u wilt zien wat de gevolgen van elke factor zijn voor de prestaties van uw toepassing, moet u benchmarking-hulpprogramma's uitvoeren voor de installatie van uw toepassing. Raadpleeg het aan het einde gekoppelde artikel Benchmarking voor stappen voor het uitvoeren van algemene hulpprogramma's voor benchmarking op Windows 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 dieper beschreven.

Zie Grootten voor virtuele machines in Azurevoor 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 een zeer hoge snelheid van transacties per seconde. Enterprise Datawarehousing-toepassing verwerkt grote hoeveelheden gegevens. Toepassingen die bijna in realtime worden gebruikt, vereisen directe reacties op aanvragen van gebruikers, zoals online gaming.
Prestatiefactoren      
I/O-grootte Een kleinere I/O-grootte levert een hogere IOPS op. Grotere I/O-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 vereisten van uw toepassing. Gebruik een VM-grootte die schaallimieten biedt die groter zijn dan de vereisten van uw toepassing.
Schijfgrootte Gebruik een schijfgrootte die IOPS biedt die groter is dan uw toepassingsvereiste. 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 uw toepassingsvereiste.
VM- en schijfschaallimieten De IOPS-limiet van de gekozen VM-grootte moet groter zijn dan de totale IOPS die wordt aangestuurd door de 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.
Schijf Caching Schakel ReadOnly Cache in op Premium Storage-schijven met leesbewerkingen voor een hogere Lees-IOPS.   Schakel ReadOnly Cache in op Premium Storage-schijven met ready heavy-bewerkingen om een zeer lage leeslatentie te krijgen.
Schijf-striping Gebruik meerdere schijven en stripe 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 stripegrootte voor willekeurige kleine I/O-patroon gezien in OLTP-toepassingen. Gebruik bijvoorbeeld stripegrootte van 64 kB voor SQL Server OLTP-toepassing. Grotere stripegrootte voor sequentieel groot I/O-patroon dat wordt gezien in Data Warehouse toepassingen. Gebruik bijvoorbeeld een stripegrootte van 256 kB voor SQL Server datawarehouse-toepassing.  
Multithreading Gebruik multithreading om een hoger aantal aanvragen te pushen naar Premium Storage die leiden tot 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 levert lagere latentie op.

Aard van I/O-aanvragen

Een I/O-aanvraag is een eenheid van de invoer-/uitvoerbewerking die uw toepassing gaat uitvoeren. Als u de aard van I/O-aanvragen, willekeurig of sequentieel, lezen of schrijven, klein of groot, identificeert, kunt u de prestatievereisten van uw toepassing bepalen. Het is belangrijk om inzicht te krijgen in de aard van I/O-aanvragen, om de juiste beslissingen te nemen bij het ontwerpen van uw toepassingsinfrastructuur. IO's moeten gelijkmatig worden gedistribueerd om de best mogelijke prestaties te bereiken.

I/O-grootte is een van de belangrijkste factoren. De I/O-grootte is de grootte van de aanvraag voor de invoer-/uitvoerbewerking die door uw toepassing wordt gegenereerd. De I/O-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.
Een diagram met de vergelijking I O P S keer I O-grootte is gelijk aan doorvoer.

Met sommige toepassingen kunt u de I/O-grootte wijzigen, terwijl sommige toepassingen dat niet doen. De SQL Server bepaalt bijvoorbeeld de optimale I/O-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, waardoor u de I/O-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 I/O-aanvragen. Als u deze typen I/O-aanvragen wilt verwerken, moet u uw toepassingsinfrastructuur ontwerpen om een hogere IOPS te krijgen.
  • Een datawarehousingtoepassing genereert grote en sequentiële I/O-aanvragen. Als u deze typen I/O-aanvragen wilt verwerken, moet u uw toepassingsinfrastructuur ontwerpen om een hogere bandbreedte of doorvoer te krijgen.

Als u een toepassing gebruikt waarmee u de I/O-grootte kunt wijzigen, gebruikt u deze thumb-regel voor de I/O-grootte naast andere prestatierichtlijnen.

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

Hier ziet u 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 I/O-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 I/O-grootte gebruikt, zoals 1024 kB, is de resulterende IOPS minder, 200 IOPS. Stem daarom de I/O-grootte zodanig af dat deze voldoet aan zowel de IOPS- als doorvoer-/bandbreedtevereiste van uw toepassing. De volgende tabel bevat een overzicht van de verschillende I/O-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
Max. IOPS + hoge doorvoer 32 kB 5.000 160 MB per seconde

Als u de IOPS en bandbreedte hoger wilt maken dan de maximumwaarde van één Premium Storage-schijf, gebruikt u meerdere Premium-schijven die samen zijn gestriped. 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, verhoogt de andere ook, zorg er dan voor dat u de doorvoer- of IOPS-limieten van de schijf of VM niet bereikt wanneer u een van beide verhoogt.

Als u wilt zien wat de gevolgen van de I/O-grootte zijn voor de prestaties van toepassingen, kunt u benchmarking-hulpprogramma's uitvoeren op uw VM en schijven. Maak meerdere testruns en gebruik voor elke run een andere I/O-grootte om de impact te bekijken. Raadpleeg het aan het einde gekoppelde artikel Benchmarking voor meer informatie.

Grootschalige VM-grootten

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 worden geleverd met grootschalige VM-grootten die toepassingen kunnen uitvoeren waarvoor meer rekenkracht en een hoge I/O-prestaties van de lokale schijf zijn vereist. Deze VM's bieden snellere processors, een hogere geheugen-naar-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.

Schaalbare VM's 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 VM kunt koppelen. Daarom heeft de gekozen VM-grootte invloed op de verwerkings-, geheugen- en opslagcapaciteit die beschikbaar is voor uw toepassing. Het is ook van invloed op de compute- en Storage kosten. Hieronder vindt 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

Raadpleeg Grootten voor virtuele machines in Azure of voor een volledige lijst met alle beschikbare azure-VM-grootten. Kies een VM-grootte die kan voldoen aan en schaal naar de gewenste vereisten voor toepassingsprestaties. Daarnaast moet u rekening houden 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 aandrijt binnen de limieten van de VM en de Premium-schijven die eraan zijn gekoppeld. Anders worden de prestaties van de toepassing tegen beperkingen gebruikt.

Stel bijvoorbeeld dat een toepassingsvereiste maximaal 4000 IOPS is. Hiervoor moet u een P30-schijf inrichten op een DS1-VM. De P30-schijf kan maximaal 5000 IOPS leveren. De DS1-VM is echter beperkt tot 3200 IOPS. Hierdoor worden de prestaties van de toepassing beperkt door de VM-limiet van 3200 IOPS en zullen de prestaties verslechteren. Als u deze situatie wilt voorkomen, kiest u een VM en schijfgrootte die beide voldoen aan de toepassingsvereisten.

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

Denk bijvoorbeeld aan een toepassing die 16.000 IOPS vereist. Voor deze prestaties hebt u een Standard _ D14 Azure IaaS-VM nodig, die maximaal 16.000 IOPS kan bieden met 32 Standard-opslagschijven 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 Standard-opslagschijven zijn $ 1638. De geschatte totale maandelijkse kosten zijn $ 3208.

Als u echter dezelfde toepassing op Premium Storage gehost, hebt u een kleinere VM-grootte en minder Premium Storage-schijven nodig, waardoor de totale kosten worden verkleind. Een Standard _ DS13-VM kan aan de 16.000 IOPS-vereisten voldoen 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. In totaal kan deze configuratie 5000 x 4 = 20.000 IOPS bereiken. De geschatte kosten van deze VM per maand zijn $ 1003. De maandelijkse kosten voor vier P30 Premium Storage-schijven zijn $ 544,34. De geschatte totale maandelijkse kosten zijn $ 1.544.

De onderstaande tabel bevat een overzicht van de kostenuitsplitsing 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 VM's met Windows 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 waar uw workload op wordt uitgevoerd. Test de Linux-distributies met uw toepassing en kies de distributie die het beste werkt.

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

Premium opslagschijfgrootten

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 grootschalige VM-grootte. In de onderstaande tabel ziet u de grootten van de schijven en de 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

*Is alleen van toepassing op schijven met bursting op aanvraag 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. Bij het maken van de keuze moet u rekening houden met de onderstaande overwegingen.

Schaallimieten (IOPS en doorvoer)
De IOPS- en doorvoerlimieten van 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 liggen.

Bijvoorbeeld als een toepassingsvereiste een maximale doorvoer van 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 opgeven. Eén P30-schijf heeft echter een doorvoerlimiet van 200 MB per seconde. Als gevolg van de schijflimiet wordt de toepassing beperkt tot 200 MB per seconde. Als u deze limiet wilt overschrijden, moet u meer dan één gegevensschijf inrichten op de VM of de schijf groter of groter maken dan P40 of P50.

Notitie

Lees lezen die worden verwerkt door de cache zijn niet opgenomen in de schijf-IOPS en doorvoer, dus niet onderhevig aan schijflimieten. De cache heeft een afzonderlijke IOPS- en doorvoerlimiet per VM.

In eerste instantie zijn uw lees- en schrijfmingen bijvoorbeeld respectievelijk 60 MB per seconde en 40 MB per seconde. Na een periode wordt de cache opgewarmd en worden er steeds meer lees- en lees lezen 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 toepassingsvereisten te beoordelen. Elke VM-grootte heeft ook een limiet voor het aantal schijven dat u aan de VM kunt koppelen. Dit is doorgaans twee keer het aantal kernen. Zorg ervoor dat de VM-grootte die u kiest het aantal benodigde schijven kan ondersteunen.

Vergeet niet dat Premium Storage schijven betere prestatiemogelijkheden hebben in vergelijking met Standard Storage schijven. Dus als u uw toepassing migreert van een 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 cachingtechnologie met meerdere lagen met de naam BlobCache. BlobCache maakt gebruik van een combinatie van het host-RAM-geheugen en lokale SSD voor caching. Deze cache is beschikbaar voor de Premium Storage schijven en de lokale schijven van de VM. Deze cache-instelling is standaard ingesteld op Lezen/schrijven voor besturingssysteemschijven en ReadOnly voor gegevensschijven die worden gehost op Premium Storage. Als schijf-caching is ingeschakeld op de Premium Storage schijven, kunnen de grootschalige VM's zeer hoge prestatieniveaus bereiken die de onderliggende schijfprestaties overschrijden.

Waarschuwing

Schijf 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 verandert, wordt de doelschijf losgekoppeld en opnieuw gekoppeld. Als dit de besturingssysteemschijf 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 gegevens.

Raadpleeg de blogpost Inside Azure Premium Storage (Inside Azure Premium Storage) voor meer informatie over hoe BlobCache werkt.

Het is belangrijk dat de cache op de juiste set schijven wordt ingeschakeld. Of u schijf caching 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 Standaardcache-instelling
Besturingssysteemschijf ReadWrite
Gegevensschijf ReadOnly

Hieronder volgen de aanbevolen schijfcache-instellingen voor gegevensschijven,

Instelling voor schijf caching aanbeveling voor het gebruik van deze instelling
Geen Configureer de hostcache als Geen voor schijven met alleen-schrijven en schrijfzware schijven.
ReadOnly Configureer hostcache als ReadOnly voor schijven met alleen-lezen en lezen/schrijven.
ReadWrite Configureer de hostcache alleen als ReadWrite als uw toepassing op de juiste wijze het schrijven van gegevens in de cache naar permanente schijven verwerkt wanneer dat nodig is.

Readonly
Door ReadOnly-caching te configureren op Premium Storage-gegevensschijven, kunt u een lage leeslatentie bereiken en een zeer hoge IOPS en doorvoer voor lezen voor uw toepassing krijgen. Dit heeft twee oorzaken:

  1. Lees lezen die worden uitgevoerd vanuit de cache, die zich op het VM-geheugen en de lokale SSD, zijn veel sneller dan leesgegevens van de gegevensschijf, die zich in de Azure Blob-opslag.
  2. Premium Storage telt niet de lees- en doorvoer van de schijf-IOPS en doorvoer mee. Daarom kan uw toepassing een hogere totale IOPS en doorvoer bereiken.

Readwrite
Op de besturingssysteemschijven is readWrite-caching standaard 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. Zo worden SQL Server het schrijven van gegevens in de cache naar de permanente opslagschijven zelf verwerkt. Het gebruik van ReadWrite-cache met een toepassing die het persistent maken van de vereiste gegevens niet verwerkt, kan leiden tot gegevensverlies als de VM vast loopt.

Geen
Op dit moment wordt Geen alleen ondersteund op gegevensschijven. Het wordt niet ondersteund op besturingssysteemschijven. Als u Geen in stelt op een besturingssysteemschijf, wordt dit intern overschrijven en ingesteld op ReadOnly.

U kunt deze richtlijnen bijvoorbeeld als volgt toepassen SQL Server op Premium Storage worden uitgevoerd:

  1. Configureer de ReadOnly-cache op Premium Storage-schijven die als host voor gegevensbestanden worden gebruikt.
    a. De snelle leesgegevens uit de cache verlagen de SQL Server querytijd omdat gegevenspagina's veel sneller worden opgehaald uit de cache in vergelijking met rechtstreeks van de gegevensschijven.
    b. Het verwerken van leesgegevens uit de cache betekent dat er extra doorvoer beschikbaar is via Premium-gegevensschijven. SQL Server kunt deze extra doorvoer gebruiken voor het ophalen van meer gegevenspagina's en andere bewerkingen, zoals back-up/herstel, batchladingen en herbouwen van indexen.
  2. Configureer geen cache op Premium Storage-schijven die als host voor de logboekbestanden worden gehost.
    a. Logboekbestanden hebben voornamelijk schrijfbewerkingen. Daarom profiteren ze niet van de ReadOnly-cache.

Prestaties optimaliseren op Linux-VM's

Voor alle Premium- of Ultra Disks-schijven 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 Azure Disk Caching 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 schrijfwerk 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 type bestandssysteem:

  • 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.
  • Gebruik voor ext3/ext4 de optie barrier=0 mount om barrières uit te schakelen. Als u expliciet barrières wilt inschakelen, gebruikt u barrier=1.
  • Voor XFS gebruikt u de optie nobarrier mount om barrières uit te schakelen. Als u expliciet barrières wilt inschakelen, gebruikt u barrière. In latere Linux-kernelversies zorgt het ontwerp van het XFS-bestandssysteem altijd voor duurzaamheid en heeft het uitschakelen van barrières geen effect.

Schijf striping

Wanneer een grootschalige VM is gekoppeld aan verschillende permanente schijven voor Premium Storage, kunnen de schijven worden gestriped om hun IOPS, bandbreedte en opslagcapaciteit te aggregeren.

Op Windows kunt u de Opslagruimten schijven samen 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 ongelijke verdeling van verkeer over de schijven.

Belangrijk: met Serverbeheer gebruikersinterface 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 stripe-set staan; geef 16 kolommen op in de parameter NumberOfColumns van de PowerShell-cmdlet New-VirtualDisk.

Gebruik in Linux het hulpprogramma MAIREM om schijven te stripen. Zie 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 stripegrootte of blokgrootte is de kleinste hoeveelheid gegevens die de toepassing op een striped volume. De stripegrootte die u configureert, is afhankelijk van het type toepassing en het aanvraagpatroon. Als u de verkeerde stripegrootte kiest, kan dit leiden tot een onjuiste uitlijning van IO, wat leidt tot slechtere prestaties van uw toepassing.

Als een I/O-aanvraag die door uw toepassing wordt gegenereerd bijvoorbeeld groter is dan de schijfstreegrootte, 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, moeten deze worden opgevraagd in meer dan één stripe-eenheden om de aanvraag te voltooien. Het cumulatieve effect van dergelijk gedrag kan leiden tot aanzienlijke prestatievermindering. Als de grootte van de I/O-aanvraag daarentegen kleiner is dan de stripe-grootte, en als deze willekeurig van aard is, kunnen de I/O-aanvragen op dezelfde schijf worden bij elkaar opgelopen, wat een knelpunt veroorzaakt en uiteindelijk de I/O-prestaties vernedeert.

Afhankelijk van het type workload dat uw toepassing wordt uitgevoerd, kiest u een geschikte stripegrootte. Gebruik voor willekeurige kleine I/O-aanvragen een kleinere stripegrootte. Bij grote sequentiële I/O-aanvragen wordt een grotere streep gebruikt. Ontdek de aanbevelingen voor stripe-grootte voor de toepassing die u gaat uitvoeren op Premium Storage. Configureer SQL Server stripegrootte van 64 kB voor OLTP-workloads en 256 kB voor datawarehousingworkloads. Zie Best practices voor prestaties voor SQL Server azure-VM's voor meer informatie.

Notitie

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

Multi-threading

Azure heeft Premium Storage platform zo ontworpen dat het enorm parallel loopt. Daarom realiseert een toepassing met meerdere threads veel betere prestaties dan een toepassing met één thread. Een toepassing met meerdere threads splitst de taken over meerdere threads en verhoogt de efficiëntie van de uitvoering door de VM en schijfresources maximaal te gebruiken.

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 de ene thread wacht op een schijf-I/O om te worden voltooid, 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, neemt de uitvoering verder af omdat elke kern taken parallel kan uitvoeren.

Het is mogelijk dat u de manier waarop een kant-en-klare toepassing één threading of meerdere threading implementeert, niet kunt wijzigen. Zo kan SQL Server meerdere CPU's en meerdere kernen verwerken. Er wordt echter SQL Server 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 samenvoegen en gegevens worden gesorteerd voordat ze naar de gebruiker worden SQL Server waarschijnlijk meerdere threads gebruikt. Een gebruiker kan echter niet bepalen of SQL Server 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 een SQL Server is dit bijvoorbeeld de maximale mate van parallelle uitvoering. Met deze instelling MAXDOP kunt u het maximum aantal processors configureren dat SQL Server kunt gebruiken bij parallelle verwerking. U kunt MAXDOP configureren voor afzonderlijke query's of indexbewerkingen. Dit is handig wanneer u resources van uw systeem wilt in balans brengen voor een toepassing die essentieel is voor prestaties.

Stel dat uw toepassing die gebruik SQL Server tegelijkertijd een grote query en een indexbewerking uitvoert. Laten we ervan uitgaan dat u wilt dat de indexbewerking beter presteert dan de grote query. In dat geval kunt u de MAXDOP-waarde van de indexbewerking instellen op hoger dan de MAXDOP-waarde voor de query. Op deze manier SQL Server meer processors die kunnen worden gebruikt voor de indexbewerking in vergelijking met het aantal processors dat kan worden besteed aan de grote query. U hebt geen controle over het aantal threads dat SQL Server voor elke bewerking wordt gebruikt. U kunt bepalen hoeveel processors er maximaal worden toegewezen voor multi-threading.

Meer informatie over Degrees of Parallelism in SQL Server. Ontdek deze instellingen die van invloed zijn op multithreading in uw toepassing en de configuraties ervan om de prestaties te optimaliseren.

Wachtrijdiepte

De wachtrijlengte of wachtrijlengte of wachtrijgrootte is het aantal I/O-aanvragen dat in behandeling is in het systeem. De waarde van wachtrijdiepte bepaalt hoeveel I/O-bewerkingen uw toepassing kan verwerken, welke opslagschijven worden verwerkt. Dit is van invloed op alle drie de indicatoren voor toepassingsprestaties die we in dit artikel hebben besproken, zoals: IOPS, doorvoer en latentie.

Wachtrijdiepte en multithreading zijn nauw verwant. De waarde Queue Depth geeft aan hoeveel multi-threading kan worden bereikt door de toepassing. Als de wachtrijdiepte groot is, kan de toepassing meer bewerkingen gelijktijdig uitvoeren, met andere woorden, meer multi-threading. Als de wachtrijdiepte klein is, zelfs als de toepassing meerdere threads heeft, worden er onvoldoende aanvragen in de wachtrij geplaatst voor gelijktijdige uitvoering.

Normaal gesproken kunt u de diepte van de wachtrij niet wijzigen als deze niet correct is ingesteld, omdat dit meer kwaad dan goed doet. Toepassingen stellen de juiste waarde voor de wachtrijdiepte in om de optimale prestaties te krijgen. Het is echter belangrijk om dit concept te begrijpen, zodat u prestatieproblemen met uw toepassing kunt oplossen. U kunt ook de gevolgen van wachtrijdiepte observeren door benchmarkinghulpprogramma's op uw systeem uit te werken.

Sommige toepassingen bieden instellingen om de wachtrijdiepte te beïnvloeden. Bijvoorbeeld de instelling MAXDOP (maximale mate van parallelle breedtegraad) in SQL Server in de vorige sectie is uitgelegd. MAXDOP is een manier om wachtrijdiepte en multi-threading te beïnvloeden, hoewel de waarde van Queue Depth niet rechtstreeks wordt SQL Server.

Hoge wachtrijdiepte
Met een grote wachtrijdiepte worden meer bewerkingen op de schijf uitgevoerd. De schijf kent de volgende aanvraag in de wachtrij van tevoren. Hierdoor kan de schijf bewerkingen van tevoren plannen en deze in een optimale volgorde verwerken. Omdat de toepassing meer aanvragen naar de schijf verstuurt, kan de schijf meer parallelle IO's verwerken. Uiteindelijk kan de toepassing hogere IOPS bereiken. Omdat de toepassing meer aanvragen verwerkt, neemt ook de totale doorvoer van de toepassing toe.

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

Als u bijvoorbeeld in SQL Server MAXDOP-waarde voor een query instelt op '4', informeert u SQL Server dat deze maximaal vier kernen kan gebruiken om de query uit te voeren. SQL Server bepaalt wat de beste wachtrijdieptewaarde is en het aantal kernen voor de uitvoering van de query.

Optimale wachtrijdiepte
Een zeer hoge wachtrijdiepte heeft ook nadelen. Als de waarde voor de wachtrijdiepte te hoog is, probeert de toepassing een zeer hoge IOPS te maken. Tenzij de toepassing permanente schijven heeft met voldoende inrichtende IOPS, kan dit een negatieve invloed hebben op de latentie van toepassingen. De volgende formule toont de relatie tussen IOPS, latentie en wachtrijdiepte.
Een diagram met de vergelijking I O P S times latency is gelijk aan Queue Depth.

U moet Queue Depth niet configureren op een hoge waarde, maar op 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 is vereist voor het bereiken van 5000 IOPS, QD = 5000 x 0,001 = 5.

Wachtrijdiepte voor striped volume
Voor een striped volume een wachtrijdiepte die hoog genoeg is, 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 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.
Een diagram met de vergelijking Q D per schijf maal aantal kolommen per volume is gelijk aan Q D van striped volume.

Beperking

Azure Premium Storage het opgegeven aantal IOPS en doorvoer, afhankelijk van de VM-grootten en schijfgrootten die u kiest. Steeds wanneer uw toepassing probeert IOPS of doorvoer boven deze limieten te krijgen van wat de VM of schijf kan verwerken, wordt Premium Storage beperkt. Dit manifesteert zich in de vorm van verslechteerde prestaties in uw toepassing. Dit kan een hogere latentie, lagere doorvoer of lagere IOPS betekenen. Als Premium Storage niet beperkt, kan uw toepassing volledig mislukken door te overschrijden wat de resources kunnen bereiken. Om prestatieproblemen vanwege bandbreedtebeperking te voorkomen, moet u dus altijd voldoende resources inrichten voor uw toepassing. Bekijk wat we hebben besproken in de bovenstaande secties VM-grootten en Schijfgrootten. Benchmarking is de beste manier om erachter te komen welke resources u nodig hebt om uw toepassing te hosten.

Volgende stappen

Als u een benchmark voor uw schijf wilt gebruiken, bekijkt 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: