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, cachelagring exkluderad
I det här riktmärket körde FIO med hjälp av loopningslogik som mindre aggressivt fyllde cacheminnet. Klientcachelagring påverkade inte resultatet. Den här konfigurationen resulterar i något bättre skrivprestandanummer, men lägre läsnummer än tester utan cachelagring.
I följande diagram visar testning att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 3 600MiB/s rena sekventiella 64-KiB-läsningar och cirka 2 400MiB/s rena sekventiella 64-KiB-skrivningar. Under testerna visade en 50/50-blandning totalt dataflöde i nivå med en ren sekventiell läsarbetsbelastning.
Läs-skriv-mixen för arbetsbelastningen justerades med 25 % för varje körning.
Resultat: 256 KiB sekventiell I/O, cachelagring exkluderad
I det här riktmärket körde FIO med hjälp av loopningslogik som mindre aggressivt fyllde cachen, så cachelagringen påverkade inte resultatet. Den här konfigurationen resulterar i något mindre skrivprestandanummer än 64-KiB-tester, men högre läsnummer än samma 64-KiB-tester körs utan cachelagring.
I diagrammet nedan visar testningen att en vanlig Azure NetApp Files-volym kan hantera mellan cirka 3 500MiB/s rena sekventiella 256-KiB-läsningar och cirka 2 500MiB/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.
Läs-skriv-mixen för arbetsbelastningen justerades i steg om 25 % för varje körning.
Jämförelse sida vid sida
För att bättre visa hur cachelagring kan påverka prestandatesterna visar följande diagram totalt antal MiB/s för 64-KiB-tester med och utan cachelagringsmekanismer på plats. Cachelagring ger en initial liten prestandaökning för totalt antal MiB/s eftersom cachelagring vanligtvis förbättrar läsningar mer än skrivningar. När läs-/skrivmixen ändras överskrider det totala dataflödet utan cachelagring de resultat som använder klientcachelagring.
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: 64 KiB, sekventiell, cachelagring utesluten, med och utan nconnect
Följande resultat visar ett uppskalningstests resultat när du läser och skriver i 4-KiB-segment på en NFSv3-montering på en enskild klient med och utan parallellisering av åtgärder (nconnect). Graferna visar att när I/O-djupet växer ökar även I/OPS. Men 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 per monteringspunkt. Dessutom är den totala svarstiden för åtgärderna vanligtvis lägre när du använder nconnect.
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.
