Udostępnij za pośrednictwem

Wskazówki dotyczące dostrajania wydajności systemu Storm w usłudze HDInsight i Azure Data Lake Storage Gen1

  • Artykuł

Zapoznaj się z czynnikami, które należy wziąć pod uwagę podczas dostosowywania wydajności topologii usługi Azure Storm. Na przykład ważne jest, aby zrozumieć cechy pracy wykonanej przez spouts i śruby (niezależnie od tego, czy praca jest intensywnie obciążana operacjami we/wy lub pamięci). W tym artykule opisano szereg wytycznych dotyczących dostrajania wydajności, w tym rozwiązywanie typowych problemów.

Wymagania wstępne

Dostrajanie równoległości topologii

Możesz zwiększyć wydajność, zwiększając współbieżność operacji we/wy do i z Data Lake Storage Gen1. Topologia systemu Storm zawiera zestaw konfiguracji, które określają równoległość:

  • Liczba procesów roboczych (procesy robocze są równomiernie dystrybuowane na maszynach wirtualnych).
  • Liczba wystąpień funkcji wykonawczej spout.
  • Liczba wystąpień funkcji wykonawczej bolt.
  • Liczba zadań spout.
  • Liczba zadań bolt.

Na przykład w klastrze z 4 maszynami wirtualnymi i 4 procesami roboczymi, 32 funkcjami wykonawczymi spout i 32 zadaniami spout oraz 256 wykonawcami śrub i 512 zadaniami śrubowymi należy wziąć pod uwagę następujące kwestie:

Każdy nadzorca, który jest węzłem procesu roboczego, ma jeden proces roboczy maszyny wirtualnej Java (JVM). Ten proces JVM zarządza 4 wątkami spout i 64 wątkami śrubowymi. W każdym wątku zadania są uruchamiane sekwencyjnie. W przypadku poprzedniej konfiguracji każdy wątek spout ma jedno zadanie, a każdy wątek bolt ma dwa zadania.

W systemie Storm znajdują się różne składniki i sposób ich wpływu na poziom równoległości:

  • Węzeł główny (nazywany Nimbus w systemie Storm) służy do przesyłania zadań i zarządzania nimi. Te węzły nie mają wpływu na stopień równoległości.
  • Węzły nadzorcy. W usłudze HDInsight odpowiada to maszynie wirtualnej platformy Azure węzła roboczego.
  • Zadania robocze to procesy systemu Storm uruchomione na maszynach wirtualnych. Każde zadanie procesu roboczego odpowiada wystąpieniu JVM. System Storm dystrybuuje liczbę procesów roboczych określonych dla węzłów procesu roboczego tak równomiernie, jak to możliwe.
  • Wystąpienia funkcji wykonawczej spout i bolt. Każde wystąpienie funkcji wykonawczej odpowiada wątkowi uruchomionemu w ramach procesów roboczych (JVM).
  • Zadania systemu Storm. Są to zadania logiczne uruchamiane przez każdy z tych wątków. Nie zmienia to poziomu równoległości, dlatego należy ocenić, czy potrzebujesz wielu zadań na funkcję wykonawcza, czy nie.

Uzyskiwanie najlepszej wydajności z Data Lake Storage Gen1

Podczas pracy z Data Lake Storage Gen1 uzyskasz najlepszą wydajność, jeśli wykonasz następujące czynności:

  • Łączenie małych dołączań do większych rozmiarów (najlepiej 4 MB).
  • Wykonaj dowolną liczbę współbieżnych żądań. Ponieważ każdy wątek śruby blokuje odczyty, chcesz mieć gdzieś w zakresie 8–12 wątków na rdzeń. Dzięki temu karta sieciowa i procesor CPU są dobrze wykorzystywane. Większa maszyna wirtualna umożliwia wykonywanie większej liczby współbieżnych żądań.

Przykładowa topologia

Załóżmy, że masz osiem klastrów węzłów roboczych z maszyną wirtualną platformy Azure D13v2. Ta maszyna wirtualna ma osiem rdzeni, więc wśród ośmiu węzłów roboczych masz 64 łączne rdzenie.

Załóżmy, że robimy osiem wątków bolt na rdzeń. Biorąc pod uwagę 64 rdzenie, oznacza to, że chcemy mieć 512 całkowite wystąpienia funkcji wykonawczej bolt (czyli wątki). W tym przypadku załóżmy, że zaczynamy od jednej maszyny wirtualnej JVM na maszynę wirtualną i używamy głównie współbieżności wątku w maszynie JVM, aby osiągnąć współbieżność. Oznacza to, że potrzebujemy ośmiu zadań roboczych (jeden na maszynę wirtualną platformy Azure) i 512 funkcji wykonawczych śrub. Biorąc pod uwagę tę konfigurację, system Storm próbuje równomiernie dystrybuować procesy robocze między węzłami roboczymi (nazywanymi również węzłami nadzorcy), dając każdemu węzłowi roboczemu jedną maszynę wirtualną JVM. Teraz w ramach nadzorców system Storm próbuje równomiernie dystrybuować funkcje wykonawcze między przełożonymi, dając każdemu nadzorcy (czyli maszynie wirtualnej JVM) osiem wątków.

Dostrajanie dodatkowych parametrów

Po dokonaniu podstawowej topologii możesz rozważyć, czy chcesz dostosować dowolny z parametrów:

  • Liczba maszyn wirtualnych JVM na węzeł roboczy. Jeśli masz dużą strukturę danych (na przykład tabelę odnośników), którą hostujesz w pamięci, każda maszyna JVM wymaga oddzielnej kopii. Alternatywnie możesz użyć struktury danych w wielu wątkach, jeśli masz mniej maszyn wirtualnych. W przypadku operacji we/wy śruby liczba maszyn wirtualnych JVM nie ma tak dużej różnicy, jak liczba wątków dodanych przez te maszyny JVM. Dla uproszczenia warto mieć jedną maszynę wirtualną JVM dla każdego procesu roboczego. Jednak w zależności od działania śruby lub wymaganego przetwarzania aplikacji może być konieczne zmianę tej liczby.
  • Liczba funkcji wykonawczych spout. Ponieważ w poprzednim przykładzie użyto śrub do zapisywania w Data Lake Storage Gen1, liczba spouts nie jest bezpośrednio istotna dla wydajności śruby. Jednak w zależności od ilości przetwarzania lub we/wy dzieje się w spout, dobrym pomysłem jest dostrojenie spouts w celu uzyskania najlepszej wydajności. Upewnij się, że masz wystarczająco dużo spouts, aby móc utrzymać śruby zajęte. Współczynniki wyjściowe spouts powinny być zgodne z przepływnością śrub. Rzeczywista konfiguracja zależy od spout.
  • Liczba zadań. Każda śruba działa jako pojedynczy wątek. Dodatkowe zadania na śrubę nie zapewniają dodatkowej współbieżności. Jedyną korzyścią jest to, że proces potwierdzania krotki zajmuje dużą część czasu wykonywania śruby. Dobrym pomysłem jest zgrupowanie wielu krotki do większego dołączania przed wysłaniem potwierdzenia ze śruby. W większości przypadków wiele zadań nie zapewnia dodatkowej korzyści.
  • Grupowanie lokalne lub shuffle. Po włączeniu tego ustawienia krotki są wysyłane do elementów bolt w ramach tego samego procesu roboczego. Zmniejsza to komunikację między procesami i wywołania sieciowe. Jest to zalecane w przypadku większości topologii.

Ten podstawowy scenariusz jest dobrym punktem wyjścia. Przetestuj przy użyciu własnych danych, aby dostosować poprzednie parametry, aby osiągnąć optymalną wydajność.

Dostrajanie spout

Możesz zmodyfikować następujące ustawienia, aby dostosować spout.

  • Limit czasu krotki: topology.message.timeout.secs. To ustawienie określa czas potrzebny na ukończenie komunikatu i odebranie potwierdzenia, zanim zostanie uznane za zakończone niepowodzeniem.

  • Maksymalna ilość pamięci na proces roboczy: worker.childopts. To ustawienie umożliwia określenie dodatkowych parametrów wiersza polecenia dla procesów roboczych języka Java. Najczęściej używane ustawienie to XmX, które określa maksymalną ilość pamięci przydzielonej do sterty JVM.

  • Maksymalna liczba oczekujących spout: topology.max.spout.pending. To ustawienie określa liczbę krotek, które mogą być w locie (nie jest jeszcze potwierdzone we wszystkich węzłach w topologii) na wątek spout w dowolnym momencie.

    Dobrym obliczeniem jest oszacowanie rozmiaru każdej krotki. Następnie dowiedzieć się, ile pamięci ma jeden wątek spout. Łączna ilość pamięci przydzielonej do wątku, podzielona przez tę wartość, powinna dać górną granicę maksymalnego parametru oczekującego na spout.

Dostrajanie śruby

Podczas zapisywania w Data Lake Storage Gen1 ustaw zasady synchronizacji rozmiaru (bufor po stronie klienta) na 4 MB. Opróżnianie lub hsync() jest wykonywane tylko wtedy, gdy rozmiar buforu jest na tej wartości. Sterownik Data Lake Storage Gen1 na maszynie wirtualnej procesu roboczego automatycznie wykonuje buforowanie, chyba że jawnie wykonasz funkcję hsync().

Domyślna Data Lake Storage Gen1 Bolt systemu Storm ma parametr zasad synchronizacji rozmiaru (fileBufferSize), który może służyć do dostrajania tego parametru.

W topologiach intensywnie korzystających z operacji we/wy warto zapisać każdy wątek bolt we własnym pliku i ustawić zasady rotacji plików (fileRotationSize). Gdy plik osiągnie określony rozmiar, strumień zostanie automatycznie opróżniony i zostanie zapisany nowy plik. Zalecany rozmiar pliku dla rotacji to 1 GB.

Obsługa danych krotki

W storm, spout trzyma się krotki, dopóki nie zostanie jawnie potwierdzony przez śrubę. Jeśli krotka została odczytowana przez śrubę, ale nie została jeszcze potwierdzona, spout może nie utrwalone w Data Lake Storage Gen1 zapleczu. Po potwierdzeniu krotki spout można zagwarantować trwałość przez śrubę, a następnie usunąć dane źródłowe z dowolnego źródła, z których jest odczytywany.

Aby uzyskać najlepszą wydajność na Data Lake Storage Gen1, bufor śruby 4 MB danych krotki. Następnie zapisz na zapleczu Data Lake Storage Gen1 jako jeden zapis o 4 MB. Po pomyślnym zapisaniu danych w magazynie (przez wywołanie metody hflush()) śruba może potwierdzić dane z powrotem do spout. To właśnie robi przykładowy element bolt podany tutaj. Dopuszczalne jest również utrzymywanie większej liczby krotki przed wywołaniem hflush() i krotki potwierdzone. Zwiększa to jednak liczbę krotki w locie, które muszą być przechowywane przez spout, a zatem zwiększa ilość pamięci wymaganej na maszynę wirtualną JVM.

Uwaga

Aplikacje mogą częściej potwierdzać krotki (w rozmiarach danych mniejszych niż 4 MB) z innych powodów innych niż wydajność. Może to jednak mieć wpływ na przepływność we/wy do zaplecza magazynu. Starannie odważyć ten kompromis względem wydajności we/wy śruby.

Jeśli szybkość przychodzących krotki nie jest wysoka, więc wypełnienie buforu o rozmiarze 4 MB trwa długo, rozważ ograniczenie tego przez:

  • Zmniejszenie liczby śrub, więc jest mniej buforów do wypełnienia.
  • Zasady oparte na czasie lub liczbach, w których hflush() jest wyzwalane co x opróżniania lub co y milisekund, a krotki skumulowane do tej pory są potwierdzane z powrotem.

Przepływność w tym przypadku jest niższa, ale przy powolnym tempie zdarzeń maksymalna przepływność nie jest mimo to największym celem. Te środki zaradcze pomagają skrócić całkowity czas potrzebny na przepływ krotki do sklepu. Może to mieć znaczenie, jeśli chcesz użyć potoku w czasie rzeczywistym nawet z niską szybkością zdarzeń. Należy również pamiętać, że jeśli szybkość krotek przychodzących jest niska, należy dostosować parametr topology.message.timeout_secs, aby krotki nie przekroczyły limitu czasu podczas ich buforowania lub przetwarzania.

Monitorowanie topologii w systemie Storm

Gdy topologia jest uruchomiona, możesz ją monitorować w interfejsie użytkownika systemu Storm. Poniżej przedstawiono główne parametry, na które należy zwrócić uwagę:

  • Łączne opóźnienie wykonywania procesu. Jest to średni czas emitowania jednej krotki przez spout, przetwarzany przez śrubę i potwierdzony.

  • Całkowite opóźnienie procesu śruby. Jest to średni czas spędzony przez krotkę na śrubie, dopóki nie otrzyma potwierdzenia.

  • Łączne opóźnienie wykonania śruby. Jest to średni czas spędzony przez element bolt w metodzie execute.

  • Liczba błędów. Odnosi się to do liczby krotki, których nie można w pełni przetworzyć, zanim upłynął limit czasu.

  • Pojemność. Jest to miara tego, jak zajęty jest system. Jeśli ta liczba wynosi 1, śruby działają tak szybko, jak to możliwe. Jeśli wartość jest mniejsza niż 1, zwiększ równoległość. Jeśli wartość jest większa niż 1, zmniejsz równoległość.

Rozwiązywanie typowych problemów

Oto kilka typowych scenariuszy rozwiązywania problemów.

  • Wiele krotki przekracza limit czasu. Przyjrzyj się każdemu węzłowi w topologii, aby określić, gdzie znajduje się wąskie gardło. Najczęstszą przyczyną jest to, że śruby nie są w stanie nadążyć za spouts. Prowadzi to do zatkania buforów wewnętrznych podczas oczekiwania na przetworzenie. Rozważ zwiększenie wartości limitu czasu lub zmniejszenie maksymalnej liczby oczekujących spout.

  • Istnieje duże całkowite opóźnienie wykonywania procesu, ale małe opóźnienie procesu śruby. W tym przypadku istnieje możliwość, że krotki nie są potwierdzane wystarczająco szybko. Sprawdź, czy istnieje wystarczająca liczba potwierdzeń. Inną możliwością jest to, że czekają w kolejce zbyt długo, zanim śruby zaczną je przetwarzać. Zmniejsz maksymalne oczekiwanie na spout.

  • Występuje duże opóźnienie wykonywania śrub. Oznacza to, że metoda execute() elementu bolt trwa zbyt długo. Zoptymalizuj kod lub przyjrzyj się rozmiarom zapisu i zachowaniu opróżniania.

ograniczanie przepustowości Data Lake Storage Gen1

Jeśli osiągniesz limity przepustowości zapewniane przez Data Lake Storage Gen1, mogą wystąpić błędy zadań. Sprawdź dzienniki zadań pod kątem błędów ograniczania przepustowości. Równoległość można zmniejszyć, zwiększając rozmiar kontenera.

Aby sprawdzić, czy jest ograniczana, włącz rejestrowanie debugowania po stronie klienta:

  1. W aplikacji Ambari>Storm>Config>Advanced storm-worker-log4j zmień <poziom główny="info"> na <poziom główny="debug".> Uruchom ponownie wszystkie węzły/usługę, aby konfiguracja weszła w życie.
  2. Monitoruj dzienniki topologii systemu Storm w węzłach procesu roboczego (w obszarze /var/log/storm/worker-artifacts/<TopologyName>/<port>/worker.log) pod kątem wyjątków ograniczania przepustowości Data Lake Storage Gen1.

Następne kroki

Dodatkowe dostrajanie wydajności systemu Storm można odwoływać się w tym blogu.

Aby zapoznać się z dodatkowym przykładem do uruchomienia, zobacz ten w witrynie GitHub.