Resolver problemas com os programas do Pathways on Cloud

Antes de começar

Neste documento, explicamos como resolver problemas com as cargas de trabalho do Pathways.

Como ver registros

É possível conferir os registros das cargas de trabalho do Pathways diretamente usando o comando gcluster job logs (transmita --main-only=false para incluir registros de pods de worker):

gcluster job logs WORKLOAD_NAME \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION \
    --main-only=false

Para listar todos os pods da carga de trabalho usando kubectl, use o rótulo de carga de trabalho do Cluster Toolkit:

kubectl get pods -l gcluster.google.com/workload=WORKLOAD_NAME

Para verificar o status da carga de trabalho ou listar jobs com falha, use o comando gcluster job list:

gcluster job list --status Failed \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION

Como alternativa, na Análise de registros do Cloud Logging, use a seguinte consulta ajustada para corresponder ao projeto, à região, ao cluster e à carga de trabalho:

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"

Substitua:

  • PROJECT : o ID do projeto do Google Cloud
  • LOCATION: a região ou zona em que você criou o cluster do GKE.
  • CLUSTER : o nome do cluster do GKE.
  • WORKLOAD_NAME: o nome da carga de trabalho ao usar o Cluster Toolkit ou o nome do JobSet ao usar kubectl

Essa consulta vai corresponder a vários contêineres do Kubernetes do Pathways com nomes como pathways-rm, pathways-proxy, pathways-worker. É possível restringir qual contêiner está causando um problema adicionando um filtro no nome do contêiner, como resource.labels.container_name:"<container_name>".

Monitoramento

Monitoramento de integridade

É possível monitorar a integridade de vários componentes do Pathways procurando entradas nos registros do contêiner, por exemplo:

O pathways-proxy estará pronto para atender a novas solicitações de conexão quando o seguinte registro for gravado:

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

O pathways-rm estará pronto para atender a novas solicitações de conexão quando o seguinte registro for gravado:

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 se todas as TPUs registradas no Gerenciador de Recursos do Pathways estão prontas, procure ***<num slices>/<num slices> Pathways Slices Now Ready *** nos registros do contêiner 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 ***

O cliente do Pathways pode se conectar ao servidor proxy do IFRT desde que o servidor proxy esteja pronto, mesmo que nem todas as frações estejam prontas. Seu job funciona com frações virtuais até que a fração fique pronta. As frações virtuais permitem que o código seja executado quando as TPUs não estão disponíveis.

O pathways-worker estará pronto para atender a novas solicitações de conexão quando o seguinte registro for gravado:

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

Coleta de métricas

O Pathways pode gravar métricas de sistema de baixo nível no Cloud Monitoring para depuração. As métricas incluem:

  • Latência de transferência da DCN
  • Latência coletiva
  • Latência de transferência de host para dispositivo
  • Latência de transferência de dispositivo para host

Encontre as métricas no painel do Cloud Monitoring do projeto doGoogle Cloud em que o cluster do GKE está em execução.

Para monitorar essas métricas no Metrics Explorer:

  1. Acesse o Metrics Explorer.
  2. Filtre pelo nome da métrica usando o campo Selecionar uma métrica.
  3. Filtre pelo nome da carga de trabalho e pelo período selecionando Adicionar filtro e filtre por pod_name.
  4. Escolha um tipo de agregação adequado com base na métrica e nas cargas de trabalho que você está monitorando.

Latência de transferência da DCN

Essa é uma métrica do Megascale XLA (MXLA) que mede a distribuição cumulativa das latências de transferência de rede para o tráfego multislice. A medição de latência começa quando uma solicitação de transferência de dados pela DCN é emitida e termina quando uma confirmação é recebida de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome dcn_transfer_latencies.

Latência coletiva

Essa é uma métrica do MXLA que mede a distribuição cumulativa da latência coletiva de ponta a ponta para o tráfego multislice. A medição de latência começa quando uma solicitação de operação de comunicação coletiva é emitida e termina quando uma confirmação é recebida de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome collective_e2e_latency.

Latência de transferência de host para dispositivo

Essa é uma métrica do MXLA que mede a distribuição cumulativa das latências de transferência de host para dispositivo para tráfego multislice. A medição de latência começa quando uma solicitação de transferência de dados pela DCN é emitida e termina quando uma confirmação é recebida de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome da métrica host_to_device_transfer_latencies.

Latência de transferência de dispositivo para host

Essa é uma métrica do MXLA que mede a distribuição cumulativa de latências de transferência de dispositivo para host para tráfego multislice. A medição de latência começa quando uma solicitação de transferência de dados pela DCN é emitida e termina quando uma confirmação é recebida de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome device_to_host_transfer_latencies.

Como depurar erros comuns

Não foi possível gerar hash dos avisos de configuração do acelerador

As mensagens a seguir são apenas avisos e não afetam o desempenho do seu 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'>)

Permissão logging.logEntries.create negada no recurso

Se você receber o erro a seguir, verifique se a conta de serviço do Compute Engine usada pelo Vertex AI Workbench tem permissões para gravar entradas de registro no sistema de geração de registros do 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 corrigir esse problema, adicione o papel Gravador de registros à conta de serviço do Compute Engine.

Não é possível se conectar ao servidor proxy do IFRT

Se você encontrar esse erro, significa que o cliente proxy do IFRT não consegue se conectar ao servidor proxy do IFRT.

  • Verificar se a rede VPC está configurada corretamente
  • Verifique se o firewall está configurado para permitir a conexão
  • Verificar se o cluster do Pathways foi provisionado
  • Verificar se há mensagens de erro de inicialização

Quando o primeiro comando JAX que envia um comando IFRT ao cluster do Pathways tentar ser executado, ele vai parar de responder por cerca de um minuto e exibir um RuntimeError como este:

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)

Falha no handshake do ALTS ou soquete fechado ao se conectar ao servidor proxy do IFRT

Se você encontrar Alts handshake failed (TSI_INTERNAL_ERROR) ou UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed ao executar um manifesto personalizado sem o campo hostNetwork: true em um pool de nós da Identidade da carga de trabalho do GKE, defina a variável de ambiente IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" no contêiner pathways-proxy e no contêiner do cliente JAX (os dois lados precisam corresponder). A adição dessa variável de ambiente desativa o ALTS e usa o gRPC não seguro.

Há uma conexão com o cluster do Pathways

Um cluster do Pathways só pode manter uma sessão com um cliente por vez. Se dois notebooks separados tentarem se conectar ao mesmo cluster do Pathways, um deles conseguirá se conectar e o outro mostrará os erros a seguir.

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)

Depois que o cliente original se desconectar, o segundo poderá se conectar. Após uma desconexão inesperada, talvez seja necessário reiniciar o cluster do Pathways para permitir que outros clientes se conectem.

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

Se esse erro aparecer depois de importar pathwaysutils, verifique se há versões desatualizadas do Flask ou do Werkzeug instaladas no seu ambiente:

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

Se o Flask ou o Werkzeug estiverem listados, considere fazer upgrade deles, mas lembre-se de que isso pode corromper outros pacotes ou dependências no projeto:

 pip install flask Werkzeug --upgrade ()

Erro interno do 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."

Esse erro indica que o servidor proxy do IFRT foi desconectado do cliente. Para corrigir isso, reinicie o cliente. Para notebooks, é possível reiniciar o kernel e executar o notebook novamente.

SIGTERMS e HBM OOM

Um SIGTERM encontrado nos registros associados a um erro RESOURCE_EXHAUSTED pode indicar uma OOM de HBM. Nesse caso, é possível reduzir a quantidade de memória de HBM usada no seu 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"

Esse erro vai ocorrer se o bucket do Cloud Storage transmitido para a flag --pathways_gcs_location tiver atingido o limite máximo da política de ciclo de vida. Se isso ocorrer, limpe as políticas de ciclo de vida do Cloud Storage que não estão mais sendo usadas.

Erro permanente

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

Esse erro é exibido nos workers do Resource Manager ou do Pathways quando você fornece um local inválido do Cloud Storage para os contêineres do Pathways.

Resposta de erro do daemon

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

Isso ocorre devido a uma versão antiga do Docker. Faça upgrade da versão do Docker.

O cliente e o servidor do proxy IFRT não concordaram

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

Isso indica que uma versão mais antiga do MaxText está sendo usada. Recrie a imagem mais recente do MaxText.

A seguir