Azure Premium Storage: ontwerp voor hoge prestaties

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

Dit artikel bevat richtlijnen voor het bouwen van 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 de farm om de meeste prestaties te krijgen.

In dit artikel vindt u antwoorden op de volgende veelvoorkomende vragen over het optimaliseren van de prestaties van toepassingen 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 communiceren met 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 tijdens deze periode.

  • Werk het opslagtype bij.
  • Koppel een schijf los en koppel deze van de ene VM aan de andere.
  • Maak een beheerde schijf van 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 om de meest optimale prestaties te bereiken.

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

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 moeilijker kan zijn om de infrastructuur te wijzigen om de prestaties later te verbeteren.

Als u een bestaande toepassing hebt en wilt verplaatsen naar Premium Storage, bouwt u eerst de bovenstaande controlelijst voor de bestaande toepassing. 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 op de Premium Storage-schijven is gemaakt. 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 Description Perfmon I hef
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 probleemloos 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 de 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 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 de effecten van elke factor op de prestaties van uw toepassing wilt zien, moet u benchmarkinghulpprogramma'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 zware leesbewerkingen om een hogere Lees-IOPS te krijgen.   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 willekeurig klein I/O-patroon gezien in OLTP-toepassingen. Gebruik bijvoorbeeld een stripegrootte van 64 kB voor SQL Server OLTP-toepassing. Grotere stripegrootte voor sequentieel groot I/O-patroon 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 een SQL Server 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. Het identificeren van de aard van I/O-aanvragen, willekeurig of sequentieel, lezen of schrijven, klein of groot, helpt u bij het bepalen van de prestatievereisten van uw toepassing. 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 vuistregel 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 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 zijn van de I/O-grootte 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-kern-verhouding en een Solid-State Drive (SSD) voor de lokale schijf. Voorbeelden van grootschalige VM's die Premium Storage 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

Als u een volledige lijst met alle beschikbare VM-grootten van Azure wilt weergeven, raadpleegt u Grootten voor virtuele machines in Azure. Kies een VM-grootte die kan voldoen aan en kan worden geschaald 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 behulp van 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 voldoen aan de vereiste van 16.000 IOPS 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 voor 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 een 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 de vereisten van uw toepassing. Bij het maken van de keuze moet u rekening houden met de onderstaande overwegingen.

Schaallimieten (IOPS en doorvoer)
De limieten voor IOPS en doorvoer 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/sec 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 het groter of groter maken naar P40 of P50.

Notitie

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

In eerste instantie zijn de lees- en schrijfmische gegevens 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-informatie 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 meestal twee keer zoveel 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 dan 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, BlobCache genaamd. BlobCache maakt gebruik van een combinatie van het RAM-geheugen van de host en de 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 Alleen-lezen 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

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 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. Het niet volgen van deze aanbevelingen kan leiden tot beschadiging van gegevens.

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

Het is belangrijk om cache in teschakelen op de juiste set schijven. Of u schijf-caching op een Premium-schijf moet inschakelen 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 Alleen-lezen voor schijven met alleen-lezen en lezen/schrijven.
ReadWrite Configureer hostcache alleen als ReadWrite als uw toepassing het schrijven van gegevens in de cache naar permanente schijven op de juiste manier 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 lees-IOPS en doorvoer voor uw toepassing krijgen. Dit heeft twee oorzaken:

  1. Lees lezen uit 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-IOPS en doorvoer van de schijf mee die vanuit de cache worden bediend. 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. De SQL Server bijvoorbeeld zelf het schrijven van gegevens in de cache naar de permanente opslagschijven. 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 gehost.
    a. De snelle leesgegevens uit de cache verlagen de SQL Server querytijd omdat gegevenspagina's veel sneller uit de cache worden opgehaald in vergelijking met rechtstreeks van de gegevensschijven.
    b. Het 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 de cache Geen 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 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.
  • Voor ext3/ext4 gebruikt u 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 nobarrierkoppeling 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 de wijzigingen in een distributierele release echter mogelijk teruggeport naar een eerdere kernelversie. Neem contact op met de leverancier van uw distributie voor de status in de distributie en versie die u gebruikt.

Schijfstriping

Wanneer een grootschalige VM is gekoppeld aan verschillende permanente schijven van 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 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-eenheid 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 werkbelasting 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 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 tot het maximum 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 bij parallelle verwerking kan gebruiken. 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 het kan gebruiken voor de indexbewerking in vergelijking met het aantal processors dat kan worden besteed aan de grote query. Vergeet niet dat u niet het aantal threads hebt 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 dergelijke instellingen die van invloed zijn op multithreading in uw toepassing en hun configuraties om de prestaties te optimaliseren.

Wachtrijdiepte

De wachtrijlengte of wachtrijlengte of wachtrijgrootte is het aantal I/O-aanvragen in behandeling 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 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 breedte) 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 gewijzigd SQL Server.

Hoge wachtrijdiepte
Met een hoge wachtrijdiepte worden meer bewerkingen op de schijf uitgevoerd. De schijf kent van tevoren de volgende aanvraag in de wachtrij. Als gevolg daarvan kan de schijf bewerkingen van tevoren plannen en deze in een optimale volgorde verwerken. Omdat de toepassing meer aanvragen naar de schijf stuurt, 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 de diepte van een wachtrij er één is, pusht de toepassing onvoldoende IO's naar het systeem en wordt in een bepaalde periode minder IO's verwerkt. Met andere woorden, minder doorvoer.

Als u in SQL Server bijvoorbeeld de 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 waarde voor wachtrijdiepte 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 nodig is om 5000 IOPS te bereiken, 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: