Debugowanie wąskich gardeł wydajności
Jeśli korzystasz z aplikacji obliczeń o wysokiej wydajności (HPC) na dużej liczbie maszyn wirtualnych (więcej niż 16), najlepiej rozpocząć uruchamianie mniejszego problemu na mniejszej liczbie maszyn wirtualnych. Ten test sprawdza, czy aplikacja HPC działa zgodnie z oczekiwaniami.
Nie zakładaj, że tylko dlatego, że uruchamiasz aplikację równoległą HPC, jej czas ściany (upłynął w czasie rzeczywistym) w miarę jego uruchamiania na większej ilości maszyn wirtualnych (z bardziej równoległymi procesami). W rzeczywistości wiele ściśle powiązanych aplikacji HPC może mieć dłuższy czas, gdy próbujesz uruchomić je na innych maszynach wirtualnych.
Dłuższy czas ściany może wystąpić z kilku powodów. Na przykład:
Algorytm równoległy może być nieefektywny.
Rozmiar problemu, czyli rozmiar modelu lub liczba stopni swobody (NDOF), nie jest wystarczająco duży. W miarę uruchamiania aplikacji w bardziej równoległych procesach ilość obliczeń w każdym procesie jest zbyt mała. W rezultacie czas komunikacji między procesami równoległymi dominuje w całkowitym czasie ściany. Wzrost czasu komunikacji zwiększa całkowity czas ściany.
Ważne jest, aby wiedzieć, jak dobrze aplikacja HPC skaluje rozmiar problemu, w którym cię interesuje. Następnie można określić, jaka wydajność równoległa jest akceptowalna z punktu widzenia wydajności i kosztów.
Następująca formuła przyspieszania równoległego mierzy, jak dobrze wydajność aplikacji równoległej poprawia się w miarę dodawania kolejnych procesów równoległych:
$${\text{Szybkość równoległa}} = {\dfrac{\text{czas ściany (1 proces)}}{\text{czas ściany (n procesów)}}}$$
Poniższa formuła wydajności równoległej ilustruje, jak efektywnie używasz zasobów obliczeniowych podczas dodawania większej liczby procesów w celu zwiększenia wydajności aplikacji równoległych:
$${\text{Wydajność równoległa}} = {\dfrac{\text{Szybkość równoległa}}{\text{N procesów}}}$$
Jeśli nie masz pewności co do wydajności skalowania równoległego dla ściśle powiązanej aplikacji HPC, uruchom badanie skalowania. Innymi słowy, uruchom aplikację na 1, 2, 4, 8, 16 itd. w procesach równoległych. Oblicz równoległą szybkość i wydajność równoległą, a następnie zdecyduj na podstawie tych wyników, ile procesów równoległych chcesz użyć.
Przed uruchomieniem zadań rozważ wyłączenie wszelkich niepotrzebnych usług, które mogą mieć wpływ na skalowanie równoległe, takie jak agent systemu Linux platformy Azure. Następnie możesz ponownie włączyć usługi po zakończeniu zadań. To zalecenie jest szczególnie prawdziwe, jeśli używasz wszystkich dostępnych rdzeni i skalowania do dużej liczby maszyn wirtualnych.
Aby zatrzymać agenta systemu Linux platformy Azure, użyj następującego polecenia:
sudo system stop waagent.service
Testy wydajności
Poniższe informacje zawierają kilka podstawowych testów, które pomogą zidentyfikować potencjalne problemy z wydajnością.
Sprawdź, czy na każdej maszynie wirtualnej jest uruchomiona prawidłowa liczba procesów i wątków
Łatwym sposobem określenia, czy używasz prawidłowej liczby procesów i wątków na każdej maszynie wirtualnej, jest uzyskanie średniej obciążenia systemu na każdej maszynie wirtualnej za pomocą narzędzia, takiego jak czas pracy. Liczba powinna być w przybliżeniu równa całkowitej oczekiwanej liczbie procesów i wątków na każdej maszynie wirtualnej. Jeśli zarejestrowana średnia obciążenia jest niższa lub wyższa niż oczekiwana całkowita liczba procesów i wątków, wskazuje problem, który należy naprawić.
Należy dokładnie sprawdzić argumenty interfejsu MPI (Message Passing Interface) i określić liczbę wątków równoległych. Na przykład sprawdź argumenty wiersza polecenia aplikacji lub sprawdź wartości zmiennych środowiskowych, takich jak OMP_NUM_THREADS.
Sprawdź, czy procesy i wątki są równomiernie dystrybuowane we wszystkich domenach węzłów NUMA
Jeśli używasz narzędzia górnego lub htop, możesz wybrać widok domeny węzła Nonuniform memory access (NUMA), określając 2 jako parametr wiersza polecenia. (Na przykład w HB120_v2 powinny być widoczne 30 domen węzłów NUMA przy użyciu tego widoku).
Procent wykorzystania użytkowników powinien być równomiernie rozłożony między wszystkie domeny NUMA. Jeśli tak nie jest, sprawdź argumenty wiersza polecenia MPI i zmienne środowiskowe.
Na poniższej ilustracji przedstawiono dane wyjściowe najlepszego narzędzia systemu Linux w widoku NUMA. W tym przypadku każda architektura NUMA jest używana w 50 procentach.
Sprawdzanie stanu uruchamiania procesów i wątków
Aby sprawdzić stan uruchamiania procesów i wątków, należy użyć górnej części. Najlepiej, aby wszystkie procesy i wątki działały w stanie uruchomionym (R).
Jeśli niektóre lub wszystkie procesy i wątki znajdują się w stanie uśpienia nieinterrupcyjnego (D) lub uśpienia (S), zbadaj sytuację, aby zrozumieć przyczynę. W zależności od sposobu projektowania algorytmu aplikacji może to być normalne i oczekiwane zachowanie procesów i wątków w stanie uśpienia. Może to jednak wskazywać na ograniczenie zasobów, takie jak niewystarczająca wydajność we/wy ze względu na używane rozwiązanie magazynu.
Poniższa formuła ilustruje, jak wydajnie działa aplikacja równoległa, jeśli oczekuje na niektóre zasoby systemowe (takie jak operacje we/wy) i w jakim zakresie:
$${\text{Czas oczekiwania aplikacji}} = {\text{czas ściany}} - \left( {\dfrac{\text{Całkowity czas procesora DLA wszystkich procesów równoległych}}{\text{Liczba procesów równoległych}}} \right)$$
Sprawdzanie, czy aplikacja jest powiązana z we/wy
Procesy i wątki spędzają znaczną ilość czasu w stanie uśpienia (D) lub uśpienia (S) może być wskaźnikiem, że istnieje wąskie gardło we/wy, które należy zbadać. Niektóre aplikacje HPC zapewniają profilowanie wydajności w ramach danych wyjściowych. Te profile pokazują procent czasu spędzonego na wykonywaniu operacji we/wy i operacji we/wy odczytu/zapisu, co może również wskazywać wąskie gardło we/wy.
Jeśli nie masz pewności, gdzie odbywa się we/wy, możesz użyć narzędzi takich jak iostat , aby ci pomóc. Aby sprawdzić, czy masz problem z we/wy, zmień rozwiązanie magazynu na coś, co wiesz, jest szybsze niż to, czego używasz. Następnie ponownie uruchom aplikację HPC. Można na przykład użyć szybkiego lokalnego dysku SSD NVMe lub pamięci RAM.
Po wprowadzeniu tej zmiany zadaj sobie następujące pytania: Czy widzisz jakiekolwiek ulepszenia czasu we/wy? Czy ogólny czas ściany poprawił się? Jeśli tak, przez ile?
Sprawdzanie, czy aplikacja jest powiązana z siecią
Określ wartość procentową całkowitego czasu ściany, który aplikacja spędza na komunikacji procesowej (zazwyczaj jest to komunikacja MPI).
Jeśli aplikacja jest powiązana z siecią, sprawdź, czy używasz sieci InfiniBand podczas uruchamiania aplikacji HPC. Jeśli dostępna jest hybrydowa wersja równoległa, określ, czy skraca to czas komunikacji sieciowej.
Jeśli masz dostęp do kodu źródłowego, sprawdź, czy istnieją bardziej wydajne sposoby implementowania komunikacji. Na przykład użyj operacji zbiorczych zamiast punkt-punkt lub spróbuj użyć komunikacji asynchronicznej zamiast synchronicznej.