Förstå Prestanda för Azure Files

2025-05-03

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

Hanteringsmodell	Faktureringsmodell	Medieklass	Redundans
Microsoft.Storage, lagringstjänster	Provisionerad v2	HDD (standard)	Lokalt (LRS)
Microsoft.Storage, lagringstjänster	Provisionerad v2	HDD (standard)	Zon (ZRS)
Microsoft.Storage, lagringstjänster	Provisionerad v2	HDD (standard)	Geo (GRS)
Microsoft.Storage, lagringstjänster	Provisionerad v2	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage, lagringstjänster	Tillhandahållen v1	SSD (hög kvalitet)	Lokalt (LRS)
Microsoft.Storage, lagringstjänster	Tillhandahållen v1	SSD (hög kvalitet)	Zon (ZRS)
Microsoft.Storage, lagringstjänster	Betala efter hand	HDD (standard)	Lokalt (LRS)
Microsoft.Storage, lagringstjänster	Betala efter hand	HDD (standard)	Zon (ZRS)
Microsoft.Storage, lagringstjänster	Betala efter hand	HDD (standard)	Geo (GRS)
Microsoft.Storage, lagringstjänster	Betala efter hand	HDD (standard)	GeoZone (GZRS)

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" är utbytbar 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 små storlekar som 4 KiB till 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 för fördröjning och mäts 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 medienivå baserat på användningsmönster

Azure Files har två lagringsmedienivåer som gör att du kan balansera prestanda och pris: SSD och HDD. Du väljer medienivån för filresursen på lagringskontonivå, och när du har skapat ett lagringskonto på en viss medienivå kan du inte flytta till den andra utan att migrera till en ny filresurs manuellt.

När du väljer mellan SSD- och HDD-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, snabba dataöverföringshastigheter eller låg svarstid bör du välja SSD-filresurser.

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

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

SSD-filresurser erbjuder en etableringsmodell som garanterar följande prestandaprofil baserat på resursstorlek. Mer information finns i den etablerade v1-modellen.

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.

Svarstidskänslighet: Arbetsbelastningar som är känsliga för läsfördröjning och har hög synlighet för slutanvändare är mer lämpliga för SSD-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: SSD-filresurser stöder större IOPS- och dataflödesgränser än HDD-filresurser. 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 HDD-filresurser jämfört med långvariga, ofta förekommande arbetsbelastningar. På SSD-filresurser är arbetsbelastningens varaktighet användbar när du fastställer rätt prestandaprofil som ska användas baserat på den etablerade lagringen, IOPS och dataflödet. 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 arbetsbelastning: För arbetsbelastningar som utför åtgärder parallellt, till exempel genom flera trådar, processer eller programinstanser på samma klient, ger SSD-filresurser en klar fördel jämfört med HDD-filresurser: SMB Multichannel. Mer information finns i Förbättra prestanda för SMB Azure-filresurser.
API-åtgärdsdistribution: Metadataintensiva arbetsbelastningar, som sådana som utför läsoperationer mot ett stort antal filer, passar bättre för SSD-filresurser. 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 färdas fram och tillbaka endast inom Azure Files. Detta inkluderar inte någon klient- eller nätverksfördröjning.

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 är 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. Underdimensionerade eller felaktigt dirigerade ExpressRoute-kretsar eller VPN-gatewayer kan avsevärt begränsa arbetsbelastningar som körs på Azure Files.

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

Dela via

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