Hinweise
- Installierte XPKs
- Installierte Kubernetes-Tools
- 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 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-IDLOCATION: die Region oder Zone, in der Sie Ihren GKE-Cluster erstellt habenCLUSTER: der Name Ihres GKE-ClusterWORKLOAD_NAME: Der Name Ihrer Arbeitslast bei Verwendung von XPK oder der JobSet-Name bei Verwendung vonkubectl.
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:
- Rufen Sie den Metrics Explorer auf.
- Nach dem Namen des Messwerts filtern (Feld Messwert auswählen)
- Filtern Sie nach dem Namen Ihrer Arbeitslast und dem Zeitraum, indem Sie Filter hinzufügen auswählen und nach pod_name filtern.
- 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
- Inferenz auf mehreren Hosts mit Pathways
- Batch-Arbeitslasten mit Pathways
- Interaktiver Modus für Lernpfade
- JAX-Arbeitslasten zu Pathways migrieren
- Belastbares Training mit Pathways