Regularne testy porównawcze wydajności woluminu usługi Azure NetApp Files dla systemu Linux
W tym artykule opisano testy porównawcze wydajności zapewniane przez usługę Azure NetApp Files dla systemu Linux z regularnym woluminem.
Obciążenia całego przesyłania strumieniowego plików (testy porównawcze skalowane w poziomie)
Celem testu skalowalnego w poziomie jest pokazanie wydajności woluminu usługi Azure NetApp File podczas skalowania w poziomie (lub zwiększania) liczby klientów generujących jednoczesne obciążenie do tego samego woluminu. Te testy są zwykle w stanie wypchnąć wolumin do krawędzi swoich limitów wydajności i wskazują na obciążenia, takie jak renderowanie multimediów, sztuczna inteligencja/uczenie maszynowe i inne obciążenia, które wykorzystują duże farmy obliczeniowe do wykonywania pracy.
Konfiguracja testu porównawczego o dużej skali operacji we/wy na poziomie operacji we/wy
Te testy porównawcze używały następujących elementów:
- Pojedynczy wolumin regularny usługi Azure NetApp Files 100-TiB z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra
- FIO (z ustawieniem i bez ustawienia randrepeat=0)
- Rozmiary bloków 4-KiB i 8-KiB
- 6 D32s_v5 maszyn wirtualnych z systemem RHEL 9.3
- NFSv3
- Ręczne QoS
- Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfiguracja testu porównawczego o wysokiej przepływności skalowanej w poziomie
Te testy porównawcze używały następujących elementów:
- Pojedynczy wolumin regularny usługi Azure NetApp Files z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra FIO (z ustawieniem i bez ustawienia randrepeat=0)
- FIO (z ustawieniem i bez ustawienia randrepeat=0)
- 64-KiB i 256-KiB rozmiar bloku
- 6 D32s_v5 maszyn wirtualnych z systemem RHEL 9.3
- NFSv3
- Ręczne QoS
- Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Konfiguracja testu porównawczego równoległego połączenia sieciowego (nconnect
)
Te testy porównawcze używały następujących elementów:
- Pojedynczy wolumin regularny usługi Azure NetApp Files z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra
- FIO (z ustawieniem i bez ustawienia randrepeat=0)
- 4-KiB i 64-KiB wsize/rsize
- Pojedyncza maszyna wirtualna D32s_v4 z systemem RHEL 9.3
- NFSv3 z systemem i bez
nconnect
- Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Testy porównawcze skalowania w górę
Celem testu skalowania w górę jest pokazanie wydajności woluminu usługi Azure NetApp File podczas skalowania w górę (lub zwiększania) liczby zadań generujących jednoczesne obciążenie w wielu połączeniach TCP na jednym kliencie do tego samego woluminu (na przykład za pomocą nconnect
polecenia ).
Bez nconnect
systemu te obciążenia nie mogą wypychać limitów maksymalnej wydajności woluminu, ponieważ klient nie może wygenerować wystarczającej przepływności operacji we/wy lub sieci. Te testy zazwyczaj wskazują na to, co może występować w obciążeniach pojedynczego użytkownika, takich jak renderowanie multimediów, bazy danych, sztuczna inteligencja/uczenie maszynowe i ogólne udziały plików.
Testy porównawcze skalowania operacji we/wy na dużą skalę operacji we/wy na poziomie
W poniższych testach porównawczych przedstawiono wydajność osiągniętą dla usługi Azure NetApp Files z wysokim obciążeniem we/wy operacji we/wy przy użyciu:
- 32 klientów
- 4-KiB i 8-KiB losowe odczyty i zapisy
- Zestaw danych 1 TiB
- Współczynniki odczytu/zapisu w następujący sposób: 100%:0%, 90%:10%, 80%:20%itd.
- W przypadku buforowania systemu plików i bez systemu plików (przy użyciu funkcji
randrepeat=0
FIO)
Aby uzyskać więcej informacji, zobacz Metodologia testowania.
Wyniki: 4 KiB, losowe, buforowanie klienta uwzględnione
W tym teściu porównawczym narzędzie FIO działało bez randrepeat
opcji losowania danych. W związku z tym, nieokreślona ilość buforowania weszła w grę. Ta konfiguracja powoduje nieco lepszą ogólną liczbę wydajności niż testy uruchamiane bez buforowania przy użyciu całego stosu operacji we/wy.
Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 130 000 czystych losowych zapisów 4-KiB i około 460 000 czystych losowych operacji odczytu KiB podczas tego testu porównawczego. Kombinacja odczytu i zapisu dla obciążenia dostosowanego o 10% dla każdego przebiegu.
W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.
Wyniki: 4 KiB, losowe, wykluczone buforowanie klienta
W tym teściu porównawczym funkcja FIO została uruchomiona z ustawieniem randrepeat=0
w celu losowania danych, co zmniejsza wpływ buforowania na wydajność. Spowodowało to około 8% zmniejszenie liczby operacji we/wy zapisu i około 17% redukcji operacji we/wy odczytu i operacji OPS, ale wyświetla liczby wydajności bardziej reprezentatywne dla tego, co magazyn może rzeczywiście zrobić.
Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 120 000 czystych losowych zapisów 4-KiB i około 388 000 czystych losowych operacji odczytu 4 KiB. Mieszanka odczytu i zapisu dla obciążenia dostosowanego o 25% dla każdego przebiegu.
W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.
Wyniki: 8 KiB, losowe, wykluczone buforowanie klienta
Większe rozmiary odczytu i zapisu spowodują mniejszą łączną liczbę operacji we/wy na platformie OPS, ponieważ więcej danych można wysyłać przy użyciu każdej operacji. Rozmiar odczytu i zapisu 8 KiB został użyty do dokładniejszego symulowania tego, czego używają większość nowoczesnych aplikacji. Na przykład wiele aplikacji EDA korzysta z odczytów i zapisów 8-KiB.
W tym tezie porównawczym narzędzie FIO zostało uruchomione z randrepeat=0
poleceniem w celu losowania danych, aby zmniejszyć wpływ buforowania klienta. Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 111 000 czystych losowych zapisów 8-KiB i około 293 000 czystych losowych odczytów 8-KiB. Mieszanka odczytu i zapisu dla obciążenia dostosowanego o 25% dla każdego przebiegu.
W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.
Porównania równoległe
Aby zilustrować, jak buforowanie może wpływać na testy porównawcze wydajności, na poniższym wykresie przedstawiono łączną liczbę testów we/wy na platformie OPS dla testów 4-KiB z mechanizmami buforowania i bez ich przechowywania. Jak pokazano, buforowanie zapewnia niewielki wzrost wydajności dla operacji we/wy na platformie OPS dość spójny trend.
Określone przesunięcie, przesyłanie strumieniowe losowych obciążeń odczytu/zapisu: testy skalowania w górę przy użyciu równoległych połączeń sieciowych (nconnect
)
Poniższe testy pokazują wysoki test porównawczy operacji we/wy przy użyciu jednego klienta z obciążeniami losowymi 4-KiB i zestawem danych 1-TiB. Wygenerowana kombinacja obciążenia używa za każdym razem innej głębokości operacji we/wy. Aby zwiększyć wydajność pojedynczego obciążenia klienta, nconnect
opcja instalacji została użyta do poprawy równoległości w porównaniu z instalacjami klientów bez nconnect
opcji instalacji.
W przypadku korzystania ze standardowego połączenia TCP, które zapewnia tylko jedną ścieżkę do magazynu, mniejsza łączna liczba operacji jest wysyłana na sekundę niż w przypadku, gdy instalacja może korzystać z nconnect
większej liczby połączeń TCP (takich jak ) na punkt instalacji. W przypadku korzystania z nconnect
programu całkowite opóźnienie operacji jest na ogół niższe. Te testy są również uruchamiane za pomocą randrepeat=0
polecenia , aby celowo uniknąć buforowania. Aby uzyskać więcej informacji na temat tej opcji, zobacz Metodologia testowania.
Wyniki: 4 KiB, losowe, z i bez nconnect
, buforowanie wykluczone
Na poniższych wykresach przedstawiono porównanie równoległe odczytów i zapisów 4-KiB z elementami i bez nconnect
wyróżniania ulepszeń wydajności w przypadku korzystania z nconnect
programu : wyższe ogólne opóźnienia operacji we/wy, mniejsze opóźnienia.
Testy porównawcze o wysokiej przepływności
Poniższe testy porównawcze pokazują wydajność osiągniętą dla usługi Azure NetApp Files z obciążeniem o wysokiej przepływności.
Obciążenia o wysokiej przepływności są bardziej sekwencyjne i często mają duże obciążenie odczytem/zapisem z niskimi metadanymi. Przepływność jest zazwyczaj ważniejsza niż we/wy na platformie OPS. Te obciążenia zwykle wykorzystują większe rozmiary odczytu/zapisu (od 64K do 256K), które generują większe opóźnienia niż mniejsze rozmiary odczytu/zapisu, ponieważ większe ładunki będą naturalnie trwać dłużej.
Przykłady obciążeń o wysokiej przepływności obejmują:
- Repozytoria multimediów
- Obliczenia o wysokiej wydajności
- Sztuczna inteligencja/uczenie maszynowe/LLP
Poniższe testy pokazują test porównawczy o wysokiej przepływności przy użyciu zestawów danych 64-KiB i 256-KiB i 256-KiB. Zestaw obciążeń wygenerowany jednocześnie zmniejsza wartość procentową zestawu i pokazuje, czego można oczekiwać podczas korzystania z różnych współczynników odczytu/zapisu (na przykład 100%:0%, 90%:10%, 80%:20%itd.).
Wyniki: 64 KiB sekwencyjne we/wy, buforowanie uwzględnione
W tym teście porównawczym fiO uruchamiało logikę pętli, która bardziej agresywnie wypełniła pamięć podręczną, więc nieokreślona ilość buforowania wpływała na wyniki. Powoduje to nieco lepszą ogólną liczbę wydajności niż testy uruchamiane bez buforowania.
Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć między około 4500MiB/s czystych sekwencyjnych operacji odczytu 64-KiB i około 1600MiB/s czystych zapisów sekwencyjnych 64-KiB. Mieszanka odczytu i zapisu dla obciążenia została skorygowana o 10% dla każdego przebiegu.
Wyniki: 64 Operacje we/wy sekwencyjne KiB, odczyty i zapis, punkt odniesienia bez buforowania
W tym podstawowym teście porównawczym testowanie pokazuje, że regularny wolumin usługi Azure NetApp Files może obsłużyć między około 3600 zapisami sekwencyjnymi MiB/s 64-KiB i około 2400 zapisów MiB/s czystej sekwencyjnej 64-KiB. Podczas testów mieszana 50/50 wykazała łączną przepływność na równi z czystym obciążeniem odczytu sekwencyjnego.
W odniesieniu do czystego odczytu punkt odniesienia 64-KiB działał nieco lepiej niż 256-KiB odniesienia. Jeśli chodzi o czysty zapis i wszystkie mieszane obciążenia odczytu/zapisu, jednak 256-KiB punkt odniesienia przewyższa 64 KiB, co wskazuje, że większy rozmiar bloku 256 KiB jest bardziej skuteczny w przypadku obciążeń o wysokiej przepływności.
Mieszanka odczytu i zapisu dla obciążenia została skorygowana o 25% dla każdego przebiegu.
Wyniki: 256 Sekwencyjne we/wy KiB bez buforowania
W poniższych dwóch odniesieniach porównawczych fiO zostało użyte do mierzenia liczby sekwencyjnych operacji we/wy (odczytu i zapisu) pojedynczego woluminu regularnego w usłudze Azure NetApp Files. Aby utworzyć plan bazowy, który odzwierciedla rzeczywistą przepustowość, jaką może osiągnąć w pełni nieprzekłodzone obciążenie odczytu, fiO zostało skonfigurowane do uruchamiania z parametrem randrepeat=0
generowania zestawu danych. Każda iteracja testowa została zrównoważona przez odczytanie całkowicie oddzielnego dużego zestawu danych, który nie jest częścią testu porównawczego, aby wyczyścić wszelkie buforowanie, które mogło wystąpić w zestawie danych porównawczych.
Na tym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć między około 3500 zapisami sekwencyjnymi MiB/s 256-KiB i około 2500 zapisów miB/s czystej sekwencyjnej 256-KiB. Podczas testów mieszana 50/50 wykazała łączną przepływność wyższą niż obciążenie odczytu sekwencyjnego.
Równoległe połączenia sieciowe (nconnect
)
Poniższe testy pokazują wysoki test porównawczy operacji we/wy przy użyciu pojedynczego klienta z losowymi obciążeniami 64 KiB i zestawem danych 1-TiB. Wygenerowana kombinacja obciążenia używa za każdym razem innej głębokości operacji we/wy. Aby zwiększyć wydajność pojedynczego obciążenia klienta, nconnect
opcja instalacji została użyta w celu zapewnienia lepszej równoległości w porównaniu z instalacjami klientów, które nie korzystały z nconnect
opcji instalacji. Te testy były uruchamiane tylko z wykluczonym buforowaniem.
Wyniki: 64KiB sekwencyjne operacje we/wy, porównanie pamięci podręcznej przepływności odczytu
Aby zademonstrować, jak buforowanie wpływa na wyniki wydajności, funkcja FIO została użyta w poniższym porównaniu mikro benchmarku w celu zmierzenia ilości sekwencyjnych operacji we/wy (odczytu i zapisu) pojedynczego woluminu regularnego w usłudze Azure NetApp Files. Ten test jest kontrastowany z korzyściami, jakie może zapewnić obciążenie z częściową pamięcią podręczną.
W wyniku bez buforowania testowanie zostało zaprojektowane w celu ograniczenia buforowania, zgodnie z opisem w powyższych testach odniesienia.
W drugim wyniku funkcja FIO była używana względem zwykłych woluminów usługi Azure NetApp Files bez parametru randrepeat=0
i przy użyciu logiki iteracji testowej pętli, która powoli wypełniała pamięć podręczną w czasie. Kombinacja tych czynników wywołała nieokreśloną ilość buforowania, zwiększając ogólną przepływność. Ta konfiguracja spowodowała nieco lepszą ogólną wydajność odczytu niż testy uruchamiane bez buforowania.
Wyniki testów wyświetlane na wykresie wyświetlają równoległe porównanie wydajności odczytu z i bez wpływu buforowania, gdzie buforowanie generowane do około 4500 MiB/sekundy przepływności odczytu, podczas gdy buforowanie nie osiągnęło około ok. 3600 MiB/sekundy.
Porównanie równoległe (z i bez nconnect
)
Na poniższych wykresach przedstawiono porównanie równoległe odczytów sekwencyjnych i zapisów 64-KiB z funkcjami i bez nconnect
wyróżniania ulepszeń wydajności widocznych podczas korzystania nconnect
z : większa ogólna przepływność, mniejsze opóźnienia.