Soluciona problemas de Pathways on Cloud

Antes de comenzar

En este documento, se explica cómo solucionar problemas de tus cargas de trabajo de Pathways.

Visualiza registros

En el Explorador de registros de Cloud Logging, usa la siguiente consulta ajustada para que coincida con tu proyecto, región, clúster y carga de trabajo.

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"

Reemplaza lo siguiente:

  • PROJECT : tu Google Cloud ID del proyecto
  • LOCATION: la región o zona en la que creaste tu clúster de GKE
  • CLUSTER : el nombre del clúster de GKE
  • WORKLOAD_NAME : el nombre de tu carga de trabajo cuando usas XPK o el nombre de JobSet cuando usas kubectl

Esta consulta coincidirá con varios contenedores de Kubernetes de Pathways con nombres como pathways-rm, pathways-proxy y pathways-worker. Puedes reducir el contenedor que causa un problema agregando un filtro en el nombre del contenedor como resource.labels.container_name:"<container_name>"

Supervisión

Supervisión del estado

Puedes supervisar el estado de varios componentes de Pathways buscando entradas en los registros de contenedores, por ejemplo:

pathways-proxy está listo para atender solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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 está listo para atender solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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

Para verificar que todas las TPU registradas en el Administrador de recursos de Pathways estén listas, puedes buscar ***<num slices>/<num slices> Pathways Slices Now Ready *** en lospathways-rm registros de contenedores:

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 ***

El cliente de Pathways puede establecer conexiones con el servidor proxy de IFRT siempre que el servidor proxy esté listo, incluso si no lo están todas las porciones. Tu trabajo funciona con porciones virtuales hasta que la porción esté lista. Las porciones virtuales permiten que tu código se ejecute cuando las TPU no están disponibles.

pathways-worker está listo para atender solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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

Recopilación de métricas

Pathways puede escribir métricas del sistema de bajo nivel en Cloud Monitoring para la depuración. Las métricas incluyen lo siguiente:

  • Latencia de transferencia de DCN
  • Latencia colectiva
  • Latencia de transferencia de host a dispositivo
  • Latencia de transferencia de dispositivo a host

Puedes encontrar las métricas en el panel de Cloud Monitoring del proyecto {gcp_name} en el que se ejecuta el clúster de GKE.

Para supervisar estas métricas en el Explorador de métricas, haz lo siguiente:

  1. Navega al Explorador de métricas.
  2. Filtra por el nombre de la métrica con el campo Seleccionar una métrica.
  3. Filtra por el nombre de tu carga de trabajo y el período seleccionando Agregar filtro y filtrando por pod_name
  4. Elige un tipo de agregación adecuado según la métrica y las cargas de trabajo que supervisas.

Latencia de transferencia de DCN

Esta es una métrica de XLA a gran escala (MXLA) que mide la distribución acumulativa de las latencias de transferencia de red para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para que los datos se transfieran a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica dcn_transfer_latencies.

Latencia colectiva

Esta es una métrica de MXLA que mide la distribución acumulativa de la latencia colectiva de extremo a extremo para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para un colectivo y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica collective_e2e_latency.

Latencia de transferencia de host a dispositivo

Esta es una métrica de MXLA que mide la distribución acumulativa de las latencias de transferencia de host a dispositivo para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para que los datos se transfieran a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica host_to_device_transfer_latencies.

Latencia de transferencia de dispositivo a host

Esta es una métrica de MXLA que mide la distribución acumulativa de las latencias de transferencia de dispositivo a host para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para que los datos se transfieran a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica device_to_host_transfer_latencies.

Depura errores comunes

Advertencias de configuración del acelerador no hash

Los siguientes mensajes son solo advertencias y no afectan el rendimiento de tu código JAX.

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'>)

Permiso logging.logEntries.create denegado en el recurso

Si ves el siguiente error, asegúrate de que la cuenta de servicio de Compute Engine que usa Vertex AI Workbench tenga permisos para escribir entradas de registro en el sistema de registro. Google Cloud 

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)."}"
>

Para solucionar este problema, agrega el rol Escritor de registros a la cuenta de servicio de Compute Engine.

No se puede conectar al servidor proxy de IFRT

Si ves este error, tu cliente proxy de IFRT no puede conectarse al servidor proxy de IFRT.

  • Asegúrate de que tu red de VPC esté configurada correctamente.
  • Asegúrate de que tu firewall esté configurado para permitir la conexión.
  • Asegúrate de que se haya aprovisionado tu clúster de Pathways.
  • Comprueba si hay mensajes de error de inicio.

Cuando se intente ejecutar tu primer comando JAX que envía un comando IFRT al clúster de Pathways deje de responder durante aproximadamente un minuto y, luego, muestre un RuntimeError como el siguiente:

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)

Hay una conexión existente con el clúster de Pathways

Un clúster de Pathways solo puede mantener una sesión con un cliente a la vez. Si dos notebooks separados intentan conectarse al mismo clúster de Pathways, uno podrá conectarse y el otro mostrará los siguientes errores.

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)

Una vez que se desconecte el cliente original, el segundo cliente podrá conectarse. Después de una desconexión inesperada, es posible que debas reiniciar el clúster de Pathways para permitir que se conecten otros clientes.

LocalProxy.init() got an unexpected keyword argument 'unbound_message'

Si ves este error después de importar pathwaysutils, verifica si hay versiones obsoletas de Flask o Werkzeug instaladas en tu entorno:

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

Si aparece Flask o Werkzeug, considera actualizarlos con la advertencia de que hacerlo puede interrumpir otros paquetes o dependencias en tu proyecto:

 pip install flask Werkzeug --upgrade ()

Error interno del servidor proxy

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

Este error indica que el servidor proxy de IFRT se desconectó del cliente. Para corregirlo, reinicia el cliente. En el caso de los notebooks, puedes reiniciar el kernel del notebook y volver a ejecutarlo.

SIGTERMS y HBM OOM

Un SIGTERM que se encuentra en los registros asociados con un error RESOURCE_EXHAUSTED puede indicar un HBM OOM. En este caso, puedes reducir la cantidad de memoria HBM que se usa en tu código JAX.

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"

Este error se produce si el bucket de Cloud Storage que se pasó a la marca --pathways_gcs_location alcanzó el límite máximo de la política de ciclo de vida. Si esto sucede, limpia las políticas de ciclo de vida de Cloud Storage que ya no se usan.

Error permanente

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

Este error se imprime en el Resource Manager o en los trabajadores de Pathways cuando proporcionas una ubicación de Cloud Storage no válida a los contenedores de Pathways.

Error response from daemon

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

Esto se debe a una versión anterior de Docker. Actualiza tu versión de Docker.

IFRT Proxy client and server failed to agree

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

Esto indica que se está usando una versión anterior de MaxText. Asegúrate de volver a compilar la imagen más reciente de MaxText.

¿Qué sigue?