Prestandamått för regelbundna volymprestanda för Azure NetApp Files för Linux
I den här artikeln beskrivs prestandamått som Azure NetApp Files levererar för Linux med en vanlig volym.
Hela arbetsbelastningar för filströmning (skalbara benchmark-tester)
Avsikten med ett utskalningstest är att visa prestanda för en Azure NetApp-filvolym när du skalar ut (eller ökar) antalet klienter som genererar samtidig arbetsbelastning till samma volym. Dessa tester kan vanligtvis push-överföra en volym till gränsen för dess prestandagränser och tyder på arbetsbelastningar som medierendering, AI/ML och andra arbetsbelastningar som använder stora beräkningsgrupper för att utföra arbete.
Hög prestandakonfiguration för I/OP-utskalning
Dessa riktmärken använde följande:
- En enda vanlig Azure NetApp Files 100-TiB-volym med en datauppsättning på 1 TiB med ultraprestandanivån
- FIO (med och utan inställning randrepeat=0)
- 4-KiB- och 8-KiB-blockstorlekar
- 6 D32s_v5 virtuella datorer som kör RHEL 9.3
- NFSv3
- Manuell QoS
- Monteringsalternativ: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Prestandakonfiguration för hög dataflödesutskalning
Dessa riktmärken använde följande:
- En enda vanlig Azure NetApp Files-volym med en 1-TiB-datauppsättning med hjälp av ULTRA-prestandanivån FIO (med och utan att ange randrepeat=0)
- FIO (med och utan inställning randrepeat=0)
- 64-KiB och 256-KiB blockstorlek
- 6 D32s_v5 virtuella datorer som kör RHEL 9.3
- NFSv3
- Manuell QoS
- Monteringsalternativ: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Parallell nätverksanslutning (nconnect) benchmark-konfiguration
Dessa riktmärken använde följande:
- En enda vanlig Azure NetApp Files-volym med en 1 TiB-datauppsättning med ultraprestandanivån
- FIO (med och utan inställning randrepeat=0)
- 4-KiB och 64-KiB wsize/rsize
- En enda D32s_v4 virtuell dator som kör RHEL 9.3
- NFSv3 med och utan
nconnect - Monteringsalternativ: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Benchmark-tester för uppskalning
Syftet med uppskalningstestet är att visa prestanda för en Azure NetApp-filvolym när du skalar upp (eller ökar) antalet jobb som genererar samtidig arbetsbelastning över flera TCP-anslutningar på en enskild klient till samma volym (till exempel med nconnect).
Utan nconnectkan dessa arbetsbelastningar inte tänja på gränserna för en volyms maximala prestanda, eftersom klienten inte kan generera tillräckligt med I/O- eller nätverksdataflöde. Dessa tester är vanligtvis ett tecken på vad en enskild användares upplevelse kan vara i arbetsbelastningar som medierendering, databaser, AI/ML och allmänna filresurser.
Höga prestandamått för I/OP-utskalning
Följande riktmärken visar prestanda för Azure NetApp Files med en hög I/OP-arbetsbelastning med hjälp av:
- 32 klienter
- 4-KiB och 8-KiB slumpmässiga läsningar och skrivningar
- 1-TiB-datauppsättning
- Läs-/skrivkvoter enligt följande: 100%:0%, 90%:10%, 80%:20%, och så vidare
- Med och utan cachelagring av filsystem (med i
randrepeat=0FIO)
Mer information finns i Testmetodik.
Resultat: 4 KiB, slumpmässig, klientcachelagring ingår
I det här riktmärket kördeS FIO utan randrepeat alternativet att randomisera data. Därför spelade en obestämd mängd cachelagring upp. Den här konfigurationen resulterar i något bättre övergripande prestandasiffror än tester som körs utan cachelagring med hela I/O-stacken som används.
I följande diagram visar testningen att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 130 000 rena slumpmässiga 4-KiB-skrivningar och cirka 460 000 rena slumpmässiga 4 KiB-läsningar under det här riktmärket. Läs- och skrivmix för arbetsbelastningen justerad med 10 % för varje körning.
I takt med att I/OP-mixen för läs- och skrivåtgärder ökar till skrivintensiv minskar den totala I/OPS.
Resultat: 4 KiB, slumpmässig, klientcachelagring exkluderad
I det här riktmärket kördes FIO med inställningen randrepeat=0 för att randomisera data, vilket minskade cachelagringens påverkan på prestanda. Detta resulterade i en cirka 8% minskning av skriv-I/OPS och en cirka 17% minskning av läs-I/OPS, men visar prestandasiffror som är mer representativa för vad lagringen faktiskt kan göra.
I följande diagram visar testningen att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 120 000 rena slumpmässiga 4-KiB-skrivningar och cirka 388 000 rena slumpmässiga 4-KiB-läsningar. Läs-skriv-mix för arbetsbelastningen justerad med 25 % för varje körning.
I takt med att I/OP-mixen för läs- och skrivåtgärder ökar till skrivintensiv minskar den totala I/OPS.
Resultat: 8 KiB, slumpmässig, klientcachelagring exkluderad
Större läs- och skrivstorlekar resulterar i färre totala I/OPS eftersom mer data kan skickas med varje åtgärd. En läs- och skrivstorlek på 8 KiB användes för att mer exakt simulera vad de flesta moderna program använder. Till exempel använder många EDA-program 8-KiB-läsningar och skrivningar.
I det här riktmärket körde FIO med randrepeat=0 för att randomisera data så att effekten av klientcachelagring minskade. I följande diagram visar testning att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 111 000 rena slumpmässiga 8-KiB-skrivningar och cirka 293 000 rena slumpmässiga 8-KiB-läsningar. Läs-skriv-mix för arbetsbelastningen justerad med 25 % för varje körning.
I takt med att I/OP-mixen för läs- och skrivåtgärder ökar till skrivintensiv minskar den totala I/OPS.
Jämförelser sida vid sida
För att illustrera hur cachelagring kan påverka prestandatesterna visar följande diagram totalt I/OPS för 4-KiB-tester med och utan cachelagringsmekanismer på plats. Som vi ser ger cachelagring en liten prestandaökning för I/OPS ganska konsekventa trender.
Specifik förskjutning, direktuppspelning av slumpmässiga läs-/skrivarbetsbelastningar: uppskalningstester med parallella nätverksanslutningar (nconnect)
Följande tester visar ett högt I/OP-riktmärke med en enskild klient med slumpmässiga arbetsbelastningar med 4 KiB och en 1 TiB-datauppsättning. Den arbetsbelastningsmix som genereras använder olika I/O-djup varje gång. För att öka prestandan för en enskild klientarbetsbelastning användes monteringsalternativet nconnect för att förbättra parallelliteten jämfört med klientmonteringar utan monteringsalternativetnconnect.
När du använder en standard-TCP-anslutning som endast tillhandahåller en enda sökväg till lagringen skickas färre totala åtgärder per sekund än när en montering kan utnyttja fler TCP-anslutningar (till exempel med nconnect) per monteringspunkt. När du använder nconnectär den totala svarstiden för åtgärderna vanligtvis lägre. Dessa tester körs också med randrepeat=0 för att avsiktligt undvika cachelagring. Mer information om det här alternativet finns i Testmetodik.
Resultat: 4 KiB, slumpmässigt, med och utan nconnect, cachelagring exkluderad
Följande diagram visar en jämförelse sida vid sida av 4-KiB-läsningar och skrivningar med och utan nconnect för att markera de prestandaförbättringar som visas när du använder nconnect: högre övergripande I/OPS, lägre svarstid.
Prestandamått för högt dataflöde
Följande riktmärken visar prestanda för Azure NetApp Files med hög dataflödesarbetsbelastning.
Arbetsbelastningar med högt dataflöde är mer sekventiella och är ofta läs-/skrivintensiva med låga metadata. Dataflödet är vanligtvis viktigare än I/OPS. Dessa arbetsbelastningar använder vanligtvis större läs-/skrivstorlekar (64K till 256 000), vilket genererar högre svarstider än mindre läs-/skrivstorlekar, eftersom större nyttolaster naturligtvis tar längre tid att bearbeta.
Exempel på arbetsbelastningar med högt dataflöde är:
- Medielagringsplatser
- Databehandling med höga prestanda
- AI/ML/LLP
Följande tester visar ett prestandamått för högt dataflöde med både 64-KiB- och 256-KiB-sekventiella arbetsbelastningar och en 1-TiB-datauppsättning. Den genererade arbetsbelastningsmixen minskar en viss procentandel i taget och visar vad du kan förvänta dig när du använder varierande läs-/skrivkvoter (till exempel 100%:0%, 90%:10%, 80%:20%och så vidare).
Resultat: 64 KiB sekventiell I/O, cachelagring ingår
I det här riktmärket körde FIO med hjälp av loopningslogik som mer aggressivt fyllde cachen, så en obestämd mängd cachelagring påverkade resultatet. Detta resulterar i något bättre övergripande prestandasiffror än tester som körs utan cachelagring.
I diagrammet nedan visar testning att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 4 500MiB/s rena sekventiella 64-KiB-läsningar och cirka 1 600MiB/s rena sekventiella 64-KiB-skrivningar. Läs-skriv-mixen för arbetsbelastningen justerades med 10 % för varje körning.
Resultat: 64 KiB sekventiell I/O, läsning jämfört med skrivning, baslinje utan cachelagring
I det här baslinjemåttet visar testningen att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 3 600 MiB/s rena sekventiella 64-KiB-läsningar och cirka 2 400 MiB/sekund rena sekventiella 64-KiB-skrivningar. Under testerna visade en 50/50-blandning totalt dataflöde i nivå med en ren sekventiell läsarbetsbelastning.
När det gäller ren läsning presterade 64-KiB-baslinjen något bättre än 256-KiB-baslinjen. När det gäller ren skrivning och alla blandade läs-/skrivarbetsbelastningar överträffade dock 256 KiB-baslinjen 64 KiB, vilket indikerar att en större blockstorlek på 256 KiB är effektivare generellt för arbetsbelastningar med högt dataflöde.
Läs-skriv-mixen för arbetsbelastningen justerades med 25 % för varje körning.
Resultat: 256 KiB sekventiell I/O utan cachelagring
I följande två baslinjemått användes FIO för att mäta mängden sekventiell I/O (läsning och skrivning) som en enda vanlig volym i Azure NetApp Files kan leverera. För att skapa en baslinje som återspeglar den verkliga bandbredd som en helt oanvänd läsarbetsbelastning kan uppnå, konfigurerades FIO att köras med parametern randrepeat=0 för datauppsättningsgenerering. Varje test iteration förskjuts genom att läsa en helt separat stor datamängd som inte är en del av riktmärket för att rensa eventuell cachelagring som kan ha inträffat med benchmark-datauppsättningen.
I det här diagrammet visar testningen att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 3 500 MiB/s rena sekventiella 256-KiB-läsningar och cirka 2 500 MiB/s rena sekventiella 256-KiB-skrivningar. Under testerna visade en 50/50-blandning att det totala dataflödet nådde en högre topp än en ren sekventiell läsarbetsbelastning.
Parallella nätverksanslutningar (nconnect)
Följande tester visar ett högt I/OP-riktmärke med en enskild klient med slumpmässiga arbetsbelastningar med 64 KiB och en 1 TiB-datauppsättning. Den arbetsbelastningsmix som genereras använder olika I/O-djup varje gång. För att öka prestandan för en enskild klientarbetsbelastning utnyttjades monteringsalternativet nconnect för bättre parallellitet jämfört med klientmonteringar som inte använde monteringsalternativet nconnect . Dessa tester kördes endast med cachelagring undantagen.
Resultat: 64KiB sekventiell I/O, jämförelse av dataflödescache
För att visa hur cachelagring påverkar prestandaresultaten användes FIO i följande jämförelse av mikromått för att mäta mängden sekventiell I/O (läsning och skrivning) som en enda vanlig volym i Azure NetApp Files kan leverera. Det här testet kontrasteras mot de fördelar som en delvis cachebar arbetsbelastning kan ge.
I resultatet utan cachelagring utformades testningen för att minimera eventuell cachelagring enligt beskrivningen i referensvärdena ovan.
I det andra resultatet användes FIO mot vanliga Azure NetApp Files-volymer utan parametern randrepeat=0 och med hjälp av en looptest iterationslogik som långsamt fyllde cachen över tid. Kombinationen av dessa faktorer gav en obestämd mängd cachelagring, vilket ökade det totala dataflödet. Den här konfigurationen resulterade i något bättre övergripande läsprestandasiffror än tester som körs utan cachelagring.
Testresultaten som visas i diagrammet visar jämförelsen sida vid sida av läsprestanda med och utan cachelagringspåverkan, där cachelagring producerade upp till ~4 500 MiB/sekunds läsdataflöde, medan ingen cachelagring uppnåddes runt ~3 600 MiB/sekund.
Jämförelse sida vid sida (med och utan nconnect)
Följande diagram visar en jämförelse sida vid sida av sekventiella läsningar och skrivningar med 64 KiB med och utan nconnect för att markera de prestandaförbättringar som visas när du använder nconnect: högre övergripande dataflöde, lägre svarstid.
