Dela via

Förstå och optimera prestanda för Azure-filresurser

  • Artikel

Azure Files kan uppfylla prestandakraven för de flesta program och användningsfall. Den här artikeln beskriver de olika faktorer som kan påverka filresursprestanda och hur du optimerar prestanda för Azure-filresurser för din arbetsbelastning.

Gäller för

Typ av filresurs SMB NFS
Standardfilresurser (GPv2), LRS/ZRS Ja Inga
Standardfilresurser (GPv2), GRS/GZRS Ja Inga
Premiumfilresurser (FileStorage), LRS/ZRS Ja Ja

Ordlista

Innan du läser den här artikeln är det bra att förstå några viktiga termer som rör lagringsprestanda:

  • I/O-åtgärder per sekund (IOPS)

    IOPS- eller indata-/utdataåtgärder per sekund mäter antalet filsystemåtgärder per sekund. Termen "I/O" kan ändras med termerna "operation" och "transaction" i Azure Files-dokumentationen.

  • I/O-storlek

    I/O-storlek, som ibland kallas blockstorlek, är storleken på den begäran som ett program använder för att utföra en enda indata-/utdataåtgärd (I/O) på lagringen. Beroende på programmet kan I/O-storleken variera från mycket små storlekar, till exempel 4 KiB till mycket större storlekar. I/O-storlek spelar en viktig roll för uppnåeligt dataflöde.

  • Dataflöde

    Dataflödet mäter antalet bitar som läses från eller skrivs till lagringen per sekund och mäts i mebibyte per sekund (MiB/s). Om du vill beräkna dataflödet multiplicerar du IOPS med I/O-storlek. Till exempel 10 000 IOPS * 1 MiB I/O-storlek = 10 GiB/s, medan 10 000 IOPS * 4 KiB I/O-storlek = 38 MiB/s.

  • Svarstider

    Svarstid är synonymt med fördröjning och mäts vanligtvis i millisekunder (ms). Det finns två typer av svarstider: svarstid från slutpunkt till slutpunkt och tjänstfördröjning. Mer information finns i Svarstid.

  • Ködjup

    Ködjup är antalet väntande I/O-begäranden som en lagringsresurs kan hantera samtidigt. Mer information finns i Ködjup.

Välja en prestandanivå baserat på användningsmönster

Azure Files tillhandahåller en mängd olika lagringsnivåer som hjälper dig att minska kostnaderna genom att du kan lagra data på lämplig prestanda- och prisnivå. På den högsta nivån erbjuder Azure Files två prestandanivåer: standard och premium. Standardfilresurser finns på ett lagringssystem som backas upp av hårddiskar (HDD), medan premiumfilresurser backas upp av SSD (Solid State Drives) för bättre prestanda. Standardfilresurser har flera lagringsnivåer (transaktionsoptimerad, frekvent och lågfrekvent) som du sömlöst kan flytta mellan för att maximera lagrings- och transaktionspriserna för data i vila. Du kan dock inte flytta mellan standard- och premiumnivåer utan att fysiskt migrera dina data mellan olika lagringskonton.

När du väljer mellan standard- och Premium-filresurser är det viktigt att förstå kraven för det förväntade användningsmönstret som du planerar att köra på Azure Files. Om du behöver stora mängder IOPS, extremt snabba dataöverföringshastigheter eller mycket låg svarstid bör du välja Premium Azure-filresurser.

I följande tabell sammanfattas de förväntade prestandamålen mellan standard och Premium. Mer information finns i Skalbarhets- och prestandamål för Azure Files.

Krav för användningsmönster Standard Premium
Skrivsvarstid (ensiffriga millisekunder) Ja Ja
Lässvarstid (ensiffriga millisekunder) Nej Ja

Premium-filresurser erbjuder en etableringsmodell som garanterar följande prestandaprofil baserat på resursstorlek. Mer information finns i Etablerad modell. Burst-krediter ackumuleras i en burst-bucket när trafiken för filresursen ligger under baslinje-IOPS. Intjänade krediter används senare för att aktivera bursting när åtgärder skulle överskrida baslinje-IOPS.

Kapacitet (GiB) Baslinje-IOPS Burst-IOPS Burst-krediter Dataflöde (ingress + utgående)
100 3,100 Upp till 10 000 24,840,000 110 MiB/s
500 3 500 Upp till 10 000 23,400,000 150 MiB/s
1,024 4,024 Upp till 10 000 21,513,600 203 MiB/s
5,120 8 120 Upp till 15 360 26,064,000 613 MiB/s
10,240 13,240 Upp till 30 720 62,928,000 1 125 MiB/s
33,792 36,792 Upp till 100 000 227,548,800 3 480 MiB/s
51,200 54,200 Upp till 100 000 164,880,000 5 220 MiB/s
102,400 100,000 Upp till 100 000 0 10 340 MiB/s

Checklista för prestanda

Oavsett om du utvärderar prestandakrav för en ny eller befintlig arbetsbelastning kan du få förutsägbara prestanda genom att förstå dina användningsmönster. Kontakta lagringsadministratören eller programutvecklaren för att fastställa följande användningsmönster.

  • Känslighet för svarstid: Öppnar användare filer eller interagerar med virtuella skrivbord som körs på Azure Files? Det här är exempel på arbetsbelastningar som är känsliga för läsfördröjning och som även har hög synlighet för slutanvändare. De här typerna av arbetsbelastningar är mer lämpliga för Premium Azure-filresurser, vilket kan ge svarstid på en millisekunder för både läs- och skrivåtgärder (< 2 ms för liten I/O-storlek).

  • Krav för IOPS och dataflöde: Premium-filresurser stöder större IOPS- och dataflödesgränser än standardfilresurser. Mer information finns i skalningsmål för filresurser.

  • Varaktighet och frekvens för arbetsbelastning: Korta (minuter) och sällan förekommande (timvisa) arbetsbelastningar är mindre benägna att uppnå de övre prestandagränserna för standardfilresurser jämfört med långvariga, ofta förekommande arbetsbelastningar. På premiumfilresurser är arbetsbelastningens varaktighet användbar när du fastställer rätt prestandaprofil som ska användas baserat på etableringsstorleken. Beroende på hur länge arbetsbelastningen behöver brista och hur lång tid den spenderar under baslinje-IOPS kan du avgöra om du ackumulerar tillräckligt med burst-krediter för att konsekvent uppfylla din arbetsbelastning vid hög belastning. Att hitta rätt saldo minskar kostnaderna jämfört med överetablering av filresursen. Ett vanligt misstag är att köra prestandatester i bara några minuter, vilket ofta är missvisande. För att få en realistisk bild av prestanda bör du testa med tillräckligt hög frekvens och varaktighet.

  • Parallellisering av arbetsbelastningar: För arbetsbelastningar som utför parallella åtgärder, till exempel genom flera trådar, processer eller programinstanser på samma klient, ger Premium-filresurser en tydlig fördel jämfört med standardfilresurser: SMB Multichannel. Mer information finns i Förbättra prestanda för SMB Azure-filresurser.

  • API-åtgärdsdistribution: Är arbetsbelastningsmetadata tung med åtgärder för att öppna/stänga filer? Detta är vanligt för arbetsbelastningar som utför läsåtgärder mot ett stort antal filer. Se Hög arbetsbelastning för metadata eller namnområde.

Svarstid

När du tänker på svarstid är det viktigt att först förstå hur svarstiden bestäms med Azure Files. De vanligaste måtten är svarstiden som är associerad med svarstid från slutpunkt till slutpunkt och mått för tjänstfördröjning . Med hjälp av dessa transaktionsmått kan du identifiera svarstid och/eller nätverksproblem på klientsidan genom att fastställa hur lång tid programtrafiken lägger på överföring till och från klienten.

  • Svarstid från slutpunkt till slutpunkt (SuccessE2ELatency) är den totala tid det tar för en transaktion att utföra en fullständig tur och retur-resa från klienten, över nätverket, till Azure Files-tjänsten och tillbaka till klienten.

  • Tjänstsvarstid (SuccessServerLatency) är den tid det tar för en transaktion att endast resa tur och retur inom Azure Files-tjänsten. Detta inkluderar inte någon klient- eller nätverksfördröjning.

    Diagram som jämför klientfördröjning och tjänstfördröjning för Azure Files.

Skillnaden mellan värdena SuccessE2ELatency och SuccessServerLatency är den svarstid som sannolikt orsakas av nätverket och/eller klienten.

Det är vanligt att förväxla klientfördröjning med tjänstfördröjning (i det här fallet Azure Files-prestanda). Om tjänstsvarstiden till exempel rapporterar låg svarstid och från slutpunkt till slutpunkt rapporterar mycket hög svarstid för begäranden, tyder det på att all tid som spenderas under överföring till och från klienten och inte i Azure Files-tjänsten.

Dessutom, som diagrammet visar, ju längre du är borta från tjänsten, desto långsammare blir svarstiden och desto svårare blir det att uppnå prestandaskalningsgränser med alla molntjänster. Detta gäller särskilt när du kommer åt Azure Files lokalt. Även om alternativ som ExpressRoute är idealiska för lokalt, matchar de fortfarande inte prestanda för ett program (beräkning + lagring) som körs uteslutande i samma Azure-region.

Dricks

Att använda en virtuell dator i Azure för att testa prestanda mellan lokalt och Azure är ett effektivt och praktiskt sätt att baslinjeansluta nätverksfunktionerna för anslutningen till Azure. Ofta kan en arbetsbelastning saktas ned av en undersized eller felaktigt dirigerad ExpressRoute-krets eller VPN-gateway.

Ködjup

Ködjup är antalet utestående I/O-begäranden som en lagringsresurs kan betjäna. Eftersom de diskar som används av lagringssystem har utvecklats från HDD-spindlar (IDE, SATA, SAS) till SSD-enheter (SSD, NVMe) har de också utvecklats för att stödja högre ködjup. En arbetsbelastning som består av en enda klient som seriellt interagerar med en enda fil i en stor datamängd är ett exempel på lågt ködjup. Däremot kan en arbetsbelastning som stöder parallellitet med flera trådar och flera filer enkelt uppnå högt ködjup. Eftersom Azure Files är en distribuerad filtjänst som omfattar tusentals Azure-klusternoder och är utformad för att köra arbetsbelastningar i stor skala rekommenderar vi att du skapar och testar arbetsbelastningar med högt ködjup.

Hög ködjup kan uppnås på flera olika sätt i kombination med klienter, filer och trådar. För att fastställa ködjupet för din arbetsbelastning multiplicerar du antalet klienter med antalet filer med antalet trådar (klienter * filer * trådar = ködjup).

Tabellen nedan illustrerar de olika kombinationer som du kan använda för att uppnå ett högre ködjup. Även om du kan överskrida det optimala ködjupet på 64 rekommenderar vi det inte. Du ser inga fler prestandavinster om du gör det, och du riskerar att öka svarstiden på grund av TCP-mättnad.

Klienter Filer Trådar Ködjup
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Dricks

För att uppnå övre prestandagränser kontrollerar du att arbetsbelastnings- eller benchmarkingtestet har flera trådar med flera filer.

Program med en eller flera trådar

Azure Files passar bäst för program med flera trådar. Det enklaste sättet att förstå prestandapåverkan som multitrådning har på en arbetsbelastning är att gå igenom scenariot med I/O. I följande exempel har vi en arbetsbelastning som behöver kopiera 10 000 små filer så snabbt som möjligt till eller från en Azure-filresurs.

Den här tabellen delar upp den tid som krävs (i millisekunder) för att skapa en enda 16 KiB-fil på en Azure-filresurs, baserat på ett entrådsprogram som skrivs i 4 KiB-blockstorlekar.

I/O-åtgärd Skapa 4 KiB-skrivning 4 KiB-skrivning 4 KiB-skrivning 4 KiB-skrivning Stäng Totalt
Tråd 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

I det här exemplet skulle det ta cirka 14 ms att skapa en enda 16 KiB-fil från de sex åtgärderna. Om ett entrådat program vill flytta 10 000 filer till en Azure-filresurs översätts det till 140 000 ms (14 ms * 10 000) eller 140 sekunder eftersom varje fil flyttas sekventiellt en i taget. Tänk på att tiden för att betjäna varje begäran främst bestäms av hur nära beräkningen och lagringen finns till varandra, enligt beskrivningen i föregående avsnitt.

Genom att använda åtta trådar i stället för en kan ovanstående arbetsbelastning minskas från 140 000 ms (140 sekunder) ned till 17 500 ms (17,5 sekunder). Som tabellen nedan visar kan du flytta samma mängd data på 87,5 % mindre tid när du flyttar åtta filer parallellt i stället för en fil i taget.

I/O-åtgärd Skapa 4 KiB-skrivning 4 KiB-skrivning 4 KiB-skrivning 4 KiB-skrivning Stäng Totalt
Tråd 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tråd 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Se även