Azure Premium Storage: ontwerpen voor hoge prestaties
Van toepassing op: ✔️ Virtuele Linux-machines voor Windows-VM's ✔️ ✔️ Flexibele schaalsets Uniform-schaalsets ✔️
Dit artikel bevat richtlijnen voor het bouwen van hoogwaardige toepassingen met behulp van Azure Premium Storage. U kunt de instructies in dit document gebruiken in combinatie met aanbevolen procedures voor prestaties die van toepassing zijn op technologieën die door uw toepassing worden gebruikt. Ter illustratie van de richtlijnen gebruiken we SQL Server die wordt uitgevoerd in Premium Storage als voorbeeld in dit document.
Hoewel we prestatiescenario's voor de opslaglaag in dit artikel aanpakken, moet u de toepassingslaag optimaliseren. Als u bijvoorbeeld een SharePoint-farm host in Premium Storage, kunt u de SQL Server-voorbeelden uit dit artikel gebruiken om de databaseserver te optimaliseren. U kunt ook de webserver en toepassingsserver van de SharePoint-farm optimaliseren om de meeste prestaties te verkrijgen.
Dit artikel helpt u bij het beantwoorden van de volgende veelgestelde vragen over het optimaliseren van toepassingsprestaties in Premium Storage:
- Hoe kunt u de prestaties van uw toepassing meten?
- Waarom ziet u geen verwachte hoge prestaties?
- Welke factoren zijn van invloed op de prestaties van uw toepassing op Premium Storage?
- Hoe beïnvloeden deze factoren de prestaties van uw toepassing in Premium Storage?
- Hoe kunt u optimaliseren voor invoer-/uitvoerbewerkingen per seconde (IOPS), bandbreedte en latentie?
We bieden deze richtlijnen specifiek voor Premium Storage, omdat workloads die worden uitgevoerd op Premium Storage zeer gevoelig zijn voor prestaties. We bieden waar nodig voorbeelden. U kunt ook enkele van deze richtlijnen toepassen op toepassingen die worden uitgevoerd op IaaS-VM's (Infrastructure as a Service) met standaardopslagschijven.
Notitie
Soms lijkt het een probleem met schijfprestaties te zijn, een netwerkknelpunt. In deze situaties moet u de netwerkprestaties optimaliseren.
Als u uw schijf wilt benchmarken, raadpleegt u de volgende artikelen:
- Voor Linux: Uw toepassing benchmarken in Azure Disk Storage
- Voor Windows: Benchmark a disk
Als uw VIRTUELE machine versneld netwerken ondersteunt, controleert u of deze is ingeschakeld. Als deze niet is ingeschakeld, kunt u deze inschakelen op al geïmplementeerde VM's in Zowel Windows als Linux.
Lees voordat u begint, als u geen toegang hebt tot Premium Storage, eerst een Azure-schijftype selecteren voor IaaS-VM's en schaalbaarheidsdoelen voor Premium-pagina-blobopslagaccounts.
Prestatie-indicatoren voor toepassingen
We beoordelen of een toepassing goed presteert of niet met behulp van prestatie-indicatoren zoals:
- Hoe snel een toepassing een gebruikersaanvraag verwerkt.
- Hoeveel gegevens een toepassing per aanvraag verwerkt.
- Hoeveel aanvragen een toepassing in een bepaalde periode verwerkt.
- Hoe lang een gebruiker moet wachten om een antwoord te krijgen nadat hij zijn aanvraag heeft ingediend.
De technische voorwaarden 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 sectie Prestatietoepassing controlelijst voor schijven leert u hoe u deze prestatie-indicatoren voor uw toepassing kunt meten. Verderop in De prestaties van toepassingen optimaliseren leert u meer over de factoren die van invloed zijn op deze prestatie-indicatoren en aanbevelingen om deze te optimaliseren.
IOPS
IOPS is het aantal aanvragen dat uw toepassing in één seconde naar opslagschijven verzendt. Een invoer-/uitvoerbewerking kan lezen of schrijven, opeenvolgend of willekeurig zijn. OLTP-toepassingen (Online Transaction Processing), zoals een onlinewinkelwebsite, moeten direct veel gelijktijdige gebruikersaanvragen verwerken. De gebruikersaanvragen zijn invoeg- en updateintensieve databasetransacties, die de toepassing snel moet verwerken. Daarom vereisen OLTP-toepassingen zeer hoge IOPS.
OLTP-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. Zie Prestaties van toepassingen optimaliseren voor meer informatie over alle factoren die u moet overwegen om hoge IOPS te verkrijgen.
Wanneer u een Premium Storage-schijf koppelt aan uw grootschalige VM, biedt Azure u een gegarandeerd aantal IOPS op basis van de schijfspecificatie. Een P50-schijf richt bijvoorbeeld 7500 IOPS in. Elke grootschalige VM-grootte heeft ook een specifieke IOPS-limiet die deze kan ondersteunen. Een standaard GS5 VM heeft bijvoorbeeld een limiet van 80.000 IOPS.
Doorvoer
Doorvoer of bandbreedte is de hoeveelheid gegevens die uw toepassing in een opgegeven interval naar de opslagschijven verzendt. Als uw toepassing invoer-/uitvoerbewerkingen met grote I/O-eenheidsgrootten uitvoert, is een hoge doorvoer vereist. Datawarehouse-toepassingen geven vaak scanintensieve bewerkingen uit die toegang hebben tot grote delen van gegevens tegelijk en vaak bulkbewerkingen uitvoeren. Met andere woorden, dergelijke toepassingen vereisen een hogere doorvoer. Als u een dergelijke toepassing hebt, moet u de infrastructuur ontwerpen om de doorvoer te optimaliseren. In de volgende sectie bespreken we de factoren die u moet afstemmen om deze optimalisatie te bereiken.
Wanneer u een Premium Storage-schijf koppelt aan een grootschalige VM, richt Azure de doorvoer in op basis van die schijfspecificatie. Een P50-schijf richt bijvoorbeeld 250 MB per seconde schijfdoorvoer in. Elke grootschalige VM-grootte heeft ook een specifieke doorvoerlimiet die kan worden ondersteund. Standard 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 volgende formule.
Het is belangrijk om de optimale doorvoer en IOPS-waarden te bepalen die uw toepassing nodig heeft. Wanneer u probeert de ene te optimaliseren, wordt de andere ook beïnvloed. Zie Prestaties van toepassingen optimaliseren voor meer informatie over het optimaliseren van IOPS en doorvoer.
Latentie
Latentie is de tijd die een toepassing nodig heeft om één aanvraag te ontvangen, naar opslagschijven te verzenden en het antwoord naar de client te verzenden. Latentie is een kritieke meting van de prestaties van een toepassing, naast IOPS en doorvoer. De latentie van een Premium Storage-schijf is de tijd die nodig is om de informatie voor een aanvraag op te halen en deze terug te communiceren met uw toepassing. Premium-opslag biedt consistent lage latenties. Premium-schijven zijn ontworpen voor latenties van één cijfer in milliseconden voor de meeste I/O-bewerkingen. Als u ReadOnly-hostcaching inschakelt op Premium Storage-schijven, kunt u veel lagere leeslatentie krijgen. Zie Schijfcache voor meer informatie over schijfcaching.
Wanneer u uw toepassing optimaliseert voor een hogere IOPS en doorvoer, is dit van 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 beheerde schijven kunnen betrekking hebben op het verplaatsen van de schijf van de ene opslaglocatie naar de andere. Deze verplaatsing wordt ingedeeld via de achtergrondkopie van gegevens, wat enkele uren kan duren. De tijd is doorgaans minder dan 24 uur, afhankelijk van de hoeveelheid gegevens in de schijven. Gedurende die tijd kan uw toepassing een hogere latentie ervaren dan de gebruikelijke leeslatentie, omdat sommige leesbewerkingen kunnen worden omgeleid naar de oorspronkelijke locatie en langer kunnen duren om te voltooien.
Er is tijdens deze periode geen effect op schrijflatentie. Voor Premium SSD v2 en Ultra Disks, als de schijf een 4K-sectorgrootte heeft, ervaart deze een hogere leeslatentie. Als de schijf een sectorgrootte van 512e heeft, ondervindt deze zowel een hogere lees- als schrijflatentie.
Besturingsvlakbewerkingen worden gebruikt om:
- Werk het opslagtype bij.
- Koppel een schijf los van de ene VM aan een andere.
- Een beheerde schijf maken op basis van een VHD.
- Maak een beheerde schijf op basis van een momentopname.
- Niet-beheerde schijven converteren naar beheerde schijven.
Controlelijst voor prestatietoepassingen voor schijven
De eerste stap bij het ontwerpen van toepassingen met hoge prestaties die worden uitgevoerd in 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 uitgelegd: IOPS, doorvoer en latentie. U moet bepalen welke van deze prestatie-indicatoren essentieel zijn voor uw toepassing om de gewenste gebruikerservaring te bieden. Hoge IOPS is bijvoorbeeld belangrijk voor OLTP-toepassingen die miljoenen transacties in een seconde verwerken. Hoge doorvoer is essentieel voor datawarehouse-toepassingen die grote hoeveelheden gegevens in een seconde verwerken. Extreem lage latentie is cruciaal voor realtime toepassingen zoals live videostreamingwebsites.
Meet vervolgens de maximale prestatievereisten van uw toepassing gedurende de hele levensduur. Gebruik de volgende voorbeeldcontrolelijst als begin. Noteer de maximale prestatievereisten tijdens normale, piek- en off-hour workloadperioden. Door vereisten voor alle workloadniveaus te identificeren, kunt u de algehele prestatievereiste van uw toepassing bepalen.
De normale werkbelasting van een e-commercewebsite is bijvoorbeeld de transacties die gedurende de meeste dagen in een jaar worden uitgevoerd. De piekbelasting van de website is de transacties die het dient tijdens vakantieseizoenen of speciale verkoopevenementen. De piekworkload wordt doorgaans gedurende een beperkte periode ervaren, maar kan vereisen dat uw toepassing twee of meer keer de normale werking ervan kan schalen. Ontdek de vereisten voor 50 percentiel, 90 percentiel en 99 percentiel. Deze informatie helpt bij het filteren van uitbijters in de prestatievereisten en u kunt zich richten op het optimaliseren van de juiste waarden.
Controlelijst voor toepassingsprestaties
| Prestatievereisten | 50 percentiel | 90 percentiel | 99 percentiel |
|---|---|---|---|
| Maximum aantal transacties per seconde | |||
| % leesbewerkingen | |||
| % schrijfbewerkingen | |||
| % willekeurige bewerkingen | |||
| % sequentiële bewerkingen | |||
| I/O-aanvraaggrootte | |||
| Gemiddelde doorvoer | |||
| Maximale doorvoer | |||
| Minimale latentie | |||
| Gemiddelde latentie | |||
| Maximale CPU | |||
| Gemiddeld CPU-gebruik | |||
| Maximumgeheugen | |||
| Gemiddeld geheugen | |||
| Wachtrijdiepte |
Notitie
Overweeg deze getallen te schalen op basis van de verwachte toekomstige groei van uw toepassing. Het is een goed idee om van tevoren te plannen voor groei, omdat het moeilijker kan zijn om de infrastructuur te wijzigen om de prestaties later te verbeteren.
Als u een bestaande toepassing hebt en wilt overstappen op Premium Storage, bouwt u eerst de voorgaande controlelijst voor de bestaande toepassing. Vervolgens bouwt u een prototype van uw toepassing in Premium Storage en ontwerpt u de toepassing op basis van richtlijnen die worden beschreven in De prestaties van de toepassing optimaliseren. In het volgende artikel worden de hulpprogramma's beschreven die u kunt gebruiken om de prestatiemetingen te verzamelen.
Prestatievereisten voor toepassingen meten
De beste manier om prestatievereisten van uw toepassing te meten, is het gebruik PerfMonvan -bewakingshulpprogramma's die worden geleverd door het besturingssysteem van de server. U kunt voor Windows en iostat Linux gebruikenPerfMon. Met deze hulpprogramma's worden meteritems vastgelegd die overeenkomen met elke meting die in de vorige sectie wordt uitgelegd. U moet de waarden van deze tellers vastleggen wanneer uw toepassing de normale, piek- en off-hour workloads uitvoert.
De PerfMon tellers zijn beschikbaar voor processor, geheugen en elke logische schijf en fysieke schijf van uw server. Wanneer u Premium Storage-schijven met een VIRTUELE machine gebruikt, zijn de fysieke schijfmeteritems voor elke Premium-opslagschijf en logische schijfmeteritems voor elk volume dat op de Premium Storage-schijven is gemaakt. U moet de waarden vastleggen voor de schijven waarop uw toepassingsworkload wordt gehost. Als er een een-op-een-toewijzing tussen logische en fysieke schijven is, kunt u verwijzen naar fysieke schijftellers. Raadpleeg anders de logische schijftellers.
In Linux genereert de iostat opdracht een rapport cpu- en schijfgebruik. Het rapport schijfgebruik bevat statistieken per fysiek apparaat of partitie. Als u een databaseserver met de bijbehorende gegevens en logboeken op afzonderlijke schijven hebt, verzamelt u deze gegevens voor beide schijven. In de volgende tabel worden tellers voor schijven, processors en geheugen beschreven.
| Prestatiemeteritem | Beschrijving | Perfmon | iostat |
|---|---|---|---|
| IOPS of transacties per seconde | Aantal I/O-aanvragen dat per seconde is uitgegeven aan de opslagschijf | Leesbewerkingen per seconde van schijf Schrijfbewerkingen per seconde |
Tps r/s w/s |
| Lees- en schrijfbewerkingen in de schijf | % van lees- en schrijfbewerkingen uitgevoerd op de schijf | Leestijd van schijf Schrijftijd van schijfpercentage |
r/s w/s |
| Doorvoer | Hoeveelheid gegevens die van of naar de schijf per seconde worden gelezen of geschreven | Bytes per seconde lezen van schijf Schrijfbytes per seconde van schijf |
kB_read/s kB_wrtn/s |
| Latentie | Totale tijd voor het voltooien van een I/O-aanvraag voor een schijf | Gemiddelde schijf sec/gelezen Gemiddelde schijf sec/write |
Wachten svctm |
| I/O-grootte | De grootte van I/O-aanvraagproblemen voor de opslagschijven | Gemiddelde schijfbytes/leesbewerking Gemiddelde schijfbytes/schrijfbewerking |
avgrq-sz |
| Wachtrijdiepte | Aantal openstaande I/O-aanvragen die wachten om te worden gelezen of geschreven naar de opslagschijf | Lengte van huidige schijfwachtrij | avgqu-sz |
| Maximumgeheugen | Hoeveelheid geheugen die nodig is om de toepassing soepel uit te voeren | Percentage doorgevoerde bytes in gebruik | Vmstat gebruiken |
| Maximale CPU | Hoeveelheid CPU die nodig is om de toepassing soepel uit te voeren | % processortijd | %util |
Meer informatie over iostat 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, schijfcaching, multithreading en wachtrijdiepte. U kunt enkele van deze factoren beheren 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 SQL Server gebruikt, 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 verkrijgen. Het is belangrijk om inzicht te krijgen in de effecten van beide typen factoren op de prestaties van uw toepassing, zodat u de juiste resources kunt inrichten om te voldoen aan de prestatiebehoeften.
Raadpleeg in deze sectie de controlelijst voor toepassingsvereisten die u hebt gemaakt om te bepalen hoeveel u nodig hebt om de prestaties van uw toepassing te optimaliseren. Op basis van de controlelijst 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, voert u benchmarkinghulpprogramma's uit voor de installatie van uw toepassing. Zie de benchmarkingartikelen aan het einde van dit document voor stappen voor het uitvoeren van algemene benchmarkprogramma's op Windows- en Linux-VM's.
IOPS, doorvoer en latentie in één oogopslag optimaliseren
De volgende 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 uitgebreider beschreven.
Zie Grootten voor virtuele machines in Azure voor meer informatie over VM-grootten en over de IOPS, doorvoer en latentie die beschikbaar zijn voor elk type VM.
| Prestatiefactoren | IOPS | Doorvoer | Latentie |
|---|---|---|---|
| Voorbeeldscenario | Enterprise OLTP-toepassing vereist zeer hoge transacties per secondetarief. | Zakelijke datawarehousingtoepassing die grote hoeveelheden gegevens verwerkt. | Toepassingen in bijna realtime vereisen directe reacties op gebruikersaanvragen, zoals online gaming. |
| Prestatiefactoren | |||
| I/O-grootte | Kleinere I/O-grootte levert hogere IOPS op. | Grotere I/O-grootte levert hogere doorvoer op. | |
| VM-grootte | Gebruik een VM-grootte die IOPS groter biedt dan uw toepassingsvereiste. | Gebruik een VM-grootte met een doorvoerlimiet die groter is dan uw toepassingsvereiste. | Gebruik een VM-grootte die schaallimieten biedt die groter zijn dan uw toepassingsvereiste. |
| Schijfgrootte | Gebruik een schijfgrootte die IOPS groter biedt dan uw toepassingsvereiste. | Gebruik een schijfgrootte met een doorvoerlimiet die groter is dan uw toepassingsvereiste. | Gebruik een schijfgrootte die schaallimieten biedt die groter zijn dan uw toepassingsvereiste. |
| Vm- en schijfschaallimieten | De IOPS-limiet van de gekozen VM-grootte moet groter zijn dan 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 de Premium Storage-schijven die eraan zijn gekoppeld. | Schaallimieten van de gekozen VM-grootte moeten groter zijn dan de totale schaallimieten van de gekoppelde Premium Storage-schijven. |
| Schijfcaching | Schakel ReadOnly Cache in op Premium Storage-schijven met leesintensieve bewerkingen om hogere lees-IOPS te krijgen. | Schakel ReadOnly Cache in op Premium Storage-schijven met leesintensieve bewerkingen om zeer lage leeslatenties te krijgen. | |
| Schijfstriping | Gebruik meerdere schijven en strip ze samen om een gecombineerde hogere IOPS- en doorvoerlimiet te krijgen. De gecombineerde limiet per VIRTUELE machine moet hoger zijn dan de gecombineerde limieten van gekoppelde Premium-schijven. | ||
| Streepgrootte | Kleinere streepgrootte voor willekeurig klein I/O-patroon dat wordt gezien in OLTP-toepassingen. Gebruik bijvoorbeeld een stripegrootte van 64 kB voor een SQL Server OLTP-toepassing. | Grotere stripegrootte voor sequentiële grote I/O-patronen die worden gezien in datawarehouse-toepassingen. Gebruik bijvoorbeeld een stripegrootte van 256 kB voor een SQL Server-datawarehouse-toepassing. | |
| Multithreading | Gebruik multithreading om een hoger aantal aanvragen naar Premium Storage te pushen om te leiden tot hogere IOPS en doorvoer. Stel bijvoorbeeld in 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 hogere doorvoer op. | Kleinere wachtrijdiepte levert lagere latenties op. |
Aard van I/O-aanvragen
Een I/O-aanvraag is een eenheid van invoer-/uitvoerbewerking die door uw toepassing wordt uitgevoerd. Door de aard van I/O-aanvragen, willekeurige of sequentiële, lees- of schrijfbewerkingen, kleine of grote aanvragen te identificeren, kunt u de prestatievereisten van uw toepassing bepalen. Het is belangrijk om inzicht te hebben in de aard van I/O-aanvragen om de juiste beslissingen te nemen wanneer u uw toepassingsinfrastructuur ontwerpt. I/Os moet 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 beïnvloedt de prestaties aanzienlijk, met name op de IOPS en bandbreedte die de toepassing kan bereiken. De volgende formule toont de relatie tussen IOPS, I/O-grootte en bandbreedte/doorvoer.
In sommige toepassingen kunt u de I/O-grootte wijzigen, terwijl sommige toepassingen dat niet doen. 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, die u kunt gebruiken om de I/O-aanvraaggrootte van de database te configureren.
Als u een toepassing gebruikt waarmee 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 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 hogere IOPS te krijgen. Bijvoorbeeld 8 kB voor een OLTP-toepassing.
- Grotere I/O-grootte om een hogere bandbreedte/doorvoer te krijgen. Bijvoorbeeld 1024 kB voor een datawarehouse-toepassing.
Hier volgt een voorbeeld van hoe u de IOPS en doorvoer/bandbreedte voor uw toepassing kunt berekenen.
Overweeg een toepassing die gebruikmaakt van een P30-schijf. De maximale IOPS en doorvoer/bandbreedte die een P30-schijf kan bereiken, zijn respectievelijk 5000 IOPS en 200 MB per seconde. Als uw toepassing 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 voor uw toepassing de maximale doorvoer/bandbreedte van een P30-schijf is vereist en u een grotere I/O-grootte gebruikt, zoals 1024 kB, is de resulterende IOPS kleiner, zoals 200 IOPS.
Stem de I/O-grootte af zodat deze voldoet aan de IOPS-vereisten van uw toepassing en doorvoer/bandbreedte. 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 |
|---|---|---|---|
| Maximum IOPS | 8 kB | 5\.000 | 40 MB per seconde |
| Maximale doorvoer | 1024 KB | 200 | 200 MB/sec |
| Maximale doorvoer + hoge IOPS | 64 kB | 3,200 | 200 MB/sec |
| Maximale IOPS + hoge doorvoer | 32 kB | 5\.000 | 160 MB per seconde |
Als u IOPS en bandbreedte wilt ophalen die hoger zijn dan de maximumwaarde van één Premium-opslagschijf, gebruikt u meerdere Premium-schijven die samen zijn gestreept. Strip bijvoorbeeld twee P30-schijven om een gecombineerde IOPS van 10.000 IOPS te verkrijgen of een gecombineerde doorvoer van 400 MB per seconde. Zoals wordt uitgelegd in de volgende sectie, moet u een VM-grootte gebruiken die ondersteuning biedt voor de gecombineerde IOPS en doorvoer van schijven.
Notitie
Naarmate u IOPS of doorvoer verhoogt, neemt de andere ook toe. Zorg ervoor dat u geen doorvoer- of IOPS-limieten van de schijf of VM bereikt wanneer u een van beide verhoogt.
Als u de gevolgen van de I/O-grootte van de toepassingsprestaties wilt zien, kunt u benchmarkinghulpprogramma's uitvoeren op uw VM en schijven. Maak meerdere testuitvoeringen en gebruik een andere I/O-grootte voor elke uitvoering om het effect te zien. Zie de benchmarkartikelen aan het einde van dit document voor meer informatie.
Vm-grootten op grote schaal
Wanneer u een toepassing gaat ontwerpen, is een van de eerste dingen die u moet doen een VIRTUELE machine kiezen om uw toepassing te hosten. Premium-opslag wordt geleverd met grootschalige VM-grootten waarmee toepassingen kunnen worden uitgevoerd waarvoor hogere rekenkracht en een hoge I/O-prestaties van lokale schijven nodig zijn. Deze VM's bieden snellere processors, een hogere verhouding tussen geheugen en kern en een SSD (Solid State Drive) voor de lokale schijf. Voorbeelden van grootschalige VM's die premium-opslag ondersteunen, zijn de VM's uit de DS- en GS-serie.
Vm's op grote schaal zijn beschikbaar in verschillende grootten met een ander aantal CPU-kernen, geheugen, besturingssysteem en tijdelijke schijfgrootte. Elke VM-grootte heeft ook een maximum aantal gegevensschijven die u aan de virtuele machine kunt koppelen. De gekozen VM-grootte is van invloed op hoeveel verwerking, geheugen en opslagcapaciteit beschikbaar zijn voor uw toepassing. Dit is ook van invloed op de reken- en opslagkosten. De volgende specificaties zijn bijvoorbeeld voor de grootste VM-grootte in een DS-serie en een GS-serie.
| VM-grootte | CPU-kernen | Geheugen | VM-schijfgrootten | Maximumaantal gegevensschijven | Cachegrootte | IOPS | I/O-limieten voor bandbreedtecache |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | BESTURINGSSYSTEEM = 1,023 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 = 1,023 GB Lokale SSD = 896 GB |
64 | 4224 GB | 80.000 IOPS 2000 MB per seconde |
5000 IOPS en 50 MB per seconde |
Zie Grootten voor virtuele machines in Azure voor een volledige lijst met alle beschikbare Azure-VM-grootten. Kies een VM-grootte die kan voldoen aan de gewenste toepassingsprestatievereisten en deze kan schalen. Houd ook rekening met de volgende belangrijke overwegingen wanneer u VM-grootten kiest.
Schaallimieten
De maximale IOPS-limieten per VM en per schijf verschillen en zijn onafhankelijk van elkaar. Zorg ervoor dat de toepassing IOPS aansturen binnen de limieten van de VIRTUELE machine en de Premium-schijven die eraan zijn gekoppeld. Anders ondervinden toepassingsprestaties beperkingen.
Stel dat een toepassingsvereiste maximaal 4000 IOPS is. Om dit niveau te bereiken, richt u een P30-schijf in op een DS1-VM. De P30-schijf kan maximaal 5.000 IOPS leveren. De DS1-VM is echter beperkt tot 3.200 IOPS. De prestaties van de toepassing worden dus beperkt door de VM-limiet van 3.200 IOPS en de prestaties worden gedegradeerd. Als u deze situatie wilt voorkomen, kiest u een VM en schijfgrootte die beide voldoen aan de toepassingsvereisten.
Kosten van de bewerking
In veel gevallen is het mogelijk dat uw totale bedrijfskosten voor het gebruik van Premium-opslag lager zijn dan het gebruik van standard-opslag.
Denk bijvoorbeeld aan een toepassing waarvoor 16.000 IOPS zijn vereist. Om deze prestaties te bereiken, hebt u een Standard_D14 Azure IaaS-VM nodig, die maximaal IOPS van 16.000 kan bieden met behulp van 32 Standard Storage 1 TB-schijven. Elke standard-opslagschijf van 1 TB kan maximaal 500 IOPS bereiken.
- De geschatte kosten van deze VIRTUELE machine per maand bedragen $ 1570.
- De maandelijkse kosten van 32 standaardopslagschijven bedragen $ 1.638.
- De geschatte totale maandelijkse kosten bedragen $ 3.208.
Als u dezelfde toepassing op Premium Storage hebt gehost, hebt u een kleinere VM-grootte en minder Premium-opslagschijven nodig, waardoor de totale kosten worden verminderd. Een Standard_DS13 VM kan voldoen aan de 16.000 IOPS-vereiste met behulp van vier P30-schijven. De DS13-VM heeft een maximale IOPS van 25.600 en elke P30-schijf heeft een maximale IOPS van 5000. Over het algemeen kan deze configuratie 5.000 x 4 = 20.000 IOPS bereiken.
- De geschatte kosten van deze VIRTUELE machine per maand bedragen $ 1.003.
- De maandelijkse kosten van vier P30 Premium-opslagschijven bedragen $ 544,34.
- De geschatte totale maandelijkse kosten bedragen $ 1.544.
De volgende tabel bevat een overzicht van de kostenanalyse van dit scenario voor Standard- en Premium-opslag.
| Maandelijkse kosten | Standard | Premium |
|---|---|---|
| Kosten van vm's per maand | $ 1.570,58 (Standard_D14) | $ 1.003,66 (Standard_DS13) |
| Kosten van schijven per maand | $ 1.638,40 (32 x 1 TB schijven) | $ 544,34 (4 x P30-schijven) |
| Totale kosten per maand | $ 3.208,98 | $ 1.544,34 |
Linux-distributies
Met Premium Storage krijgt u hetzelfde prestatieniveau voor VM's met Windows en Linux. We ondersteunen veel varianten van Linux-distributies. Zie Linux-distributies die zijn goedgekeurd in Azure voor meer informatie.
Verschillende distributies zijn beter geschikt voor verschillende typen werkbelastingen. U ziet verschillende prestatieniveaus, afhankelijk van de distributie waarop uw workload wordt uitgevoerd. Test de Linux-distributies met uw toepassing en kies de distributie die het beste werkt.
Wanneer u Linux met Premium Storage uitvoert, controleert u de meest recente updates over vereiste stuurprogramma's om hoge prestaties te garanderen.
Premium Storage-schijfgrootten
Premium-opslag 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-opslagschijfgrootte, afhankelijk van de toepassingsvereisten en de vm-grootte op grote schaal. In de volgende tabel ziet u de grootte van de schijven en de bijbehorende mogelijkheden. P4-, P6-, P15-, P60-, P70- en P80-grootten worden momenteel alleen ondersteund voor beheerde schijven.
| Premium SSD-grootten | 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 | 1024 | 2048 | 4096 | 8192 | 16,384 | 32.767 |
| Basis ingerichte IOPS per schijf | 120 | 120 | 120 | 120 | 240 | 500 | 1,100 | 2.300 | 5\.000 | 7500 | 7500 | 16.000 | 18.000 | 20,000 |
| **Uitgebreide ingerichte IOPS per schijf | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | 8,000 | 16.000 | 20,000 | 20,000 | 20,000 | 20,000 |
| Ingerichte basisdoorvoer per schijf | 25 MB/s | 25 MB/s | 25 MB/s | 25 MB/s | 50 MB/s | 100 MB/s | 125 MB/s | 150 MB/s | 200 MB/s | 250 MB/s | 250 MB/s | 500 MB/s | 750 MB/s | 900 MB/s |
| **Uitgebreide ingerichte doorvoer per schijf | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
| Max. burst-IOP's per schijf | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 3500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| Max. burst-doorvoer per schijf | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 1000 MB/s* | 1000 MB/s* | 1000 MB/s* | 1000 MB/s* | 1000 MB/s* | 1000 MB/s* |
| Max. burst-duur | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Onbeperkt* | Onbeperkt* | Onbeperkt* | Onbeperkt* | Onbeperkt* | Onbeperkt* |
| Kan worden gereserveerd | Nee | Nee | Nee | Nee | Nee | Nee | Nee | Nr. | Ja, maximaal één jaar | Ja, maximaal één jaar | Ja, maximaal één jaar | Ja, maximaal één jaar | Ja, maximaal één jaar | Ja, maximaal één jaar |
*Is alleen van toepassing op schijven waarvoor bursting op aanvraag is ingeschakeld.
** Alleen van toepassing op schijven waarvoor prestaties plus (preview) zijn ingeschakeld.
Hoeveel schijven u kiest, is afhankelijk van de gekozen schijfgrootte. U kunt één P50-schijf of meerdere P10-schijven gebruiken om te voldoen aan uw toepassingsvereiste. Houd rekening met overwegingen die hier worden vermeld wanneer u de keuze maakt.
Schaallimieten (IOPS en doorvoer)
De IOPS- en doorvoerlimieten van elke Premium-schijfgrootte verschillen en zijn onafhankelijk van de VM-schaallimieten. Zorg ervoor dat de totale IOPS en doorvoer van de schijven binnen de schaallimieten van de gekozen VM-grootte vallen.
Als een toepassingsvereiste bijvoorbeeld een maximale doorvoer van 250 MB per seconde is en u een DS4-VM met één P30-schijf gebruikt, kan de DS4-VM een doorvoer van maximaal 256 MB per seconde geven. Eén P30-schijf heeft echter een doorvoerlimiet van 200 MB/sec. De toepassing wordt dus beperkt tot 200 MB per seconde vanwege de schijflimiet. Als u deze limiet wilt overwinnen, richt u meer dan één gegevensschijf in op de VIRTUELE machine of wijzigt u de grootte van uw schijven in P40 of P50.
Notitie
Leesbewerkingen die door de cache worden geleverd, worden niet opgenomen in de IOPS en doorvoer van de schijf, zodat ze niet onderhevig zijn aan schijflimieten. Cache heeft de afzonderlijke IOPS- en doorvoerlimiet per VM.
In eerste instantie zijn uw lees- en schrijfbewerkingen bijvoorbeeld respectievelijk 60 MB per seconde en 40 MB per seconde. Na verloop van tijd wordt de cache opgewarmd en worden meer en meer van de leesbewerkingen uit de cache verwerkt. Vervolgens kunt u een hogere schrijfdoorvoer van de schijf krijgen.
Aantal schijven
Bepaal het aantal schijven dat u nodig hebt door toepassingsvereisten te beoordelen. Elke VM-grootte heeft ook een limiet voor het aantal schijven dat u aan de virtuele machine kunt koppelen. Normaal gesproken is dit aantal twee keer het aantal kernen. Zorg ervoor dat de VM-grootte die u kiest, ondersteuning biedt voor het aantal schijven dat nodig is.
Houd er rekening mee dat de Premium Storage-schijven betere prestaties bieden in vergelijking met standard-opslagschijven. Als u uw toepassing migreert van een Azure IaaS-VM met standaardopslag naar Premium-opslag, hebt u waarschijnlijk minder Premium-schijven nodig om dezelfde of hogere prestaties voor uw toepassing te bereiken.
Schijfcaching
Vm's met hoge schaal die gebruikmaken van Premium Storage hebben een multitier caching technologie genaamd BlobCache. BlobCache maakt gebruik van een combinatie van de host-RAM en lokale SSD voor caching. Deze cache is beschikbaar voor de permanente schijven van premium-opslag en de lokale VM-schijven. Deze cache-instelling is standaard ingesteld op ReadWrite voor besturingssysteemschijven en ReadOnly voor gegevensschijven die worden gehost in Premium Storage. Als schijfcaching is ingeschakeld op de Premium Storage-schijven, kunnen de grootschalige VM's extreem hoge prestatieniveaus bereiken die de onderliggende schijfprestaties overschrijden.
Waarschuwing
Schijfcache wordt niet ondersteund voor schijven 4 TiB en groter. Als er meerdere schijven aan uw VIRTUELE machine zijn gekoppeld, ondersteunt elke schijf die kleiner is dan 4 TiB caching.
Het wijzigen van de cache-instelling van een Azure-schijf koppelt de doelschijf los en weer vast. Als het de besturingssysteemschijf is, wordt de virtuele machine opnieuw opgestart. Stop alle toepassingen en services die mogelijk worden beïnvloed door deze onderbreking voordat u de instelling voor de schijfcache wijzigt. Het niet volgen van deze aanbevelingen kan leiden tot beschadiging van gegevens.
Zie het blogbericht Inside Azure Premium Storage voor meer informatie over hoe BlobCache werkt.
Het is belangrijk om caching in te schakelen op de juiste set schijven. Of u schijfcaching op een Premium-schijf moet inschakelen of niet afhankelijk is van het workloadpatroon dat de schijf verwerkt. In de volgende tabel ziet u de standaardcache-instellingen voor besturingssysteem- en gegevensschijven.
| Schijftype | Standaardinstelling voor cache |
|---|---|
| Besturingssysteemschijf | Readwrite |
| Gegevensschijf | Alleen-lezen |
We raden de volgende instellingen voor schijfcache aan voor gegevensschijven.
| Instelling voor schijfcache | Aanbeveling voor het gebruik van deze instelling |
|---|---|
| Geen | Configureer hostcache als Geen voor alleen-schrijven en schrijfintensieve schijven. |
| Alleen-lezen | Configureer hostcache als ReadOnly voor alleen-lezen- en lezen-schrijfschijven. |
| Readwrite | Configureer hostcache alleen als ReadWrite alleen als uw toepassing het schrijven van in de cache opgeslagen gegevens naar permanente schijven afhandelt wanneer dat nodig is. |
Alleen-lezen
Door ReadOnly caching te configureren op Premium Storage-gegevensschijven, kunt u een lage leeslatentie bereiken en om twee redenen zeer hoge lees-IOPS en doorvoer voor uw toepassing krijgen:
- Leesbewerkingen die worden uitgevoerd vanuit de cache, die zich op het VM-geheugen en de lokale SSD bevindt, zijn sneller dan leesbewerkingen van de gegevensschijf, die zich in Azure Blob Storage bevindt.
- Premium-opslag telt niet de leesbewerkingen uit de cache naar de schijf-IOPS en doorvoer. Daarom kan uw toepassing hogere totale IOPS en doorvoer bereiken.
Readwrite
Op de besturingssysteemschijven is standaard ReadWrite-caching ingeschakeld. We hebben onlangs ook ondersteuning toegevoegd voor ReadWrite-caching op gegevensschijven. Als u ReadWrite-caching gebruikt, moet u over de juiste manier beschikken om de gegevens van de cache naar permanente schijven te schrijven. SQL Server verwerkt bijvoorbeeld het schrijven van gegevens in de cache naar de permanente opslagschijven zelf. Het gebruik van de ReadWrite-cache met een toepassing die de vereiste gegevens niet afhandelt, kan leiden tot gegevensverlies als de VM vastloopt.
Geen
Momenteel wordt Geen alleen ondersteund op gegevensschijven. Het wordt niet ondersteund op besturingssysteemschijven. Als u Geen op een besturingssysteemschijf instelt, wordt deze instelling intern overschreven en ingesteld op ReadOnly.
U kunt deze richtlijnen bijvoorbeeld toepassen op SQL Server die wordt uitgevoerd in Premium Storage door de volgende stappen uit te voeren:
- Configureer de ReadOnly-cache op Premium Storage-schijven die gegevensbestanden hosten.
- De snelle leesbewerkingen uit de cache verlagen de SQL Server-querytijd omdat gegevenspagina's sneller uit de cache worden opgehaald dan rechtstreeks vanaf de gegevensschijven.
- Het leveren van leesbewerkingen uit de cache betekent dat er meer doorvoer beschikbaar is van Premium-gegevensschijven. SQL Server kan deze extra doorvoer gebruiken voor het ophalen van meer gegevenspagina's en andere bewerkingen, zoals back-up/herstel, batchbelastingen en het opnieuw opbouwen van indexen.
- Configureer de None-cache op Premium Storage-schijven die als host fungeren voor de logboekbestanden.
- Logboekbestanden hebben voornamelijk schrijfintensieve bewerkingen, zodat ze niet profiteren van de ReadOnly-cache .
Prestaties optimaliseren op Linux-VM's
Voor alle Premium SSD's of Ultra Disks kunt u mogelijk barrières uitschakelen voor bestandssystemen op de schijf om de prestaties te verbeteren wanneer bekend is dat er geen caches zijn die gegevens kunnen verliezen. Als caching van Azure-schijven is ingesteld op ReadOnly of None, kunt u barrières uitschakelen. Maar als caching is ingesteld op ReadWrite, moeten barrières ingeschakeld blijven om de duurzaamheid van schrijfbewerkingen te garanderen. Barrières worden doorgaans standaard ingeschakeld, maar u kunt barrières uitschakelen met behulp van een van de volgende methoden, afhankelijk van het bestandstype:
- reiserFS: Gebruik de barrière=geen koppeloptie om barrières uit te schakelen. Gebruik barrière=leegmaken om expliciet barrières in te schakelen.
- ext3/ext4: Gebruik de barrière=0 koppeloptie om barrières uit te schakelen. Gebruik barrière=1 om expliciet barrières in te schakelen.
- XFS: Gebruik de koppelingsoptie nobarrier om barrières uit te schakelen. Gebruik barrières om expliciet barrières in te schakelen. Vanaf versie 4.10 van de mainline Linux-kernel zorgt het ontwerp van het XFS-bestandssysteem altijd voor duurzaamheid. Het uitschakelen van barrières heeft geen effect en de optie nobarrier is afgeschaft. Sommige Linux-distributies hebben echter mogelijk de wijzigingen in een distributierelease met een eerdere kernelversie gebackporteerd. Neem contact op met uw distributieleverancier voor de status in de distributie en versie die u uitvoert.
Schijfstriping
Wanneer een grootschalige VIRTUELE machine is gekoppeld aan verschillende permanente schijven van Premium Storage, kunnen de schijven worden gestreept om hun IOPS, bandbreedte en opslagcapaciteit te aggregeren.
In Windows kunt u Opslagruimten gebruiken om schijven samen te stripen. U moet één kolom configureren voor elke schijf in een groep. Anders kunnen de algehele prestaties van gestreept volume lager zijn dan verwacht vanwege ongelijke verdeling van verkeer over de schijven.
Met behulp van de gebruikersinterface van Serverbeheer kunt u het totale aantal kolommen instellen op 8 een gestreept volume. Wanneer u meer dan acht schijven koppelt, gebruikt u PowerShell om het volume te maken. Met Behulp van PowerShell kunt u het aantal kolommen instellen dat gelijk is aan het aantal schijven. Als er bijvoorbeeld 16 schijven in één stripeset staan, geeft u 16 kolommen op in de NumberOfColumns parameter van de New-VirtualDisk PowerShell-cmdlet.
Gebruik in Linux het hulpprogramma MDADM om schijven samen te stripen. Zie Software RAID configureren in Linux voor stappen voor het stripen van schijven in Linux.
Streepgrootte
Een belangrijke configuratie in schijfstriping is de stripegrootte. De streepgrootte of blokgrootte is het kleinste segment gegevens dat een toepassing kan adresseren op een gestreept volume. De stripegrootte die u configureert, is afhankelijk van het type toepassing en het bijbehorende aanvraagpatroon. Als u de verkeerde stripegrootte kiest, kan dit leiden tot een onjuiste I/O-uitlijning, wat leidt tot verminderde prestaties van uw toepassing.
Als een I/O-aanvraag die wordt gegenereerd door uw toepassing bijvoorbeeld groter is dan de schijfstrookgrootte, schrijft het opslagsysteem deze over de grenzen van stripe-eenheden op meer dan één schijf. Wanneer het tijd is om toegang te krijgen tot die gegevens, moet er meer dan één stripe-eenheid worden gezocht om de aanvraag te voltooien. Het cumulatieve effect van dergelijk gedrag kan leiden tot aanzienlijke prestatievermindering. Als de I/O-aanvraaggrootte daarentegen kleiner is dan de stripegrootte en als deze willekeurig is, kunnen de I/O-aanvragen op dezelfde schijf optellen, waardoor een knelpunt ontstaat en uiteindelijk de I/O-prestaties afnemen.
Afhankelijk van het type workload dat uw toepassing uitvoert, kiest u een geschikte stripegrootte. Gebruik voor willekeurige kleine I/O-aanvragen een kleinere stripegrootte. Voor grote opeenvolgende I/O-aanvragen gebruikt u een grotere stripegrootte. Bekijk de aanbevelingen voor stripegrootte voor de toepassing die u gaat uitvoeren in Premium Storage. Voor SQL Server configureert u een stripegrootte van 64 kB voor OLTP-workloads en 256 kB voor datawarehousingworkloads. Zie best practices voor prestaties voor SQL Server op Azure-VM's voor meer informatie.
Notitie
U kunt maximaal 32 Premium-opslagschijven op een VM uit de DS-serie en 64 Premium Storage-schijven op een VM uit de GS-serie stripen.
Multithreading
Azure heeft het Premium Storage-platform ontworpen om enorm parallel te zijn. Daarom bereikt een multithreaded-toepassing hogere prestaties dan een toepassing met één thread. Een multithreaded-toepassing splitst de taken over meerdere threads en verhoogt de efficiëntie van de uitvoering door gebruik te maken van de VM- en schijfbronnen tot het maximum.
Als uw toepassing bijvoorbeeld wordt uitgevoerd op één kern-VM met behulp van twee threads, kan de CPU schakelen tussen de twee threads om efficiëntie te bereiken. Terwijl één thread wacht op een schijf-I/O om te voltooien, kan de CPU overschakelen naar de andere thread. Op deze manier kunnen twee threads meer dan één thread bereiken. Als de VIRTUELE machine meer dan één kern heeft, wordt de uitvoeringstijd verder verlaagd, omdat elke kern taken parallel kan uitvoeren.
Mogelijk kunt u de manier waarop een kant-en-klare toepassing één threading of multithreading implementeert, niet wijzigen. SQL Server kan bijvoorbeeld multi-CPU en multicore verwerken. SQL Server bepaalt echter onder welke voorwaarden een of meer threads worden gebruikt om een query te verwerken. Het kan query's uitvoeren en indexen bouwen met behulp van multithreading. Voor een query waarbij grote tabellen worden gekoppeld en gegevens worden gesorteerd voordat u terugkeert naar de gebruiker, gebruikt SQL Server waarschijnlijk meerdere threads. Een gebruiker kan niet bepalen of SQL Server een query uitvoert met behulp van één thread of meerdere threads.
Er zijn configuratie-instellingen die u kunt wijzigen om de multithreading of parallelle verwerking van een toepassing te beïnvloeden. Voor SQL Server is dit bijvoorbeeld de max degree of parallelism configuratie. Met deze instelling met de naam MAXDOP kunt u het maximum aantal processors configureren dat SQL Server kan gebruiken bij parallelle verwerking. U kunt MAXDOP configureren voor afzonderlijke query's of indexbewerkingen. Deze mogelijkheid is nuttig wanneer u resources van uw systeem wilt verdelen voor een essentiële toepassing voor prestaties.
Stel dat uw toepassing die GEBRUIKMAAKT van SQL Server een grote query uitvoert en tegelijkertijd een indexbewerking uitvoert. Stel 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 een hogere waarde dan de MAXDOP-waarde voor de query. Op deze manier heeft SQL Server meer processors dan voor de indexbewerking kan worden gebruikt in vergelijking met het aantal processors dat kan worden toegewezen aan de grote query. Houd er rekening mee dat u het aantal threads dat SQL Server gebruikt voor elke bewerking niet beheert. U kunt bepalen hoeveel processors er maximaal worden toegewezen voor multithreading.
Meer informatie over mate van parallelle uitvoering in SQL Server. Ontdek hoe dergelijke instellingen van invloed zijn op multithreading in uw toepassing en hun configuraties om de prestaties te optimaliseren.
Wachtrijdiepte
De wachtrijdiepte of wachtrijlengte of wachtrijgrootte is het aantal in behandeling zijnde I/O-aanvragen in het systeem. De waarde van de wachtrijdiepte bepaalt hoeveel I/O-bewerkingen uw toepassing kan uitlijnen, die door de opslagschijven worden verwerkt. Dit is van invloed op alle drie de prestatie-indicatoren van toepassingen die in dit artikel worden besproken: IOPS, doorvoer en latentie.
Wachtrijdiepte en multithreading zijn nauw verwant. De dieptewaarde van de wachtrij geeft aan hoeveel multithreading kan worden bereikt door de toepassing. Als de wachtrijdiepte groot is, kan de toepassing meer bewerkingen gelijktijdig uitvoeren, met andere woorden, meer multithreading. Als de wachtrijdiepte klein is, zelfs als de toepassing multithreaded is, zijn er niet voldoende aanvragen beschikbaar voor gelijktijdige uitvoering.
Normaal gesproken kunt u met off-the-shelf-toepassingen de diepte van de wachtrij niet wijzigen, omdat als deze onjuist is ingesteld, het meer kwaad dan goed doet. Toepassingen stellen de juiste waarde voor wachtrijdiepte in om de optimale prestaties te verkrijgen. Het is belangrijk om dit concept te begrijpen, zodat u prestatieproblemen met uw toepassing kunt oplossen. U kunt ook de gevolgen van de diepte van de wachtrij bekijken door benchmarkinghulpprogramma's op uw systeem uit te voeren.
Sommige toepassingen bieden instellingen om de diepte van de wachtrij te beïnvloeden. Bijvoorbeeld de MAXDOP-instelling in SQL Server die in de vorige sectie is uitgelegd. MAXDOP is een manier om de diepte van de wachtrij en multithreading te beïnvloeden, hoewel de dieptewaarde van de wachtrij van SQL Server niet rechtstreeks wordt gewijzigd.
Hoge wachtrijdiepte
Een hoge wachtrijdiepte biedt meer bewerkingen op de schijf. De schijf kent de volgende aanvraag in de wachtrij van tevoren. De schijf kan bewerkingen dus van tevoren plannen en in een optimale volgorde verwerken. Omdat de toepassing meer aanvragen naar de schijf verzendt, kan de schijf meer parallelle I/Os verwerken. Uiteindelijk kan de toepassing hogere IOPS bereiken. Omdat de toepassing meer aanvragen verwerkt, neemt de totale doorvoer van de toepassing ook toe.
Normaal gesproken kan een toepassing een maximale doorvoer bereiken met 8 tot 16+ openstaande I/Os per gekoppelde schijf. Als een wachtrijdiepte één is, pusht de toepassing niet genoeg I/Os naar het systeem en verwerkt deze een kleinere hoeveelheid in een bepaalde periode. Met andere woorden, minder doorvoer.
Stel bijvoorbeeld in SQL Server de MAXDOP-waarde voor een query in om SQL Server te 4 informeren dat deze maximaal vier kernen kan gebruiken om de query uit te voeren. SQL Server bepaalt de beste waarde voor de diepte van de wachtrij en het aantal kernen voor de queryuitvoering.
Optimale wachtrijdiepte
Een zeer hoge waarde voor de diepte van de wachtrij heeft ook de nadelen. Als de dieptewaarde van de wachtrij te hoog is, probeert de toepassing zeer hoge IOPS te sturen. Tenzij de toepassing permanente schijven met voldoende ingerichte IOPS heeft, kan een zeer hoge wachtrijdiepte een negatieve invloed hebben op de latenties van toepassingen. In de volgende formule ziet u de relatie tussen IOPS, latentie en wachtrijdiepte.
U moet geen wachtrijdiepte configureren voor een hoge waarde, maar voor een optimale waarde, die voldoende IOPS voor de toepassing kan leveren zonder dat dit van invloed is op latenties. Als de toepassingslatentie bijvoorbeeld 1 milliseconden moet zijn, is de wachtrijdiepte die nodig is om 5.000 IOPS te bereiken QD = 5.000 x 0,001 = 5.
Wachtrijdiepte voor gestreept volume
Voor een gestreept volume moet u een hoge wachtrijdiepte onderhouden, zodat elke schijf afzonderlijk een piekwachtrijdiepte heeft. Denk bijvoorbeeld aan een toepassing die een wachtrijdiepte 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 zodat alle schijven bezet kunnen zijn. In de volgende formule ziet u hoe u de wachtrijdiepte van gestreepte volumes kunt bepalen.
Beperking
Premium-opslag richt een opgegeven aantal IOPS en doorvoer in, afhankelijk van de VM-grootten en schijfgrootten die u kiest. Wanneer uw toepassing IOPS of doorvoer probeert te sturen boven deze limieten van wat de VIRTUELE machine of schijf kan verwerken, wordt deze beperkt door Premium Storage. Het resultaat is verslechterde prestaties in uw toepassing, wat kan betekenen dat de latentie, een lagere doorvoer of een lagere IOPS zijn.
Als Premium Storage niet wordt beperkt, kan uw toepassing volledig mislukken door te overschrijden wat de resources ervan kunnen bereiken. Als u prestatieproblemen wilt voorkomen vanwege beperking, moet u altijd voldoende resources inrichten voor uw toepassing. Neem rekening met wat we in de vorige secties over VM-grootten en schijfgrootten hebben besproken. Benchmarking is de beste manier om erachter te komen welke resources u nodig hebt om uw toepassing te hosten.
Volgende stappen
Als u uw schijf wilt benchmarken, raadpleegt u de volgende artikelen:
- Voor Linux: Uw toepassing benchmarken in Azure Disk Storage
- Voor Windows: Benchmark a disk
Meer informatie over de beschikbare schijftypen:
- Voor Linux: Selecteer een schijftype
- Voor Windows: Selecteer een schijftype
Voor SQL Server-gebruikers raadpleegt u de artikelen over aanbevolen procedures voor prestaties voor SQL Server: