Fehlerbehebung bei Pathways on Cloud

Hinweise

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

Logs ansehen

Verwenden Sie im Log-Explorer von Cloud Logging 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 Kubernetes-Containern für Pathways mit Namen wie pathways-rm, pathways-proxy und pathways-worker. Sie können das Problem eingrenzen, indem Sie einen Filter für den Containernamen hinzufügen, z. B. resource.labels.container_name:"<container_name>".

Monitoring

Statusmonitoring

Sie können den Zustand verschiedener Pathways-Komponenten überwachen, indem Sie beispielsweise in den Containerlogs nach Einträgen suchen:

pathways-proxy ist bereit, neue Verbindungsanfragen zu bearbeiten, 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 bearbeiten, wenn der folgende Logeintrag 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 Containerlogs von pathways-rm 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 verwendet virtuelle Slices, bis der Slice bereit ist. Mit virtuellen Slices kann Ihr Code auch dann ausgeführt werden, wenn keine TPUs verfügbar sind.

pathways-worker ist bereit, neue Verbindungsanfragen zu bearbeiten, 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 können Systemmesswerte auf niedriger Ebene zu Debugging-Zwecken in Cloud Monitoring schreiben. Die Messwerte enthalten:

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

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. Nach dem Namen des Messwerts filtern (Feld Messwert auswählen)
  3. Filtern Sie nach dem Namen Ihrer 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), mit dem die kumulative Verteilung der Netzwerkübertragungslatenzen für Multi-Slice-Traffic gemessen wird. Die Latenzmessung beginnt, wenn eine Anfrage zum Übertragen von Daten über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen dcn_transfer_latencies.

Gesamtlatenz

Dies ist ein MXLA-Messwert, der die kumulative Verteilung der End-to-End-Gesamtlatenz für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage für eine Sammlung ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten 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 zum Übertragen von Daten über das DCN ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen host_to_device_transfer_latencies.

Übertragungslatenz von Gerät zu Host

Dies ist eine MXLA-Messwert, mit dem die kumulative Verteilung der Geräte-zu-Host-Übertragungslatenzen für Multi-Slice-Traffic gemessen wird. Die Latenzmessung beginnt, wenn eine Anfrage zum Übertragen von Daten über das DCN gestellt wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen device_to_host_transfer_latencies.

Behebung von allgemeinen Fehlern

Warnungen zur Beschleunigerkonfiguration können nicht gehasht werden

Die folgenden Meldungen sind nur Warnungen und haben keine Auswirkungen auf die Leistung Ihres JAX-Codes.

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 von Vertex AI Workbench verwendete Compute Engine-Dienstkonto die 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)."}"
>

Um dieses Problem zu beheben, fügen Sie dem Compute Engine-Dienstkonto die Rolle Logs Writer hinzu.

Verbindung zum IFRT-Proxyserver kann nicht hergestellt werden

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

  • VPC-Netzwerk richtig konfigurieren
  • Firewall so konfigurieren, dass die Verbindung zugelassen wird
  • Prüfen, ob Ihr Pathways-Cluster bereitgestellt wurde
  • Nach Startfehlermeldungen suchen

Wenn Ihr erster 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 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 nur eines eine Verbindung herstellen. Im anderen werden die folgenden Fehler angezeigt.

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 zum ursprünglichen Client getrennt wird, kann der zweite Client eine Verbindung herstellen. Nach einer unerwarteten Trennung müssen Sie den Pathways-Cluster möglicherweise neu starten, damit sich andere Clients verbinden können.

LocalProxy.init() got an unexpected keyword argument 'unbound_message' (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 in Betracht ziehen. Beachten Sie jedoch, dass dadurch möglicherweise andere Pakete oder Abhängigkeiten in Ihrem Projekt beschädigt werden:

 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. Das Problem lässt sich durch einen Neustart des Clients beheben. 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, die mit einem RESOURCE_EXHAUSTED-Fehler verknüpft sind, kann auf einen HBM-OOM hinweisen. In diesem Fall können Sie die Menge an HBM-Speicher reduzieren, die 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 --pathways_gcs_location-Flag übergeben wurde, das maximale Limit für die Lebenszyklusrichtlinie erreicht hat. Wenn dies der Fall ist, sollten Sie nicht mehr verwendete Cloud Storage-Richtlinien für den Objektlebenszyklus bereinigen.

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 auf den Resource Manager- oder Pathways-Workern ausgegeben, wenn Sie einen ungültigen Cloud Storage-Speicherort für Pathways-Container angeben.

Fehlerantwort vom Daemon

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

Das liegt an einer alten Docker-Version. Aktualisieren Sie Ihre Docker-Version.

IFRT-Proxy-Client 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]

Das bedeutet, dass eine ältere Version von MaxText verwendet wird. Bauen Sie das neueste MaxText-Image neu.

Nächste Schritte