Se tiver problemas ao executar a tarefa do Dataflow com TPUs, use os seguintes passos de resolução de problemas para resolver o problema.
Resolva problemas com a imagem de contentor
Pode ser útil depurar o software de contentores e TPUs numa VM autónoma. Pode depurar com uma VM criada por um conjunto de nós do GKE ou pode depurar numa VM de trabalho do Dataflow em execução.
Depure com uma VM autónoma
Para depurar o seu contentor numa VM autónoma, pode criar um conjunto de nós do GKE que use a mesma VM de TPU para experimentação local.
Por exemplo, a criação de um node pool do GKE com um dispositivo TPU V5 Lite
em us-west1-c
teria o seguinte aspeto:
Crie um cluster do GKE.
gcloud container clusters create TPU_CLUSTER_NAME \ --project PROJECT_ID \ --release-channel=stable \ --scopes=cloud-platform \ --enable-ip-alias \ --location us-west1-c
Crie um node pool do GKE.
gcloud container node-pools create TPU_NODE_POOL_NAME \ --project PROJECT_ID \ --location=us-west1-c \ --cluster=TPU_CLUSTER_NAME \ --node-locations=us-west1-c \ --machine-type=ct5lp-hightpu-1t \ --num-nodes=1 \ [ --reservation RESERVATION_NAME \ --reservation-affinity=specific ]
Encontre o nome da VM do nó da TPU no conjunto de nós na IU do GKE ou com o seguinte comando.
gcloud compute instances list --filter='metadata.kube-labels:"cloud.google.com/gke-nodepool=TPU_NODEPOOL_NAME"'
Ligue-se a uma VM criada pelo node pool do GKE através de SSH:
gcloud compute ssh --zone "us-west1-c" "VM_NAME" --project PROJECT_ID
Depois de estabelecer ligação a uma VM através do SSH, configure o Docker para o Artifact Registry que está a usar.
docker-credential-gcr configure-docker --registries=us-west1-docker.pkg.dev
Em seguida, inicie um contentor a partir da imagem que usa.
docker run --privileged --network=host -it --rm --entrypoint=/bin/bash IMAGE_NAME
Dentro do contentor, teste se as TPUs estão acessíveis.
Por exemplo, se tiver uma imagem que usa o PyTorch para utilizar as TPUs, abra um intérprete Python:
python3
Em seguida, execute um cálculo num dispositivo TPU:
import torch import torch_xla.core.xla_model as xm dev = xm.xla_device() t1 = torch.randn(3,3,device=dev) t2 = torch.randn(3,3,device=dev) print(t1 + t2)
Exemplo de saída:
>>> tensor([[ 0.3355, -1.4628, -3.2610], >>> [-1.4656, 0.3196, -2.8766], >>> [ 0.8667, -1.5060, 0.7125]], device='xla:0')
Se o cálculo falhar, a imagem pode não estar configurada corretamente.
Por exemplo, pode ter de definir as variáveis de ambiente necessárias no Dockerfile da imagem. Para confirmar, tente novamente o cálculo depois de definir manualmente as variáveis de ambiente da seguinte forma:
export TPU_SKIP_MDS_QUERY=1 # Don't query metadata export TPU_HOST_BOUNDS=1,1,1 # There's only one host export TPU_CHIPS_PER_HOST_BOUNDS=1,1,1 # 1 chips per host export TPU_WORKER_HOSTNAMES=localhost export TPU_WORKER_ID=0 # Always 0 for single-host TPUs export TPU_ACCELERATOR_TYPE=v5litepod-1 # Since we use v5e 1x1 accelerator.
Se faltarem dependências do PyTorch ou do LibTPU, pode tentar novamente o cálculo depois de as instalar através do seguinte comando:
# Install PyTorch with TPU support pip install torch torch_xla[tpu] torchvision -f https://storage.googleapis.com/libtpu-releases/index.html
Depure através de uma VM do Dataflow
Em alternativa, pode estabelecer ligação à instância da VM do worker do Dataflow através de SSH enquanto um trabalho está em execução. Uma vez que as VMs do worker do Dataflow são encerradas após a conclusão do pipeline, pode ter de aumentar artificialmente o tempo de execução fazendo um cálculo que aguarde um período prolongado.
Uma vez que um dispositivo TPU não pode ser partilhado entre vários processos, pode ter de executar um pipeline que não faça cálculos numa TPU.
Encontre uma VM para a tarefa de TPU em execução pesquisando o ID da tarefa do Dataflow na barra de pesquisa da Google Cloud consola ou usando o seguinte comando
gcloud
:gcloud compute instances list --project PROJECT_ID --filter "STATUS='RUNNING' AND description ~ 'Created for Dataflow job: JOB_ID'"
Depois de estabelecer ligação a uma VM com TPUs através de SSH, inicie um contentor a partir da imagem que usa. Para ver um exemplo, consulte o artigo Depure com uma VM autónoma.
No contentor, reconfigure as definições da TPU e instale as bibliotecas necessárias para testar a configuração. Para ver um exemplo, consulte o artigo Depure com uma MV autónoma.
Os trabalhadores não começam
Antes de resolver problemas, verifique se as seguintes opções da conduta estão definidas corretamente:
- a opção
--dataflow_service_option=worker_accelerator
- a opção
--worker_zone
- a opção
--machine_type
Verifique se os registos da consola mostram que os trabalhadores estão a ser iniciados, mas a tarefa falha com uma mensagem semelhante à seguinte:
Workflow failed. Causes: The Dataflow job appears to be stuck because no worker
activity has been seen in the last 25m.
A causa destes problemas pode estar relacionada com a capacidade ou com problemas de início dos trabalhadores.
Capacidade: se usar capacidade de TPU a pedido ou uma reserva esgotada, os novos pipelines podem não ser iniciados até que a capacidade esteja disponível. Se usar uma reserva, verifique a respetiva capacidade restante na página de reservas de computação naGoogle Cloud consola ou com o seguinte comando:
gcloud compute reservations describe RESERVATION_NAME --zone ZONE
Verifique se a tarefa iniciou alguma VM de trabalho. Quando a tarefa inicia um worker, os registadores, como
worker
,worker_startup
,kubelet
e outros, geralmente fornecem resultados. Além disso, na página Estatísticas de tarefas na consola Google Cloud , o número de trabalhadores atuais deve ser superior a zero.Arranque do trabalhador: verifique os registos
job-message
elauncher
. Se o pipeline iniciar trabalhadores, mas estes não conseguirem arrancar, pode ter erros no seu contentor personalizado.Espaço em disco: verifique se existe espaço em disco suficiente para o seu trabalho. Para aumentar o espaço em disco, use a opção
--disk_size_gb
.
A tarefa falha com um erro
Use os seguintes conselhos de resolução de problemas quando a tarefa falha com um erro.
O início do grupo de trabalhadores falhou
Se vir o seguinte erro, verifique se a sua pipeline especifica
--worker_zone
e se a zona corresponde à zona da sua reserva.
JOB_MESSAGE_ERROR: Startup of the worker pool in zone ZONE failed to bring up any of the desired 1 workers. [...] INVALID_FIELD_VALUE: Instance 'INSTANCE_NAME' creation failed: Invalid value for field 'resource.reservationAffinity': '{ "consumeReservationType": "SPECIFIC_ALLOCATION", "key": "compute.googleapis.com/RESERVATION_NAME...'. Specified reservations [RESERVATION_NAME] do not exist.
Os grupos de instâncias geridas não suportam TPUs do Google Cloud
Se vir o seguinte erro, contacte a sua equipa de conta para verificar se o seu projeto foi inscrito para usar as TPUs ou registe um erro através do Google Issue Tracker.
apache_beam.runners.dataflow.dataflow_runner.DataflowRuntimeException: Dataflow pipeline failed. State: FAILED, Error: Workflow failed. Causes: One or more operations had an error [...]: [INVALID_FIELD_VALUE] 'Invalid value for field 'resource.instanceTemplate': Managed Instance Groups do not support Cloud TPUs. '.
Valor inválido para o campo
Se vir o seguinte erro, verifique se a invocação do pipeline define a opção do serviço Dataflow.worker_accelerator
JOB_MESSAGE_ERROR: Workflow failed. Causes: One or more operations had an error: 'operation-[...]': [INVALID_FIELD_VALUE] 'Invalid value for field 'resource.instanceTemplate': 'projects/[...]-harness'. Regional Managed Instance Groups do not support Cloud TPUs.'
Dispositivo ou recurso ocupado
Se vir o seguinte erro, significa que um worker do Dataflow que processa o seu pipeline está provavelmente a executar mais do que um processo que acede à TPU ao mesmo tempo. Esta opção não é suportada. Para mais informações, consulte o artigo TPUs e paralelismo de trabalhadores.
RuntimeError: TPU initialization failed: open(/dev/vfio/0): Device or resource busy: Device or resource busy; Couldn't open iommu group /dev/vfio/0
Se vir o erro anterior durante a depuração do pipeline numa VM, pode inspecionar e terminar o processo que está a impedir o funcionamento da TPU através dos seguintes comandos:
apt update ; apt install lsof
lsof -w /dev/vfio/0
kill -9 PROCESS_ID # to terminate the process.
As instâncias com aceleradores convidados não suportam a migração em direto
Se vir o seguinte erro, é provável que o pipeline tenha sido iniciado com um tipo de máquina definido explicitamente que tem aceleradores, mas não especificou a configuração do acelerador corretamente. Verifique se a invocação do pipeline define a opção do serviço Dataflow e certifique-se de que o nome da opção não contém gralhas.worker_accelerator
JOB_MESSAGE_ERROR: Startup of the worker pool in zone ZONE failed to bring up any of the desired 1 workers. [...] UNSUPPORTED_OPERATION: Instance INSTANCE_ID creation failed: Instances with guest accelerators do not support live migration.
O fluxo de trabalho foi automaticamente rejeitado pelo serviço
Os seguintes erros também podem ser apresentados se algumas das opções de pipeline necessárias estiverem em falta ou incorretas:
The workflow was automatically rejected by the service. The requested accelerator type tpu-v5-lite-podslice;topology:1x1 requires setting the worker machine type to ct5lp-hightpu-1t. Learn more at: https://cloud.google.com/dataflow/docs/guides/configure-worker-vm
Foi excedido o tempo limite enquanto aguardava uma atualização do trabalhador
Se iniciar pipelines em VMs de TPU com muitas vCPUs e não reduzir o número predefinido de threads de trabalho, a tarefa pode encontrar erros como os seguintes:
Workflow failed. Causes WORK_ITEM failed. The job failed because a work item has failed 4 times. Root cause: Timed out waiting for an update from the worker.
Para evitar este erro, reduza o número de threads. Por exemplo, pode definir:
--number_of_worker_harness_threads=50
.
Sem utilização de TPUs
Se o pipeline for executado com êxito, mas os dispositivos TPU não forem usados ou não estiverem acessíveis, verifique se as frameworks que está a usar, como o JAX ou o PyTorch, conseguem aceder aos dispositivos anexados. Para resolver problemas da imagem do contentor numa única VM, consulte o artigo Depurar com uma VM autónoma.