Fehlerbehebung bei Pathways on Cloud

Vorschau

Dieses Produkt oder Feature unterliegt den "Nutzungsbedingungen für Pre-GA-Angebote" im Abschnitt "Allgemeine Dienstbedingungen" der Dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Hinweis

• XPK installiert
• Kubernetes-Tools installiert
• gcloud-CLI installiert
• TPU API aktiviert
• Google Kubernetes Engine API aktiviert
• Google Kubernetes Engine-Cluster erstellt

In diesem Dokument wird beschrieben, wie Sie Probleme mit Ihren Pathways-Arbeitslasten beheben.

Logs ansehen

Verwenden Sie im Cloud Logging Logs Explorer, verwenden Sie die folgende Abfrage, die an Ihr Projekt, Ihre Region, Ihren Cluster und Ihre Arbeitslast angepasst ist.

resource.type="k8s_container"
resource.labels.project_id="PROJECT"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER"
resource.labels.namespace_name="default"
resource.labels.pod_name:"WORKLOAD_NAME"

Ersetzen Sie Folgendes:

• PROJECT : Ihre Google Cloud Projekt-ID
• LOCATION: die Region oder Zone, in der Sie Ihren GKE-Cluster erstellt haben
• CLUSTER : der Name Ihres GKE-Cluster
• WORKLOAD_NAME : der Name Ihrer Arbeitslast bei Verwendung von XPK oder der JobSet-Name bei Verwendung von kubectl

Diese Abfrage entspricht mehreren Pathways-Kubernetes-Containern mit Namen wie pathways-rm, pathways-proxy und pathways-worker. Sie können eingrenzen , welcher Container ein Problem verursacht, indem Sie einen Filter für den Containernamen hinzufügen, z. B. resource.labels.container_name:"<container_name>"

Monitoring

Statusmonitoring

Sie können den Status verschiedener Pathways-Komponenten überwachen, indem Sie in den Containerlogs nach Einträgen suchen, z. B.:

pathways-proxy ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn der folgende Log geschrieben wird:

kubectl logs ${HEAD_POD_NAME} --container pathways-proxy
...
I1101 04:51:41.967764       1 proxy_server.cc:125] IFRT proxy server started with status OK

pathways-rm ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn der folgende Log geschrieben wird:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Wenn Sie prüfen möchten, ob alle im Pathways Resource Manager registrierten TPUs bereit sind, suchen Sie in den pathways-rm Containerlogs nach ***<num slices>/<num slices> Pathways Slices Now Ready ***:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:52:41.967764       1 multi_job_allocator.cc:1063] *** 2/2 Pathways Slices Now Ready ***

Der Pathways-Client kann Verbindungen zum IFRT-Proxyserver herstellen, solange der Proxyserver bereit ist, auch wenn nicht alle Slices bereit sind. Ihr Job funktioniert mit virtuellen Slices, bis der Slice bereit ist. Mit virtuellen Slices kann Ihr Code ausgeführt werden, wenn TPUs nicht verfügbar sind.

pathways-worker ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn der folgende Log geschrieben wird:

kubectl logs $WORKER_POD_NAME --container pathways-worker
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Messwerterfassung

Pathways kann zur Fehlerbehebung Systemmesswerte auf niedriger Ebene in Cloud Monitoring schreiben. Die Messwerte enthalten:

• DCN-Übertragungslatenz
• Gesamtlatenz
• Host-zu-Gerät-Übertragungslatenz
• Gerät-zu-Host-Übertragungslatenz

Sie finden die Messwerte im Cloud Monitoring-Dashboard des {gcp_name}-Projekts, in dem der GKE-Cluster ausgeführt wird.

So überwachen Sie diese Messwerte im Metrics Explorer:

1. Rufen Sie den Metrics Explorer auf.
2. Filtern Sie nach dem Namen des Messwerts im Feld Messwert auswählen.
3. Filtern Sie nach dem Namen der Arbeitslast und dem Zeitraum, indem Sie Filter hinzufügen auswählen und nach pod_name filtern.
4. Wählen Sie einen geeigneten Aggregationstyp basierend auf dem Messwert und den Arbeitslasten aus, die Sie überwachen.

DCN-Übertragungslatenz

Dies ist ein Megascale XLA-Messwert (MXLA), der die kumulative Verteilung der Netzwerkübertragungslatenzen für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage zur Datenübertragung über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert überwachen möchten, filtern Sie nach dem Messwertnamen dcn_transfer_latencies.

Gesamtlatenz

Dies ist ein MXLA-Messwert, der die kumulative Verteilung der Gesamt-End-to-End-Latenz für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage für ein Collective gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert überwachen möchten, filtern Sie nach dem Messwertnamen collective_e2e_latency.

Host-zu-Gerät-Übertragungslatenz

Dies ist ein MXLA-Messwert, der die kumulative Verteilung der Host-zu-Gerät-Übertragungslatenzen für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage zur Datenübertragung über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert überwachen möchten, filtern Sie nach dem Messwertnamen host_to_device_transfer_latencies.

Gerät-zu-Host-Übertragungslatenz

Dies ist ein MXLA-Messwert, der die kumulative Verteilung der Gerät-zu-Host-Übertragungslatenzen für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage zur Datenübertragung über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert überwachen möchten, filtern Sie nach dem Messwertnamen device_to_host_transfer_latencies.

Behebung von allgemeinen Fehlern

Warnungen zu Hash der Beschleunigerkonfiguration nicht möglich

Die folgenden Meldungen sind nur Warnungen und wirken sich nicht auf die Leistung Ihres JAX-Codes aus.

INFO:jax._src.cache_key:get (_hash_accelerator_config): unable to hash accelerator config, falling back to hashing devices + platform: UNIMPLEMENTED: GetTopologyForDevices is not supported for the IFRT proxy client. (type <class 'jaxlib.xla_extension.XlaRuntimeError'>)

Berechtigung logging.logEntries.create für Ressource verweigert

Wenn der folgende Fehler angezeigt wird, prüfen Sie, ob das Compute Engine-Dienst konto, das von Vertex AI Workbench verwendet wird, Berechtigungen zum Schreiben von Logeinträgen in das Google Cloud Logging-System hat.

INFO:absl:Created 'ArrayHandler' with primary_host=0, replica-id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
Failed to submit 1 logs.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 65, in error_remapped_callable
    return callable_(**args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/grpc/_channel.py", line 1181, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 1006, in _end_unary_response_blocking
    raise _InactiveRpcError(state) # pytype: disable-not-instantiable
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
  status = StatusCode.PERMISSION_DENIED
  details = "Permission 'logging.logEntries.create' denied on resource (or it may not exist)."
  debug_error_string = "UNKNOWN:Error received from peer ipv4:216.239.34.174:443 {created_time:"2024-10-03T20:30:44.820425276+00.00", grpc_status:7, grpc_message:"Permission \'logging.logEntries.create\' denied on resource (or it may not exist)."}"
>

Fügen Sie dem Compute Engine-Dienstkonto die Rolle „Logs-Autor “ hinzu, um dieses Problem zu beheben.

Verbindung zum IFRT-Proxyserver nicht möglich

Wenn dieser Fehler angezeigt wird, kann Ihr IFRT-Proxyclient keine Verbindung zum IFRT-Proxyserver herstellen.

• Prüfen Sie, ob Ihr VPC-Netzwerk richtig konfiguriert ist.
• Prüfen Sie, ob Ihre Firewall so konfiguriert ist, dass die Verbindung zugelassen wird.
• Prüfen Sie, ob Ihr Pathways-Cluster bereitgestellt wurde.
• Suchen Sie nach Fehlermeldungen beim Start.

Wenn der erste JAX-Befehl, der einen IFRT-Befehl an den Pathways-Cluster sendet ausgeführt wird, reagiert er etwa eine Minute lang nicht und zeigt dann einen RuntimeError wie den folgenden an:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: DNS resolution failed (set JAX_PLATFORMS='' to automatically choose an available backend)

Es besteht bereits eine Verbindung zum Pathways-Cluster

Ein Pathways-Cluster kann jeweils nur eine Sitzung mit einem Client aufrechterhalten. Wenn zwei separate Notebooks versuchen, eine Verbindung zum selben Pathways-Cluster herzustellen, kann eines eine Verbindung herstellen und das andere zeigt die folgenden Fehler an.

INFO:absl:Created ArrayHandler with primary_host=0, replica_id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
E0927 21:19:52.919607   37624 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:03.467547   37719 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:14.011645   37807 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:24.557955   37924 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
---------------------------------------------------------------------------
XlaRuntimeError                           Traceback (most recent call last)
File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:887, in backends()
    885   continue
--> 887 backend = _init_backend(platform)
    888 _backends[platform] = backend

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:973, in _init_backend(platform)
    972 logger.debug("Initializing backend '%s'", platform)
--> 973 backend = registration.factory()
    974 # TODO: consider raising more descriptive errors directly from backend
    975 # factories instead of returning None.

File /opt/conda/lib/python3.10/site-packages/pathwaysutils/proxy_backend.py:24, in register_backend_factory.<locals>.<lambda>()
     21 def register_backend_factory():
     22   xla_bridge.register_backend_factory(
     23       "proxy",
---> 24       lambda: ifrt_proxy.get_client(
     25           jax.config.read("jax_backend_target"),
     26           ifrt_proxy.ClientConnectionOptions(),
     27       ),
     28       priority=-1,
     29   )

XlaRuntimeError: UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled

During handling of the above exception, another exception occurred:

RuntimeError                              Traceback (most recent call last)
Cell In[2], line 4
      1 import pathwaysutils
      3 import jax
----> 4 print(jax.devices())

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1085, in devices(backend)
   1060 def devices(
   1061     backend: str | xla_client.Client | None = None
   1062 ) -> list[xla_client.Device]:
   1063   """Returns a list of all devices for a given backend.
   1064
   1065   .. currentmodule:: jaxlib.xla_extension
   (...)
   1083     List of Device subclasses.
   1084   """
-> 1085   return get_backend(backend).devices()

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1019, in get_backend(platform)
   1015 @lru_cache(maxsize=None)  # don't use util.memoize because there is no X64 dependence.
   1016 def get_backend(
   1017     platform: None | str | xla_client.Client = None
   1018 ) -> xla_client.Client:
-> 1019   return _get_backend_uncached(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:998, in _get_backend_uncached(platform)
    994   return platform
    996 platform = (platform or _XLA_BACKEND.value or _PLATFORM_NAME.value or None)
--> 998 bs = backends()
    999 if platform is not None:
   1000   platform = canonicalize_platform(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:903, in backends()
    901       else:
    902         err_msg += " (you may need to uninstall the failing plugin package, or set JAX_PLATFORMS=cpu to skip this backend.)"
--> 903       raise RuntimeError(err_msg)
    905 assert _default_backend is not None
    906 if not config.jax_platforms.value:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address 'example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled (set JAX_PLATFORMS='' to automatically choose an available backend)

Sobald die Verbindung des ursprünglichen Clients getrennt wird, kann der zweite Client eine Verbindung herstellen. Nach einer unerwarteten Trennung müssen Sie möglicherweise den Pathways-Cluster neu starten, damit andere Clients eine Verbindung herstellen können.

`LocalProxy.__init__()` hat ein unerwartetes Schlüsselwortargument `unbound_message` erhalten

Wenn dieser Fehler nach dem Importieren von pathwaysutils angezeigt wird, prüfen Sie, ob in Ihrer Umgebung veraltete Versionen von Flask oder Werkzeug installiert sind:

 pip3 list --outdated (replacing pip with pip3 as needed)

Wenn Flask oder Werkzeug aufgeführt ist, sollten Sie ein Upgrade durchführen. Beachten Sie jedoch, dass dadurch andere Pakete oder Abhängigkeiten in Ihrem Projekt beschädigt werden können:

 pip install flask Werkzeug --upgrade ()

Interner Fehler vom Proxyserver

"Internal error from proxy server during Array::IsDeleted(): UNAVAILABLE:Connection to IFRT proxy server was terminated: FAILED_PRECONDITION:
GrpcClientSession: writes no longer allowed."

Dieser Fehler gibt an, dass die Verbindung des IFRT-Proxyservers zum Client getrennt wurde. Sie können das Problem beheben, indem Sie den Client neu starten. Bei Notebooks können Sie den Notebook-Kernel neu starten und das Notebook noch einmal ausführen.

SIGTERMS und HBM OOM

Ein SIGTERM in den Logs, der mit einem RESOURCE_EXHAUSTED-Fehler verknüpft ist, kann auf einen HBM OOM hinweisen. In diesem Fall können Sie die Menge des HBM-Speichers reduzieren, der in Ihrem JAX-Code verwendet wird.

INVALID_ARGUMENT

"INVALID_ARGUMENT : Permanent error, with a last message of Lifecycle
matches_prefix cannot specify more than 50 prefixes per config.; Error while
initializing persistent cache storage Cloud Storage"

Dieser Fehler tritt auf, wenn der Cloud Storage-Bucket, der an das Flag --pathways_gcs_location übergeben wurde, das maximale Limit für die Lebenszyklusrichtlinie erreicht hat. In diesem Fall müssen Sie Cloud Storage-Lebenszyklusrichtlinien bereinigen, die nicht mehr verwendet werden.

Dauerhafter Fehler

Permanent error, with a last message of The specified bucket does not exist.; Error while initializing persistent cache storage gcs

Dieser Fehler wird im Resource Manager oder auf den Pathways-Workern ausgegeben, wenn Sie für Pathways-Container einen ungültigen Cloud Storage-Speicherort angeben.

Fehlerantwort vom Daemon

Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude

Dieser Fehler tritt aufgrund einer alten Version von Docker auf. Führen Sie ein Upgrade auf die neueste Docker-Version durch.

IFRT-Proxyclient und -server konnten sich nicht einigen

IFRT Proxy client and server failed to agree on the protocol version; supported versions: client = [1, 1], server = [3, 14]

Dieser Fehler gibt an, dass eine ältere Version von MaxText verwendet wird. Erstellen Sie das neueste MaxText-Image neu.

Nächste Schritte

• Inferenz auf mehreren Hosts mit Pathways
• Batch-Arbeitslasten mit Pathways
• Interaktiver Modus von Pathways
• JAX-Arbeitslasten zu Pathways portieren
• Ausfallsicheres Training mit Pathways