Narzędzie Megascale Stats

Narzędzie Megascale Stats umożliwia analizowanie wydajności komunikacji między wycinkami w przypadku zadań rozciągających się na wiele wycinków TPU, które komunikują się w sieci centrum danych (DCN).

Wszystkie dane wyświetlane w narzędziu Megascale Stats są generowane na podstawie poszczególnych jednostek TPU.

Obsługiwane platformy

Narzędzie Megascale Stats jest obsługiwane tylko na TPU.

Terminologia związana z grupami

Narzędzie wyświetla dane związane z komunikacją między wycinkami TPU, które obejmują te operacje:

• send: przerywa działanie hosta, aby rozpocząć bezpośredni dostęp do pamięci (DMA), i udostępnia hostowi wypełniony bufor, aby rozpocząć przesyłanie danych.
• send-done: sygnalizuje hostowi, że przesyłanie danych zostało zakończone.
• recv: udostępnia pusty bufor, który host może wypełnić przeniesionymi danymi.
• recv-done: informuje hosta, że dane zostały odebrane.

Operacja zbiorcza jest inicjowana przez operację send i kończona przez pasującą operację recv-done. Rzeczywiste wysyłanie danych następuje po zakończeniu operacji wysyłania. Operacja send-done jest wykonywana po wysłaniu danych. Podobnie dane są odbierane po zakończeniu operacji recv. Operacja recv-done jest wykonywana po otrzymaniu danych.

Komponenty interfejsu

Narzędzie wyświetla tabelę z tymi kolumnami, w której każdy wiersz odpowiada profilowanej operacji zbiorczej:

• Nazwa zbiorcza DCN: nadana przez XLA.
• Nazwa operacji odbioru: nazwa operacji TPU recv-done. Ułatwia to wyszukiwanie w przeglądarce śladów odpowiednich zbiorczych operacji TPU.
• Wyślij nazwę operacji: nazwa operacji TPU send.
• Czas bezczynności: zdefiniowany jako niezależny od sieci czas, w którym kolektyw musi przesyłać dane. Jest to miara czasu, w którym grupa może wysyłać i odbierać dane, z wyłączeniem operacji send, send-done, recv i recv-done. Zwiększenie czasu bezczynności zmniejsza szanse na zatrzymanie TPU dla kolektywu. Na przykład w przypadku tej osi czasu:

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>

• Zaobserwowany czas trwania: czas trwania zaobserwowany w przypadku każdej kolekcji. Jest on obliczany jako przedział czasu od rozpoczęcia operacji send do zakończenia odpowiedniej operacji recv-done, w tym czas spędzony na wysyłaniu i odbieraniu danych. Na przykład w przypadku takiego harmonogramu:

Observed duration is calculated as:

Observed duration = t<sub>send</sub> + t<sub>1</sub> + t<sub>send-done</sub> + t<sub>2</sub> + t<sub>recv</sub> + t<sub>3</sub> + t<sub>recv-done</sub>

• Czas trwania przestoju: czas, przez jaki kolektyw wstrzymuje działanie TPU. Jest to łączny czas, jaki kolektyw spędza na operacjach send, send-done, recv i recv-done, z wyłączeniem czasu poświęconego na przesyłanie danych. Na przykład w przypadku takiego harmonogramu:

Stall duration is calculated in this example as:

Stall duration = t<sub>send</sub> + t<sub>send-done</sub> + t<sub>recv</sub> + t<sub>recv-done</sub>

• Wystąpienia: łączna liczba rozpoczętych i zakończonych działań zbiorowych w okresie trwania profilu. Aby operacja send i odpowiadająca jej operacja recv-done zostały uwzględnione w tych danych, muszą wystąpić w okresie trwania profilu.
• Zagregowany łączny czas wstrzymania: łączny czas, przez jaki grupa wstrzymuje działanie TPU w okresie profilowania. Łączne opóźnienie agregacji jest obliczane w ten sposób:
  • Zagregowany łączny czas wstrzymania = czas wstrzymania * liczba wystąpień
• Rozmiar przesyłanych danych: ilość danych przesyłanych przez sieć na potrzeby kolektywu, obliczona na podstawie kształtu operacji XLA.
• Wymagana przepustowość: przepustowość wymagana do przesłania danych w ramach podanego marginesu. Na podstawie tych danych możesz sprawdzić liczbę kolektywów rywalizujących o przepustowość sieci w czasie trwania profilu. Wymagana przepustowość jest obliczana w ten sposób:
  • Wymagana przepustowość = rozmiar przesyłanych danych / czas oczekiwania

Analizowanie danych z narzędzia Megascale Stats Tool

Aby przeanalizować dane prezentowane w narzędziu:

1. Posortuj tabelę według kolumny Aggregated Total Stall w kolejności malejącej.
2. Określ zbiorczą nazwę DCN z najwyższą wartością Aggregated Total Stall. Znacznie wyższa wartość w porównaniu z innymi może wskazywać na wąskie gardło.
3. Pomnóż Required Bandwidth DCN przez liczbę rdzeni (np. 8 na hosta TPU v4). Jeśli ta wartość jest większa niż maksymalna przepustowość sieci TPU, może to oznaczać przeciążenie sieci. Spróbuj zmienić mechanizm dzielenia, aby zmniejszyć wymaganą przepustowość.
4. Wygeneruj zrzut HLO, aby sprawdzić, czy nie ma problemów z kompilatorem. Rozszerzanie operacji send i recv-done może umożliwić planowanie większej liczby nakładających się operacji HLO i skrócić czas przestoju TPU.
5. Sprawdź czas trwania operacji recv-done w narzędziu Trace Viewer dla kolekcji z największym łącznym czasem oczekiwania. Długi czas przesyłania może wskazywać wąskie gardło przepustowości, ponieważ operacje recv-done są zwykle blokowane w sieci.
6. Jeśli czas trwania operacji recv-done nie jest nadmiernie wysoki w porównaniu z czasem bezczynności, może to oznaczać problem ze sprzętem.