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, vyloučené ukládání do mezipaměti
V tomto srovnávacím testu fio běžela pomocí logiky smyčky, která méně agresivně naplňovala mezipaměť. Ukládání do mezipaměti klienta nemělo vliv na výsledky. Výsledkem této konfigurace jsou mírně lepší čísla výkonu zápisu, ale nižší čísla čtení než testy 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ě 3 600MiB/s čistě sekvenčních 64 KiB čtení a přibližně 2 400MiB/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í.
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, vyloučené ukládání do mezipaměti
V tomto srovnávacím testu se FIO spustilo pomocí logiky smyčky, která méně agresivně naplnila mezipaměť, takže ukládání do mezipaměti nemělo vliv na výsledky. Výsledkem této konfigurace je o něco méně výkonu zápisu než 64 testů KiB, ale vyšší čísla čtení než stejná 64-KiB testy běží 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ě 3 500MiB/s čistě sekvenčních 256-KiB čtení a přibližně 2 500MiB/s čistě sekvenčních 256-KiB zápisů. Během testů ukázala kombinace 50/50 celkovou propustnost vyšší než čistě sekvenční úloha čtení.
Kombinace čtení a zápisu pro úlohu byla upravena v 25% přírůstcích pro každé spuštění.
Souběžné porovnání
Aby bylo možné lépe ukázat, 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 miB/s pro 64 testů KiB s mechanismy ukládání do mezipaměti a bez jejich použití. Ukládání do mezipaměti poskytuje počáteční mírné zvýšení výkonu pro celkový počet MiB/s, protože ukládání do mezipaměti obecně zlepšuje čtení více než zápisy. Při změně kombinace čtení a zápisu celková propustnost bez ukládání do mezipaměti překračuje výsledky, které využívají ukládání do mezipaměti klienta.
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: 64 KiB, sekvenční, ukládání do mezipaměti vyloučené a bez nconnect
Následující výsledky ukazují výsledky testu vertikálního navýšení kapacity při čtení a zápisu do bloků 4 KiB na připojení NFSv3 k jednomu klientovi s paralelizací operací (nconnect). Grafy ukazují, že s rostoucí hloubkou vstupně-výstupních operací se také zvyšuje vstupně-výstupní operace. Pokud ale používáte standardní připojení TCP, které poskytuje pouze jednu cestu k úložišti, odesílá se méně celkových operací za sekundu, než když připojení dokáže využít více připojení TCP na přípojný bod. Kromě toho je celková latence operací obecně nižší při použití nconnect.
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.
