Tool „Megascale Stats“

Mit dem Tool „Megascale Stats“ können Sie die Leistung der Kommunikation zwischen Slices von Arbeitslasten analysieren, die sich über mehrere TPU-Slices erstrecken und über das Data Center Network (DCN) kommunizieren.

Alle im Tool „Megascale Stats“ angezeigten Messwerte werden pro TPU generiert.

Unterstützte Plattformen

Das Tool „Megascale Stats“ wird nur auf TPUs unterstützt.

Das Tool zeigt Messwerte zur Kommunikation zwischen TPU-Slices an, die die folgenden Vorgänge umfassen:

  • send: Unterbricht den Host und startet einen direkten Arbeitsspeicherzugriff (Direct Memory Access, DMA); stellt dem Host einen gefüllten Zwischenspeicher bereit und startet die Datenübertragung.
  • send-done: Signalisiert dem Host, dass die Datenübertragung abgeschlossen ist.
  • recv: Stellt dem Host einen leeren Zwischenspeicher bereit, den er mit den übertragenen Daten füllen kann.
  • recv-done: Signalisiert dem Host, dass die Daten empfangen wurden.

Eine Sammlung wird durch einen send-Vorgang initiiert und durch den entsprechenden recv-done-Vorgang abgeschlossen. Das eigentliche Senden der Daten wird nach Abschluss des Sendevorgangs ausgeführt. Nachdem die Daten gesendet wurden, wird der Vorgang send-done ausgeführt. Analog dazu wird der Empfang der Daten erst nach Abschluss des Vorgangs recv ausgeführt. Der Vorgang recv-done wird ausgeführt, nachdem die Daten empfangen wurden.

Komponenten der Benutzeroberfläche

Im Tool wird eine Tabelle mit den folgenden Spalten angezeigt, wobei jede Zeile einen profilierten kollektiven Vorgang darstellt:

  • DCN-Sammlungsname: Wird von XLA zugewiesen.
  • Recv-Vorgangsname: Der Name des TPU-Vorgangs recv-done. So können Sie ganz einfach im Trace Viewer nach den entsprechenden kollektiven TPU-Operationen suchen.
  • Send op name: Der Name des TPU-Vorgangs send.
  • Pufferzeit: Die netzwerkunabhängige Zeit, die die Sammlung für die Übertragung der Daten hat. Dies ist ein Maß für die Zeit, die der Kollektivgruppe zum Senden und Empfangen von Daten zur Verfügung steht, mit Ausnahme der Vorgänge send, send-done, recv oder recv-done. Ein längerer Zeitpuffer verringert die Wahrscheinlichkeit, dass die TPU für eine Sammlung blockiert wird. Beispiel für eine Zeitachse:

Zeitachse mit Pufferzeit

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>
  • Beobachteter Zeitraum: Der für jedes Kollektiv beobachtete Zeitraum. Sie wird als das Intervall zwischen dem Beginn des send-Vorgangs und dem Ende des entsprechenden recv-done-Vorgangs berechnet, einschließlich der Zeit, die für das Senden und Empfangen von Daten aufgewendet wird. Beispiel für eine Zeitachse:

Zeitachse mit der beobachteten Dauer

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>
  • Blockierungsdauer: Die Zeit, die die TPU durch die Sammlung blockiert wird. Dies ist die Gesamtdauer, die für die Vorgänge send, send-done, recv und recv-done benötigt wird, ohne die Zeit für die Datenübertragung. Beispiel für eine Zeitachse:

Zeitachse mit Verzögerungsdauer

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>
  • Vorkommen: Die Gesamtzahl der Male, die eine Sammlung während einer Profildauer gestartet und beendet wird. Der send-Vorgang und der entsprechende recv-done-Vorgang müssen innerhalb einer Profildauer erfolgen, damit sie für diesen Messwert berücksichtigt werden.
  • Aggregierte Gesamtverzögerung: Die Zeit innerhalb einer Profildauer, die eine TPU insgesamt durch eine Sammlung blockiert wird. Die aggregierte Gesamtverzögerung wird so berechnet:
    • Aggregierte Gesamtverzögerung = Verzögerungsdauer × Vorkommen
  • Größe der übertragenen Daten: Die Datenmenge, die für die Sammlung über das Netzwerk übertragen wird. Sie wird basierend auf der Form des XLA-Vorgangs berechnet.
  • Erforderliche Bandbreite: Die Bandbreite, die für die Übertragung der Daten innerhalb des bereitgestellten Zeitpuffers erforderlich ist. Anhand dieses Messwerts sehen Sie, wie viele Sammlungen während der Profildauer um Netzwerkbandbreite konkurrieren. Die erforderliche Bandbreite wird folgendermaßen berechnet:
    • Erforderliche Bandbreite = übertragene Datenmenge / Zeitpuffer

Daten des Tools „Megascale Stats“ analysieren

So analysieren Sie die im Tool präsentierten Daten:

  1. Sortieren Sie die Tabelle in absteigender Reihenfolge nach Aggregated Total Stall.
  2. Bestimmen Sie den DCN-Sammlungsnamen mit dem höchsten Aggregated Total Stall. Ein im Vergleich zu anderen deutlich hoher Wert kann auf einen Engpass hinweisen.
  3. Multiplizieren Sie die Required Bandwidth der DCN-Sammlung mit der Anzahl der Kerne (z.B. 8 pro v4-TPU-Host). Wenn dieser Wert größer als die maximale Netzwerkbandbreite der TPU ist, kann dies auf eine Netzwerküberlastung hinweisen. Sie können versuchen, den Fragmentierungsmechanismus zu ändern, um die erforderliche Bandbreite zu verringern.
  4. Generieren Sie einen HLO-Dump, um nach Compilerproblemen zu suchen. Durch die Verteilung von send- und recv-done-Vorgängen können mehr sich überschneidende HLO-Vorgänge geplant und die TPU-Verzögerungszeit verkürzt werden.
  5. Überprüfen Sie im Trace Viewer die Dauer der recv-done-Vorgänge für die Sammlung mit der längsten aggregierten Gesamtverzögerungszeit. Eine lange Übertragungsdauer könnte auf einen Bandbreitenengpass hindeuten, da recv-done-Vorgänge normalerweise im Netzwerk blockiert werden.
  6. Wenn die Dauer der recv-done-Vorgänge im Vergleich zum Zeitpuffer nicht zu lang ist, könnte ein Hardwareproblem vorliegen.