Oktatás
Modul
Ismerje meg, hogyan javíthatja az Azure NetApp Files teljesítményét az EDA- és HPC-alkalmazások esetében az ajánlott eljárások használatával.
Az Azure NetApp Files rendszeres mennyiségi teljesítménymutatói Linuxhoz
Ez a cikk az Azure NetApp Files linuxos, normál kötettel nyújtott teljesítménymutatóit ismerteti.
A horizontális felskálázási teszt célja egy Azure NetApp-fájlkötet teljesítményének megjelenítése az egyidejű számítási feladatot ugyanazon kötetre létrehozó ügyfelek számának horizontális felskálázása (vagy növelése) során. Ezek a tesztek általában képesek egy kötetet a teljesítménykorlátok peremére küldeni, és olyan számítási feladatokra utalnak, mint a médiamegjelenítés, az AI/ML és más számítási feladatok, amelyek nagy számítási farmokat használnak a munka elvégzéséhez.
Ezek a teljesítménymutatók a következőket használták:
- Egyetlen Azure NetApp Files 100-TiB normál kötet 1 TiB-adatkészlettel az Ultra teljesítményszint használatával
- FIO (a randrepeat=0 beállítással és anélkül)
- 4-KiB és 8 KiB blokkméretek
- 6 D32s_v5 RHEL 9.3-at futtató virtuális gépek
- NFSv3
- Manuális QoS
- Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Ezek a teljesítménymutatók a következőket használták:
- Egyetlen Normál Azure NetApp Files-kötet 1 TiB-adatkészlettel az Ultra teljesítményszint fiO használatával (a randrepeat=0 beállítással és anélkül)
- FIO (a randrepeat=0 beállítással és anélkül)
- 64 KiB és 256 KiB blokkméret
- 6 D32s_v5 RHEL 9.3-at futtató virtuális gépek
- NFSv3
- Manuális QoS
- Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Ezek a teljesítménymutatók a következőket használták:
- Egyetlen Normál Azure NetApp Files-kötet 1 TiB-adatkészlettel az Ultra teljesítményszint használatával
- FIO (a randrepeat=0 beállítással és anélkül)
- 4-KiB és 64-KiB wsize/rsize
- Egyetlen D32s_v4 RHEL 9.3-at futtató virtuális gép
- NFSv3 with and without
nconnect - Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
A vertikális felskálázási teszt célja egy Azure NetApp-fájlkötet teljesítményének megjelenítése, amikor felskálázza (vagy növeli) azon feladatok számát, amelyek egyszerre több TCP-kapcsolaton keresztül hoznak létre egyszerre több TCP-kapcsolatot ugyanazon a köteten (például a ).nconnect
Nélkülük nconnectezek a számítási feladatok nem tudják leküldeni a kötet maximális teljesítményének korlátait, mivel az ügyfél nem tud elegendő IO- vagy hálózati átviteli sebességet generálni. Ezek a tesztek általában azt jelzik, hogy egy felhasználó milyen felhasználói élményt érhet el olyan számítási feladatokban, mint a médialeképezés, az adatbázisok, az AI/ML és az általános fájlmegosztások.
Az alábbi teljesítménymutatók a magas I/OP-számítási feladatokkal rendelkező Azure NetApp Files esetében elért teljesítményt mutatják be:
- 32 ügyfél
- 4-KiB és 8-KiB véletlenszerű olvasások és írások
- 1 TiB adatkészlet
- Olvasási/írási arányok az alábbiak szerint: 100%:0%, 90%:10%, 80%:20% stb.
- Fájlrendszer-gyorsítótárazással és anélkül (a FIO használatával
randrepeat=0)
További információ: Tesztelési módszertan.
Ebben a teljesítménytesztben a FIO anélkül futott, hogy lehetőség volt az randrepeat adatok véletlenszerűsítésére. Így meghatározhatatlan mennyiségű gyorsítótárazás került a játékba. Ez a konfiguráció valamivel jobb általános teljesítményszámokat eredményez, mint a tesztek, amelyek gyorsítótárazás nélkül futnak a teljes IO-verem használatával.
A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 130 000 tiszta véletlenszerű 4 KiB-írás és körülbelül 460 000 tiszta véletlenszerű 4 KiB-olvasás között képes kezelni a teljesítményteszt során. Olvasási-írási mix a számítási feladathoz 10%-kal módosítva minden futtatáshoz.
Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.
Ebben a teljesítménytesztben a FIO az adatok véletlenszerűsítésére szolgáló beállítással randrepeat=0 lett futtatva, csökkentve a teljesítményre gyakorolt gyorsítótárazási hatást. Ez körülbelül 8%-os csökkenést eredményezett az írási I/OPS-ben, és körülbelül 17%-kal csökkentette az olvasási I/OPS-t, de a teljesítményszámokat jobban reprezentatívan jeleníti meg, hogy a tároló valójában mire képes.
A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 120 000 tiszta véletlenszerű 4 KiB-írás és körülbelül 388 000 tiszta véletlenszerű 4 KiB-olvasás között képes kezelni. Olvasási-írási mix a számítási feladathoz 25%-kal módosítva minden futtatáshoz.
Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.
A nagyobb olvasási és írási méretek kevesebb I/OPS-t eredményeznek, mivel minden művelettel több adat küldhető el. A 8 KiB-s olvasási és írási méret pontosabban szimulálta a legtöbb modern alkalmazást. Sok EDA-alkalmazás például 8 KiB olvasást és írást használ.
Ebben a teljesítménytesztben a FIO az adatok véletlenszerűsítésére randrepeat=0 futott, így az ügyfél gyorsítótárazási hatása csökkent. A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 111 000 tiszta véletlenszerű 8 KiB-írás és körülbelül 293 000 tiszta véletlenszerű 8 KiB-olvasás között képes kezelni. Olvasási-írási mix a számítási feladathoz 25%-kal módosítva minden futtatáshoz.
Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.
Annak szemléltetésére, hogy a gyorsítótárazás hogyan befolyásolhatja a teljesítménymutató-teszteket, az alábbi grafikon a 4 kiB-tesztek teljes I/OPS-ét mutatja be gyorsítótárazási mechanizmusokkal és anélkül. Ahogy látható, a gyorsítótárazás enyhe teljesítménynövelést biztosít az I/OPS viszonylag konzisztens trendjeihez.
Specifikus eltolás, véletlenszerű olvasási/írási számítási feladatok streamelése: párhuzamos hálózati kapcsolatok használatával végzett vertikális felskálázási tesztek (nconnect)
Az alábbi tesztek egy magas I/OP-teljesítményt mutatnak egy 4 KiB véletlenszerű számítási feladatokkal és egy 1 TiB-adatkészlettel rendelkező ügyfél használatával. A létrehozott számítási feladatok keveréke minden alkalommal eltérő I/O-mélységet használ. Az egyetlen ügyfél-számítási feladat teljesítményének növelése érdekében a csatlakoztatási nconnect lehetőség a csatlakoztatási lehetőség nélküli nconnect ügyfélcsatlakozásokhoz képest a párhuzamosság javítására szolgál.
Ha olyan szabványos TCP-kapcsolatot használ, amely csak egyetlen elérési utat biztosít a tárolóhoz, a rendszer másodpercenként kevesebb teljes műveletet küld el, mint amikor a csatlakoztatás több TCP-kapcsolatot képes kihasználni (például nconnect) csatlakoztatási pontonként. Használat nconnectesetén a műveletek teljes késése általában alacsonyabb. Ezek a tesztek a gyorsítótárazás szándékos elkerülése érdekében is futnak randrepeat=0 . Erről a lehetőségről további információt a Tesztelési módszertan című témakörben talál.
Az alábbi grafikonok a 4 KiB-olvasások és -írások egymás melletti összehasonlítását mutatják be, és nem nconnect emelik ki a használat nconnectsorán tapasztalt teljesítménybeli javulást: magasabb általános I/OPS, alacsonyabb késés.
Az alábbi teljesítménymutatók a nagy átviteli sebességű számítási feladatokkal rendelkező Azure NetApp Files esetében elért teljesítményt mutatják be.
A nagy átviteli sebességű számítási feladatok szekvenciálisabbak a természetben, és gyakran alacsony metaadatokat tartalmazó olvasási/írási nehézkesek. Az átviteli sebesség általában fontosabb, mint az I/OPS. Ezek a számítási feladatok általában nagyobb olvasási/írási méreteket használnak (64K–256K), ami nagyobb késéseket eredményez, mint a kisebb olvasási/írási méretek, mivel a nagyobb hasznos adatok feldolgozása természetesen tovább tart.
A nagy átviteli sebességű számítási feladatok például a következők:
- Médiatárak
- Nagy teljesítményű számítás
- AI/ML/LLP
Az alábbi tesztek egy magas átviteli teljesítménytesztet mutatnak, amely 64 KiB és 256 KiB szekvenciális számítási feladatokat és egy 1 TiB-adatkészletet használ. A létrehozott számítási feladatok keveréke egyszerre csökkenti a megadott százalékos értéket, és bemutatja, hogy mire számíthat a változó olvasási/írási arányok használatakor (például 100%:0%, 90%:10%, 80%:20%stb.).
Ebben a teljesítménytesztben a FIO olyan cikluslogikával futott, amely agresszívabban feltöltötte a gyorsítótárat, így a gyorsítótárazás meghatározatlan mennyisége befolyásolta az eredményeket. Ez valamivel jobb általános teljesítményt eredményez, mint a gyorsítótárazás nélkül futtatott tesztek.
Az alábbi ábrán a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 4500MiB/s tiszta szekvenciális 64 KiB-olvasás és körülbelül 1600MiB/s tiszta szekvenciális 64 KiB-írás között képes kezelni. A számítási feladat írási és olvasási mixe minden futtatás esetében 10%-kal lett módosítva.
Ebben az alapkonfigurációban a tesztelés azt mutatja be, hogy az Azure NetApp Files normál kötete körülbelül 3600 MiB/s tiszta szekvenciális 64 KiB-olvasás és körülbelül 2400 MiB/másodperc tiszta szekvenciális 64 KiB-írás között képes kezelni. A tesztek során az 50/50-es mix teljes átviteli sebességet mutatott egy tiszta szekvenciális olvasási számítási feladattal.
A tiszta olvasás tekintetében a 64 KiB alapkonfiguráció valamivel jobban teljesített, mint a 256 KiB alapkonfiguráció. A tiszta írás és az összes vegyes olvasási/írási számítási feladat esetében azonban a 256-KiB alapkonfiguráció 64 KiB-t meghaladó teljesítményt eredményezett, ami azt jelzi, hogy a nagyobb, 256 KiB blokkméret hatékonyabb általánosan a nagy átviteli sebességű számítási feladatok esetében.
A számítási feladat írási és olvasási mixe minden futtatás esetében 25%-kal lett módosítva.
A következő két alapkonfigurációban a FIO-t használták a szekvenciális I/O (olvasási és írási) mennyiségének mérésére az Azure NetApp Files egyetlen normál kötetében. Annak érdekében, hogy olyan alapkonfigurációt állítson elő, amely tükrözi a teljes mértékben nem gyorsítótárazott olvasási számítási feladatok által elérhető valós sávszélességet, a FIO úgy lett konfigurálva, hogy az adatkészlet-létrehozás paraméterével randrepeat=0 fusson. Az egyes tesztelési iterációkat úgy ellensúlyozták, hogy egy teljesen különálló nagy adathalmazt olvasnak be, amely nem része a teljesítménytesztnek, hogy töröljön minden olyan gyorsítótárazást, amely a teljesítményteszt-adatkészlettel történhetett.
Ebben a grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 3500 MiB/s tiszta szekvenciális 256 KiB-olvasás és körülbelül 2500 MiB/s tiszta szekvenciális 256-KiB-írás között képes kezelni. A tesztek során egy 50/50-es mix azt mutatta, hogy a teljes átviteli sebesség magasabb volt, mint egy tiszta szekvenciális olvasási számítási feladat.
Az alábbi tesztek egy magas I/OP-teljesítményt mutatnak egyetlen ügyfél használatával, 64 KiB véletlenszerű számítási feladatokkal és egy 1 TiB-adatkészlettel. A létrehozott számítási feladatok keveréke minden alkalommal eltérő I/O-mélységet használ. Az egyetlen ügyfél-számítási feladat teljesítményének növelése érdekében a csatlakoztatási lehetőséget a nconnect jobb párhuzamosság érdekében használták a csatlakoztatási lehetőséget nem használó nconnect ügyfélcsatlakozásokhoz képest. Ezeket a teszteket csak a gyorsítótárazás kizárásával futtatták.
Annak bemutatására, hogy a gyorsítótárazás hogyan befolyásolja a teljesítményeredményeket, a FIO-t a következő mikro teljesítménymutató-összehasonlításban használták a szekvenciális I/O -k (olvasási és írási) mennyiségének mérésére az Azure NetApp Files egyetlen normál kötetében. Ez a teszt ellentétben áll a részben gyorsítótárazható számítási feladat által nyújtott előnyökkel.
A gyorsítótárazás nélküli eredmény érdekében a tesztelés célja a fenti alapértékekben leírt gyorsítótárazás enyhítése.
A másik eredményben a FIO paraméter nélkül randrepeat=0 , az Azure NetApp Files normál köteteihez lett használva, és egy ciklusos tesztelési iterációs logikát használt, amely idővel lassan feltöltötte a gyorsítótárat. E tényezők kombinációja meghatározhatatlan mennyiségű gyorsítótárazást eredményezett, ami növelte a teljes átviteli sebességet. Ez a konfiguráció valamivel jobb általános olvasási teljesítményt eredményezett, mint a gyorsítótárazás nélkül futtatott tesztek.
A gráfban megjelenített teszteredmények az olvasási teljesítmény egymás melletti összehasonlítását jelenítik meg a gyorsítótárazási hatásokkal és anélkül, ahol a gyorsítótárazás akár ~4500 MiB/másodperc olvasási átviteli sebességet is eredményezett, míg a gyorsítótárazás nem érte el a ~3600 MiB/másodpercet.
Az alábbi grafikonok a 64 KiB szekvenciális olvasások és írások egymás melletti összehasonlítását mutatják be, és nem nconnect emelik ki a használat nconnectsorán tapasztalt teljesítménybeli javulást: nagyobb általános átviteli sebesség, alacsonyabb késés.
