Srovnávací testy výkonu běžných svazků služby Azure NetApp Files pro Linux
Tento článek popisuje srovnávací testy výkonu, které Azure NetApp Files poskytuje pro Linux s pravidelným objemem.
Úlohy streamování celých souborů (srovnávací testy horizontálního navýšení kapacity)
Cílem testu horizontálního navýšení kapacity je ukázat výkon svazku Azure NetApp File při horizontálním navýšení kapacity (nebo zvýšení) počtu klientů, kteří generují souběžné úlohy na stejný svazek. Tyto testy jsou obecně schopné odeslat svazek na okraj svých limitů výkonu a ukazují na úlohy, jako je vykreslování médií, AI/ML a další úlohy, které k provádění práce využívají velké výpočetní farmy.
Vysoká konfigurace srovnávacích testů horizontálního navýšení kapacity vstupně-odchozích operací
Tyto srovnávací testy používaly následující:
- Jeden běžný svazek Azure NetApp Files 100-TiB s datovou sadou 1 TiB s úrovní výkonu Ultra
- FIO (s nastavením randrepeat=0 a bez nastavení)
- Velikosti bloků 4 KiB a 8-KiB
- 6 D32s_v5 virtuálních počítačů s RHEL 9.3
- NFSv3
- Ruční QoS
- Možnosti připojení: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfigurace srovnávacího testu s vysokou propustností na více instancí
Tyto srovnávací testy používaly následující:
- Jeden běžný svazek Azure NetApp Files s datovou sadou 1 TiB pomocí FIO úrovně výkonu Úrovně Ultra (s nastavením randrepeat=0)
- FIO (s nastavením randrepeat=0 a bez nastavení)
- Velikost bloku 64 KiB a 256-KiB
- 6 D32s_v5 virtuálních počítačů s RHEL 9.3
- NFSv3
- Ruční QoS
- Možnosti připojení: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfigurace srovnávacího testu paralelního síťového připojenínconnect
Tyto srovnávací testy používaly následující:
- Jeden běžný svazek Azure NetApp Files s datovou sadou 1 TiB pomocí úrovně výkonu Ultra
- FIO (s nastavením randrepeat=0 a bez nastavení)
- 4-KiB a 64-KiB wsize/rsize
- Jeden D32s_v4 virtuální počítač s RHEL 9.3
- NFSv3 s a bez
nconnect - Možnosti připojení: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Testy srovnávacích testů vertikálního navýšení kapacity
Záměrem testu vertikálního navýšení kapacity je ukázat výkon svazku Azure NetApp File při vertikálním navýšení kapacity (nebo zvýšení) počtu úloh, které generují souběžné úlohy napříč několika připojeními TCP na jednom klientovi ke stejnému svazku (například pomocí nconnect).
Bez nconnecttěchto úloh nejde nasdílit limity maximálního výkonu svazku, protože klient nemůže vygenerovat dostatek vstupně-výstupních operací nebo propustnosti sítě. Tyto testy obecně naznačují, co může být prostředí jednoho uživatele v úlohách, jako je vykreslování médií, databáze, AI/ML a obecné sdílené složky.
Srovnávací testy horizontálního navýšení kapacity pro vysoké vstupně-provozní operace
Následující srovnávací testy ukazují výkon dosažený pro Azure NetApp Files s vysokou zátěží vstupně-výstupních operací pomocí:
- 32 klientů
- 4-KiB a 8-KiB náhodné čtení a zápisy
- Datová sada 1 TiB
- Poměry čtení a zápisu: 100%:0%, 90%:10%, 80%:20% atd.
- Ukládání do mezipaměti systému souborů (použití
randrepeat=0v ROZHRANÍ FIO) a bez systému souborů
Další informace najdete v části Metodologie testování.
Výsledky: 4 KiB, náhodné, zahrnuté ukládání do mezipaměti klienta
V tomto srovnávacím testu fio běžela bez randrepeat možnosti randomizovat data. Proto se objevilo nedeterminovat množství ukládání do mezipaměti. Výsledkem této konfigurace je mírně lepší celkový výkon než spouštění testů bez ukládání do mezipaměti s využitím celého zásobníku vstupně-výstupních operací.
V následujícím grafu testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 130 000 čistých náhodných zápisů 4 KiB a přibližně 460 000 čistých náhodných 4 KiB čtení během tohoto srovnávacího testu. Kombinace čtení a zápisu pro úlohu upravená o 10 % pro každé spuštění.
Vzhledem k tomu, že se kombinace I/OP pro čtení a zápis zvyšuje směrem k vysokému zatížení zápisu, celkové I/OPS se snižuje.
Výsledky: 4 KiB, náhodné, klientské ukládání do mezipaměti vyloučené
V tomto srovnávacím testu se fio spustilo s nastavením randrepeat=0 pro náhodnou velikost dat, což snižuje vliv ukládání do mezipaměti na výkon. Výsledkem je přibližně 8 % snížení počtu I/OPS zápisu a přibližně 17% snížení počtu čtení I/OPS, ale zobrazuje čísla výkonu, která jsou více reprezentativní pro to, co může úložiště skutečně dělat.
V následujícím grafu testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 120 000 čistých náhodných zápisů 4 KiB a přibližně 388 000 čistých náhodných čtení 4 KiB. Kombinace čtení a zápisu pro úlohu upravená o 25 % pro každé spuštění
Vzhledem k tomu, že se kombinace I/OP pro čtení a zápis zvyšuje směrem k vysokému zatížení zápisu, celkové I/OPS se snižuje.
Výsledky: 8 KiB, náhodné, vyloučené ukládání do mezipaměti klienta
Větší velikosti čtení a zápisu budou mít za následek menší celkový počet V/OPS, protože s každou operací je možné odeslat více dat. K přesnější simulaci toho, co většina moderních aplikací používá, byla použita velikost čtení a zápisu 8 KiB. Mnoho aplikací EDA například využívá 8 KiB čtení a zápisů.
V tomto srovnávacím testu se fio spustilo s náhodným určením randrepeat=0 dat, aby se snížil dopad na ukládání do mezipaměti klienta. V následujícím grafu testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 111 000 čistých náhodných zápisů 8 KiB a přibližně 293 000 čistých náhodných 8 KiB čtení. Kombinace čtení a zápisu pro úlohu upravená o 25 % pro každé spuštění
Vzhledem k tomu, že se kombinace I/OP pro čtení a zápis zvyšuje směrem k vysokému zatížení zápisu, celkové I/OPS se snižuje.
Porovnání vedle sebe
Abychom si ukázali, jak ukládání do mezipaměti může ovlivnit testy srovnávacích testů výkonnosti, následující graf ukazuje celkový počet I/OPS pro testy 4 KiB s mechanismy ukládání do mezipaměti a bez jejich ukládání do mezipaměti. Jak je znázorněno, ukládání do mezipaměti poskytuje mírné zvýšení výkonu pro I/OPS poměrně konzistentní trend.
Specifický posun, úlohy náhodného čtení a zápisu streamování: testy vertikálního navýšení kapacity s využitím paralelních síťových připojení (nconnect)
Následující testy ukazují vysoký srovnávací test vstupně-výstupních operací s jedním klientem s náhodnými úlohami 4 KiB a datovou sadou 1 TiB. Vygenerovaná kombinace úloh pokaždé používá jinou hloubku vstupně-výstupních operací. Kvůli zvýšení výkonu pro jednu úlohu nconnect klienta se možnost připojení použila ke zlepšení paralelismu v porovnání s připojeními klientů bez nconnect možnosti připojení.
Při použití standardního připojení TCP, které poskytuje pouze jednu cestu k úložišti, se odesílá méně celkových operací za sekundu, než když připojení dokáže využívat více připojení TCP (například s nconnect) na přípojný bod. Při použití nconnectje celková latence operací obecně nižší. Tyto testy se také spouštějí, randrepeat=0 aby se záměrně vyhnuly ukládání do mezipaměti. Další informace o této možnosti najdete v části Metodologie testování.
Výsledky: 4 KiB, náhodné, s a bez nconnect, ukládání do mezipaměti vyloučeno
Následující grafy ukazují souběžné porovnání 4 KiB čtení a zápisů se 4 KiB a bez nconnect toho, aby se zvýraznily vylepšení výkonu při použití nconnect: vyšší celková I/OPS, nižší latence.
Srovnávací testy s vysokou propustností
Následující srovnávací testy ukazují výkon pro Azure NetApp Files s vysokou propustností.
Úlohy s vysokou propustností jsou v podstatě sekvenční a často jsou náročné na čtení a zápis s nízkými metadaty. Propustnost je obecně důležitější než V/OPS. Tyto úlohy obvykle využívají větší velikosti čtení a zápisu (64K až 256 K), které generují vyšší latenci než menší velikosti čtení a zápisu, protože zpracování větších datových částí bude přirozeně trvat déle.
Mezi příklady úloh s vysokou propustností patří:
- Úložiště médií
- Vysokovýkonné výpočetní prostředí
- AI/ML/LLP
Následující testy ukazují srovnávací test s vysokou propustností s využitím sekvenčních úloh 64-KiB i 256-KiB a datové sady 1 TiB. Kombinace úloh vygenerovaná snižuje nastavené procento najednou a ukazuje, co můžete očekávat při použití různých poměrů čtení a zápisu (například 100%:0%, 90%:10%, 80%:20% atd.).
Výsledky: 64 KiB sekvenční vstupně-výstupní operace, zahrnuté ukládání do mezipaměti
V tomto srovnávacím testu se FIO spustilo pomocí logiky smyčky, která agresivně naplnila mezipaměť, takže nedeterminované množství ukládání do mezipaměti ovlivnilo výsledky. Výsledkem je mírně lepší celkový výkon než spouštění testů bez ukládání do mezipaměti.
V následujícím grafu testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 4 500MiB/s čistě sekvenčních 64 KiB čtení a přibližně 1 600MiB/s čistě sekvenčních zápisů 64 KiB. Kombinace čtení a zápisu pro úlohu byla pro každé spuštění upravena o 10 %.
Výsledky: 64 KiB sekvenční vstupně-výstupní operace, čtení vs. zápis, směrný plán bez ukládání do mezipaměti
V tomto srovnávacím testu standardních hodnot testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 3 600 MiB/s čistě sekvenčních 64 KiB a přibližně 2 400 MiB/s čistých sekvenčních zápisů 64 KiB. Během testů ukázala kombinace 50/50 celkovou propustnost na stejné hodnotě s čistě sekvenční úlohou čtení.
Vzhledem k čistému čtení se směrný plán 64-KiB mírně zlepšil než směrný plán 256-KiB. Pokud jde o čisté úlohy zápisu a všech smíšených úloh čtení a zápisu, ale 256-KiB standardních hodnot přesahuje 64 KiB, což znamená, že větší velikost bloku 256 KiB je celkově efektivnější pro úlohy s vysokou propustností.
Kombinace čtení a zápisu pro úlohu byla pro každé spuštění upravena o 25 %.
Výsledky: 256 KiB sekvenční vstupně-výstupní operace bez ukládání do mezipaměti
V následujících dvou standardních srovnávacích testech se fiO použilo k měření množství sekvenčních vstupně-výstupních operací (čtení a zápisu) jednoho běžného svazku v Azure NetApp Files, který může poskytovat. Aby bylo možné vytvořit směrný plán, který odráží skutečnou šířku pásma, kterou může dosáhnout plně necached čtení, bylo fiO nakonfigurováno tak, aby běželo s parametrem randrepeat=0 pro generování sady dat. Každá iterace testů byla posunována čtením zcela samostatné velké datové sady, která není součástí srovnávacího testu, aby bylo možné vymazat veškeré ukládání do mezipaměti, ke kterým mohlo dojít u datové sady srovnávacích testů.
V tomto grafu testování ukazuje, že běžný svazek Azure NetApp Files dokáže zpracovat přibližně 3 500 MiB/s čistě sekvenčních 256-KiB čtení a přibližně 2 500 MiB/s čistě sekvenčních 256 zápisů KiB. Během testů ukázala kombinace 50/50 celkovou propustnost vyšší než čistě sekvenční úloha čtení.
Paralelní síťová připojení (nconnect)
Následující testy ukazují vysoký srovnávací test vstupně-výstupních operací pomocí jednoho klienta s náhodnými úlohami 64 KiB a datovou sadou 1 TiB. Vygenerovaná kombinace úloh pokaždé používá jinou hloubku vstupně-výstupních operací. Aby se zvýšil výkon jedné úlohy klienta, nconnect byla možnost připojení využita pro lepší paralelismus ve srovnání s připojeními klientů, které možnost připojení nepoužívala nconnect . Tyto testy byly spuštěny pouze s vyloučeným ukládáním do mezipaměti.
Výsledky: 64KiB sekvenční vstupně-výstupní operace, porovnání mezipaměti propustnosti čtení
Abychom si ukázali, jak ukládání do mezipaměti ovlivňuje výsledky výkonu, použilo se FIO v následujícím porovnání mikro srovnávacích testů k měření množství sekvenčních vstupně-výstupních operací (čtení a zápisu) jednoho běžného svazku v Azure NetApp Files, který dokáže doručovat. Tento test je kontrastován s výhodami, které může poskytnout částečně uložená úloha v mezipaměti.
Výsledkem bez ukládání do mezipaměti bylo testování navržené tak, aby zmírnit veškeré ukládání do mezipaměti, jak je popsáno ve výše uvedených standardních srovnávacích testech.
V druhém výsledku se funkce FIO použila pro běžné svazky Azure NetApp Files bez parametru randrepeat=0 a pomocí logiky iterace testů smyčky, která v průběhu času pomalu naplňovala mezipaměť. Kombinace těchto faktorů vytvořila nedeterminované množství ukládání do mezipaměti, což zvyšuje celkovou propustnost. Tato konfigurace vedla k mírně lepšímu celkovému výkonu čtení než spouštění testů bez ukládání do mezipaměti.
Výsledky testů zobrazené v grafu zobrazují souběžné porovnání výkonu čtení s vlivem ukládání do mezipaměti a bez vlivu ukládání do mezipaměti, kdy se ukládání do mezipaměti vytvořilo až přibližně 4 500 MiB za sekundu, zatímco ukládání do mezipaměti se nedosáhne přibližně ~3600 MiB za sekundu.
Souběžné porovnání (s a bez nconnect)
Následující grafy ukazují souběžné porovnání se sekvenčními čteními a zápisy 64 KiB a bez nconnect toho, aby se zvýraznily vylepšení výkonu při použití nconnect: vyšší celková propustnost, nižší latence.
