Soluciona problemas de Pathways on Cloud

Antes de comenzar

En este documento, se explica cómo solucionar problemas relacionados con 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 : El ID de tu proyecto de Google Cloud
  • LOCATION: Es la región o zona en la que creaste el clúster de GKE.
  • CLUSTER : Es el nombre de tu clúster de GKE.
  • WORKLOAD_NAME : Es el nombre de tu carga de trabajo cuando usas XPK o el nombre de JobSet cuando usas kubectl.

Esta búsqueda coincidirá con varios contenedores de Kubernetes de Pathways con nombres como pathways-rm, pathways-proxy y pathways-worker. Para determinar qué contenedor está causando un problema, puedes agregar 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 del contenedor, por ejemplo:

pathways-proxy está listo para atender nuevas solicitudes de conexión 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 nuevas solicitudes de conexión 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 los registros del contenedor pathways-rm:

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 todos los segmentos. Tu trabajo funciona con segmentos virtuales hasta que el segmento está listo. Las porciones virtuales permiten que tu código se ejecute cuando las TPU no están disponibles.

pathways-worker está listo para atender nuevas solicitudes de conexión 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

Las rutas pueden 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. Para filtrar por el nombre de tu carga de trabajo y el período, selecciona Agregar filtro y filtra 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 Megascale XLA (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 de datos para transferir a través de la DCN y finaliza cuando se recibe una confirmación 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

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 una confirmación 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

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 de transferencia de datos a través de la DCN y finaliza cuando se recibe una confirmación 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

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 de datos para transferir a través de la DCN y finaliza cuando se recibe una confirmación 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 los errores comunes

No se pueden generar hashes de las advertencias de configuración del acelerador

Los siguientes mensajes son solo advertencias y no afectan el rendimiento de tu código de 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'>)

Se denegó el permiso logging.logEntries.create 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 corregir este problema, agrega el rol de Logs Writer a la cuenta de servicio de Compute Engine.

No se puede establecer conexión con el servidor proxy de IFRT

Si ves este error, significa que 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 el 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 de JAX que envía un comando de IFRT al clúster de Pathways, dejará de responder durante aproximadamente un minuto y, luego, mostrará 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)

Ya existe una conexión 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 el cliente original se desconecte, 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() recibió un argumento de palabra clave inesperado "unbound_message"

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

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

Si se muestran Flask o Werkzeug, considera actualizarlos, pero ten en cuenta que hacerlo puede dañar otros paquetes o dependencias de 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 solucionar este problema, reinicia el cliente. En el caso de los notebooks, puedes reiniciar el kernel y volver a ejecutar el notebook.

SIGTERMS y HBM OOM

Un SIGTERM que se encuentra en los registros asociados con un error RESOURCE_EXHAUSTED puede indicar un error de OOM de HBM. En este caso, puedes reducir la cantidad de memoria HBM que se usa en tu código de 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 políticas de ciclo de vida. Si esto ocurre, 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 los trabajadores de Resource Manager o de Pathways cuando proporcionas una ubicación de Cloud Storage no válida para los contenedores de Pathways.

Respuesta de error del 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.

No se pudo establecer un acuerdo entre el cliente y el servidor de IFRT Proxy

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?