Hinweis
- Cluster Toolkit einrichten
- Installierte Kubernetes-Tools
- gcloud CLI installiert
- Google Kubernetes Engine API aktivieren
- Google Kubernetes Engine-Cluster mit Pathways erstellt
In diesem Dokument wird beschrieben, wie Sie Probleme mit Pathways-Arbeitslasten beheben.
Logs ansehen
Sie können Logs für Ihre Pathways-Arbeitslasten direkt mit dem Befehl gcluster job logs aufrufen. Übergeben Sie --main-only=false, um Worker-Pod-Logs einzuschließen:
gcluster job logs WORKLOAD_NAME \
--cluster=CLUSTER \
--project=PROJECT_ID \
--location=LOCATION \
--main-only=false
Wenn Sie alle Pods für Ihre Arbeitslast mit kubectl auflisten möchten, verwenden Sie das Cluster Toolkit-Arbeitslastlabel:
kubectl get pods -l gcluster.google.com/workload=WORKLOAD_NAME
Mit dem Befehl gcluster job list können Sie den Arbeitslaststatus prüfen oder fehlgeschlagene Jobs auflisten:
gcluster job list --status Failed \
--cluster=CLUSTER \
--project=PROJECT_ID \
--location=LOCATION
Alternativ können Sie im Log-Explorer von Cloud Logging die folgende Abfrage verwenden, 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 Projekt-ID in Google CloudLOCATION: die Region oder Zone, in der Sie Ihren GKE-Cluster erstellt habenCLUSTER: der Name Ihres GKE-ClusterWORKLOAD_NAME: der Name Ihrer Arbeitslast, wenn Sie das Cluster Toolkit verwenden, oder der JobSet-Name, wenn Siekubectlverwenden
Diese Abfrage stimmt mit mehreren Pathways-Kubernetes-Containern mit Namen wie pathways-rm, pathways-proxy, pathways-worker überein. 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 Zustand verschiedener Pathways-Komponenten überwachen, indem Sie nach Einträgen in den Containerlogs suchen, z. B.:
pathways-proxy ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn das 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 das 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 beim Pathways Resource Manager registrierten TPUs bereit sind, können Sie in den Containerlogs von pathways-rm nach ***<num slices>/<num slices> Pathways Slices Now Ready *** suchen:
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 arbeitet 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 das 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 Low-Level-Systemmesswerte zu Debugging-Zwecken in Cloud Monitoring schreiben. Die Messwerte enthalten:
- DCN-Übertragungslatenz
- Gesamtlatenz
- Latenz bei der Übertragung von Host zu Gerät
- Latenz bei der Übertragung von Gerät zu Host
Sie finden die Messwerte im Cloud Monitoring-Dashboard des ProjektsGoogle Cloud , in dem der GKE-Cluster ausgeführt wird.
So überwachen Sie diese Messwerte im Metrics Explorer:
- Rufen Sie den Metrics Explorer auf.
- Filtern Sie im Feld Messwert auswählen nach dem Namen des Messwerts.
- Filtern Sie nach dem Namen und dem Zeitraum der Arbeitslast, 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), der die kumulative Verteilung der Netzwerkübertragungslatenzen für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage zur Übertragung 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 Monitoring beobachten 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 gesendet 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.
Latenz bei der Übertragung von Host zu Gerät
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 ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert beobachten möchten, filtern Sie nach dem Messwertnamen host_to_device_transfer_latencies.
Übertragungslatenz von Gerät zu Host
Dies ist ein MXLA-Messwert, der die kumulative Verteilung der Übertragungslatenzen von Gerät zu Host für Multi-Slice-Traffic misst. Die Latenzmessung beginnt, wenn eine Anfrage zur Datenübertragung über das DCN ausgegeben wird, und endet, wenn eine Bestätigung eingeht, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Monitoring beobachten 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 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 von Vertex AI Workbench verwendete Compute Engine-Dienstkonto Berechtigungen zum Schreiben von Logeinträgen in das Logging-System von Google Cloud 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 Log-Autor hinzu, um dieses Problem zu beheben.
Verbindung zum IFRT-Proxyserver kann nicht hergestellt werden
Wenn dieser Fehler angezeigt wird, kann Ihr IFRT-Proxy-Client keine Verbindung zum IFRT-Proxy-Server herstellen.
- VPC-Netzwerk richtig konfigurieren
- Achten Sie darauf, dass Ihre Firewall so konfiguriert ist, dass die Verbindung zugelassen wird.
- Prüfen, ob Ihr Pathways-Cluster bereitgestellt wurde
- Nach Fehlermeldungen beim Start suchen
Wenn der erste JAX-Befehl, der einen IFRT-Befehl an den Pathways-Cluster sendet, ausgeführt wird, reagiert er etwa eine Minute lang nicht mehr 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)
ALTS-Handshake fehlgeschlagen oder Socket beim Herstellen einer Verbindung zum IFRT-Proxyserver geschlossen
Wenn Sie Alts handshake failed (TSI_INTERNAL_ERROR) oder UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed sehen, wenn Sie ein benutzerdefiniertes Manifest ohne das Feld hostNetwork: true in einem GKE-Workload Identity-Knotenpool ausführen, legen Sie die Umgebungsvariable IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" sowohl für den Container pathways-proxy als auch für den JAX-Clientcontainer fest (beide Seiten müssen übereinstimmen). Wenn Sie diese Umgebungsvariable hinzufügen, wird ALTS deaktiviert und stattdessen unsicheres gRPC verwendet.
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 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 zum ursprünglichen Client getrennt wird, kann der zweite Client eine Verbindung herstellen. Nach einer unerwarteten Trennung der Verbindung müssen Sie den Pathways-Cluster möglicherweise neu starten, damit andere Clients eine Verbindung herstellen können.
LocalProxy.init() got an unexpected keyword argument 'unbound_message'
Wenn dieser Fehler nach dem Importieren von pathwaysutils auftritt, 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 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 zwischen dem IFRT-Proxyserver und dem 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, das mit einem RESOURCE_EXHAUSTED-Fehler verknüpft ist, kann auf einen HBM-OOM-Fehler hinweisen. In diesem Fall können Sie die Menge des in Ihrem JAX-Code verwendeten HBM-Speichers reduzieren.
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 im Flag --pathways_gcs_location übergeben wurde, das maximale Limit für Lebenszyklusrichtlinien erreicht hat. In diesem Fall sollten Sie nicht mehr verwendete Cloud Storage-Lebenszyklusrichtlinien 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.
Error response from daemon
Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude
Dies 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]
Dies weist darauf hin, dass eine ältere Version von MaxText verwendet wird. Erstellen Sie das neueste MaxText-Image neu.