Monitorar instâncias do Compute Engine e clusters do Slurm

Neste documento, explicamos como usar os painéis do Cloud Monitoring para monitorar as instâncias A4X Max, A4X, A4, A3 Ultra e A3 Mega criadas usando a capacidade vinculada à reserva. O uso desses painéis ajuda a identificar e resolver problemas de gargalos de desempenho nas instâncias independentes do Compute Engine ou nos clusters do Slurm, minimizando o tempo de inatividade nas cargas de trabalho.

Ao criar painéis personalizados ou usar painéis pré-criados do Monitoring, é possível monitorar o seguinte:

  • Integridade da instância de computação

  • Performance da GPU

  • Eficiência da transmissão de rede

  • Eficiência de rede entre blocos e sub-blocos

  • Eficiência da carga de trabalho de machine learning (ML)

  • Detecção de tarefas retardatárias

  • Detecção de carga de trabalho que não responde

Para monitorar os clusters do Cluster Director, consulte Monitorar o desempenho do cluster com painéis predefinidos.

Antes de começar

Antes de monitorar sua carga de trabalho, se ainda não tiver feito isso, conclua as seguintes etapas:

Quando você usa o console do Google Cloud para acessar os serviços e as APIs do Google Cloud , não é necessário configurar a autenticação.

Limitações

  • As métricas neste documento só são compatíveis com cargas de trabalho executadas em instâncias de computação que atendem a todos os seguintes critérios:

    • As instâncias de computação precisam ser criadas como instâncias independentes do Compute Engine ou como parte de um cluster do Slurm.
    • As instâncias de computação precisam ter sido criadas usando a capacidade vinculada à reserva.
    • As instâncias de computação precisam usar as séries de máquinas A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
      • No entanto, a detecção de retardatários também é compatível com instâncias de máquina virtual (VM) que usam a série de máquinas A3 Mega.

Para monitorar as métricas de carga de trabalho de ML, é necessário configurar o monitoramento para sua carga de trabalho.

Limitações da detecção de tarefas retardatárias

As métricas de detecção de retardatários têm as seguintes limitações adicionais:

  • Para séries de máquinas compatíveis que não sejam A3 Mega, a detecção de retardatários só é compatível com instâncias de computação que permitem que a biblioteca Collective Communication Analyzer (CoMMA) exporte a telemetria NCCL para os serviços do Google Cloud . Para mais informações, consulte Visão geral do CoMMA.
  • A detecção de retardatários normalmente leva até 10 minutos para informar um retardatário.
  • Ao contrário das outras métricas neste documento, não é possível filtrar as métricas de detecção de retardatários para seus projetos por cluster, bloco, sub-bloco ou instância de computação. No entanto, é possível filtrar consultas de registros de detecção de retardatários pelo ID de uma ou mais instâncias de computação que são suspeitas de serem retardatárias.

Limitações da detecção de cargas de trabalho que não respondem

As métricas de detecção de carga de trabalho sem resposta só são compatíveis com instâncias de computação que usam a biblioteca Collective Communication Analyzer (CoMMA) para exportar a telemetria NCCL para os serviços do Google Cloud . Para mais informações, consulte Visão geral do CoMMA.

Funções exigidas

Para receber as permissões necessárias para monitorar métricas de cargas de trabalho do hipercomputador de IA, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para monitorar métricas de cargas de trabalho do Hipercomputador de IA. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para monitorar as métricas das cargas de trabalho do hipercomputador de IA:

  • Para visualizar painéis: monitoring.dashboards.get no projeto
  • Para criar painéis: monitoring.dashboards.create no projeto
  • Para ver as entradas de registro: logging.logEntries.list no projeto

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Métricas disponíveis

Dependendo do seu caso de uso, as seguintes métricas estão disponíveis para monitorar as instâncias de computação e os clusters do Slurm:

Para saber como visualizar essas métricas, consulte Visualizar métricas neste documento.

Métricas de infraestrutura:

Para monitorar a integridade, o desempenho e o desempenho de rede das GPUs anexadas às instâncias de computação, use as seguintes métricas:

Para uma visão geral das métricas disponíveis no Compute Engine, consulte Métricas doGoogle Cloud .

Métricas de saúde da GPU

Para monitorar a integridade das GPUs, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Status da máquina machine/machine_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Se a máquina usada pela instância de computação está íntegra ou não e precisa de reparo.
Status do NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Se um switch NVLink em uma GPU NVIDIA anexada a uma instância de computação está com problemas.
Integridade da infraestrutura da VM instance/gpu/infra_health A4X, A4, A3 Ultra ou A3 Mega A integridade do cluster, do bloco, do sub-bloco e do host em que as instâncias de computação estão em execução. Se essa métrica mostrar que a infraestrutura de uma instância de computação não está íntegra, ela também vai descrever o problema.
Pontuação de previsão de falha da VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra ou A3 Mega A probabilidade de o host em que a instância de computação é executada ser degradado nas próximas cinco horas. O valor pode estar entre 0.0 e 1.0. Quanto mais próximo o valor permanecer de 1.0 por um período consistente, maior será a probabilidade de a instância de computação se degradar. Nesse caso, recomendamos que você mova o job para uma instância de computação diferente e, se encontrar problemas com a instância de computação, informe o host como defeituoso.

Métricas de desempenho da GPU

Para monitorar o desempenho das GPUs, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Uso de contexto acumulado instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra ou A3 Mega O tempo total, em segundos, em que a GPU está ocupada processando uma carga de trabalho.
Consumo de energia da GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra ou A3 Mega A energia em watts (W) e em valores decimais consumida em GPUs individuais no host. Para instâncias de computação com várias GPUs anexadas, a métrica fornece o consumo de energia separadamente para cada GPU no host.
Utilização do SM instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra ou A3 Mega Um valor diferente de zero indica que os multiprocessadores de streaming (SMs) nas GPUs estão sendo usados ativamente.
Temperatura da GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra ou A3 Mega A temperatura em graus Celsius (℃) e em valores decimais de GPUs individuais no host. Para instâncias de computação com várias GPUs anexadas, a métrica fornece a temperatura separadamente para cada GPU no host.
Margem térmica da GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra ou A3 Mega A margem térmica em Celsius (℃) e em valores decimais que as GPUs individuais têm antes de precisarem desacelerar devido à alta temperatura. Para instâncias de computação com várias GPUs anexadas, a métrica fornece o headroom térmico separadamente para cada GPU no host.

Métricas de desempenho de rede da GPU

Para monitorar o desempenho de rede das GPUs, use as métricas a seguir. Para monitorar as trocas de rede ToR de back-end, consulte Métricas de troca ToR.

Nome Tipo de métrica Série de máquinas compatível Descrição
Mudanças no Link Carrier instance/gpu/link_carrier_changes A4X, A4, A3 Ultra ou A3 Mega Com que frequência a operadora do link de rede muda em um minuto.
RTT de rede instance/gpu/network_rtt A4X, A4, A3 Ultra ou A3 Mega O tempo de retorno, medido em microssegundos, para que os dados de rede viajem entre uma origem e um destino.
Tráfego de rede entre blocos instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra ou A3 Mega O número de bytes de tráfego de rede entre blocos.
Tráfego de rede entre sub-blocos instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra ou A3 Mega O número de bytes de tráfego de rede entre sub-blocos.
Tráfego de rede no sub-bloco interno instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra ou A3 Mega O número de bytes de tráfego de rede em um único sub-bloco.
Velocidade ativa do NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra ou A3 Mega A velocidade atual da porta do link de acesso, em GBps.
Bytes de Rx de capacidade de processamento instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra ou A3 Mega O número de bytes recebidos do tráfego de rede.
Bytes de TX de capacidade de processamento instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra ou A3 Mega O número de bytes transmitidos para o tráfego de rede.

Métricas do switch ToR

Para clusters A4X Max e A4X, é possível monitorar a telemetria da troca de rede ToR de back-end para fazer o seguinte durante o treinamento de ML distribuído:

  • Observe a integridade do switch e da porta.
  • Avaliar a capacidade de largura de banda disponível e as profundidades da fila do buffer.
  • Diagnosticar descartes de pacotes, erros, flaps de interface e eventos de gerenciamento de congestionamento.

Essas métricas usam o tipo de recurso monitorado compute.googleapis.com/NetworkSwitch e o prefixo de tipo de métrica compute.googleapis.com/. No Metrics Explorer, selecione o tipo de recurso NetworkSwitch (compute.googleapis.com/NetworkSwitch).

As métricas de troca são organizadas nas seguintes categorias:

Métricas de integridade e status do switch

Use as métricas listadas nesta seção para fazer o seguinte:

  • Verificar o status de funcionamento das portas do switch.
  • Monitorar o uso da CPU e da memória do switch.
  • Verifique os tempos de inicialização para detectar reinicializações inesperadas.
Nome Tipo de métrica Série de máquinas compatível Descrição
Status da portabilidade network_switch/port_status A4X Max ou A4X Indica o status de funcionamento da interface física (porta) no switch de rede. O valor da métrica é sempre 1 para agregação. O estado real é fornecido no rótulo status (como UP ou DOWN).
Rótulos de chave: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Uso da CPU network_switch/cpu_utilization A4X Max ou A4X O uso da CPU da troca de rede, medido como uma fração de 0.0 a 1.0.
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Memória usada network_switch/memory_used A4X Max ou A4X A memória usada pela troca de rede, em bytes.
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Memória total network_switch/total_memory_bytes A4X Max ou A4X A capacidade total de memória da troca de rede, em bytes.
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Tempo de inicialização network_switch/boot_time_in_ns A4X Max ou A4X O carimbo de data/hora de inicialização da troca de rede, em nanossegundos desde a época Unix.
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Métricas de capacidade e fila do switch

Para acompanhar a capacidade de rede de referência em relação à capacidade utilizável e monitorar as profundidades da fila do buffer e as quedas de fila no switch, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Capacidade de referência network_switch/baseline_capacity_kbps A4X Max ou A4X A capacidade total de largura de banda de referência potencial de uma conexão de switch ToR com o superbloco, em quilobits por segundo (kbit/s).
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Capacidade efetiva network_switch/effective_capacity_kbps A4X Max ou A4X A capacidade operacional utilizável de uma conexão de switch ToR com o superbloco, em quilobits por segundo (kbit/s). Essa métrica reflete as reduções de capacidade causadas por links degradados ou off-line.
Rótulos de chave: subblock_id, block_id, reservation_id, switch_type.
Profundidade máxima da fila de saída network_switch/egress_max_queue_depth A4X Max ou A4X A profundidade máxima da fila observada durante o ciclo de medição mais recente.
Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Descartes da fila de saída network_switch/egress_queue_drops_count A4X Max ou A4X A contagem cumulativa de pacotes descartados das filas de saída devido ao congestionamento da fila ou ao esgotamento do buffer.
Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Descartes no buffer network_switch/in_buffer_discards A4X Max ou A4X A contagem cumulativa de pacotes recebidos descartados na entrada devido ao estouro de buffer.
Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Métricas de quedas, erros e controle de fluxo do switch

Use as métricas desta seção para diagnosticar os seguintes problemas, que podem causar interrupções no treinamento distribuído ou tempos limite de comunicação coletiva (como tempos limite do watchdog do NCCL):

  • Descarte de pacotes, erros de transmissão e oscilações de link físico.
  • Erros de palavra de correção de erros de encaminhamento (FEC, na sigla em inglês).
  • Eventos de gerenciamento de congestionamento, como pausas de controle de fluxo baseado em prioridade (PFC, na sigla em inglês) e marcações de notificação explícita de congestionamento (ECN, na sigla em inglês).
Nome Tipo de métrica Série de máquinas compatível Descrição
Flaps de interface network_switch/interface_flaps_count A4X Max ou A4X A contagem cumulativa de transições de estado de link físico (flaps entre UP e DOWN) na interface da porta do switch.
Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erros de palavra de FEC network_switch/fec_word_error_count A4X Max ou A4X A contagem cumulativa de erros de palavra de correção de erros de encaminhamento (FEC, na sigla em inglês). Use o rótulo booleano correctable (true ou false) para distinguir entre erros corrigíveis e não corrigíveis.
Rótulos de chave: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Pacotes marcados com ECN network_switch/ecn_marked_packets_count A4X Max ou A4X A contagem cumulativa de pacotes marcados com bits de notificação explícita de congestionamento (ECN, na sigla em inglês) devido a cruzamentos de limite de buffer.
Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pacotes rx do PFC network_switch/pfc_rx_packets_count A4X Max ou A4X A contagem cumulativa de frames de pausa do controle de fluxo baseado em prioridade (PFC, na sigla em inglês) recebidos na porta.
Observação: aplicável apenas a ambientes dedicados em que o PFC está ativado.
Rótulos de chave: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Pacotes de TX do PFC network_switch/pfc_tx_packets_count A4X Max ou A4X A contagem cumulativa de frames de pausa do controle de fluxo baseado em prioridade (PFC, na sigla em inglês) transmitidos para fora da porta para limitar o tráfego de entrada.
Observação: aplicável apenas a ambientes dedicados em que o PFC está ativado.
Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Pacotes tx de QoS network_switch/qos_tx_packets A4X Max ou A4X A contagem cumulativa de pacotes de Qualidade de Serviço (QoS) transmitidos na fila especificada.
Rótulos de chave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Contagem de pacotes de entrada network_switch/in_packets_count A4X Max ou A4X A contagem cumulativa de pacotes recebidos na porta do switch.
Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Em erros network_switch/in_errors A4X Max ou A4X A contagem cumulativa de pacotes recebidos com erros que impediram a entrega.
Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Em descartes network_switch/in_discards A4X Max ou A4X A contagem cumulativa de pacotes de entrada válidos que foram descartados (por exemplo, devido à falta de espaço no buffer).
Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erros de saída network_switch/out_errors A4X Max ou A4X A contagem cumulativa de pacotes de saída que não foram transmitidos devido a erros.
Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Descartes de saída network_switch/out_discards A4X Max ou A4X A contagem cumulativa de pacotes de saída que foram escolhidos para serem descartados, mesmo que nenhum erro tenha sido detectado.
Rótulos de chave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Contagem de bytes de entrada network_switch/in_bytes_count A4X Max ou A4X A contagem cumulativa de bytes recebidos na porta do switch.
Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Contagem de bytes de saída network_switch/out_bytes_count A4X Max ou A4X A contagem cumulativa de bytes de saída transmitidos para fora da porta do switch.
Rótulos de chave: port_identifier, subblock_id, block_id, reservation_id, switch_type.

Métricas de erros fatais da GPU

Para monitorar os erros que as GPUs encontram e que podem forçar a interrupção das instâncias de computação ou afetar negativamente o desempenho delas, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Erro de tempo de execução do NVLink instance/gpu/nvlink_runtime_error A4X Max ou A4X Se ocorreu um erro de tempo de execução do NVLink.
Erros de ECC da DRAM não corrigíveis instance/gpu/dram_uncorrectable_ecc_error_count A4X Max ou A4X O número de códigos de correção de erros (ECCs, na sigla em inglês) não corrigíveis em uma memória de acesso aleatório dinâmica (DRAM, na sigla em inglês) da GPU.
Contagem não corrigível de remapeamento de linhas da DRAM instance/gpu/dram_uncorrectable_row_remapping_count A4X Max ou A4X O número de remapeamentos de linhas de erros não corrigíveis em DRAMs de GPU.
Falha no remapeamento não corrigível de linhas da DRAM instance/gpu/dram_row_remapping_failed A4X Max ou A4X Se um remapeamento de linha em DRAMs de GPU falhou devido a um dos seguintes problemas:
  • Uma tentativa de remapeamento em um banco de memória falhou porque o banco de memória já tem oito linhas de erro não corrigíveis remapeadas.
  • Uma tentativa de remapeamento em uma linha falhou porque ela já havia sido remapeada.
  • Uma tentativa de remapeamento falhou porque ocorreram 512 remapeamentos no total.
Erros de PCIe não corrigíveis instance/gpu/pcie_fatal_error_count A4X Max ou A4X O número de erros não corrigíveis de interconexão de componentes periféricos express (PCIe).
Erros de ECC de cache não corrigíveis instance/gpu/cache_uncorrectable_ecc_error_count A4X Max ou A4X O número de ECCs não corrigíveis na memória cache.

Métricas de carga de trabalho de ML

Para monitorar a produtividade, especificamente o goodput, das suas cargas de trabalho de ML, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Tempo produtivo workload/goodput_time A4X, A4, A3 Ultra ou A3 Mega O tempo, em segundos, que a carga de trabalho gasta em atividades de goodput. Essas atividades são tarefas principais e úteis, como uma passagem para frente ou para trás durante treinamento de modelo.
Tempo não produtivo workload/badput_time A4X, A4, A3 Ultra ou A3 Mega O tempo, em segundos, que a carga de trabalho gasta em atividades de badput. Essas atividades são tarefas de sobrecarga, como carregar ou pré-processar dados para treinamento.

Métricas de detecção de tarefas retardatárias

As métricas de detecção de retardatários ajudam a identificar e apontar suspeitas. Retardatários são falhas de ponto único que não causam falhas e que, por fim, desaceleram toda a carga de trabalho.

Para monitorar a detecção de stragglers nas VMs, use a seguinte métrica:

Nome Tipo de métrica Série de máquinas compatível Descrição
Suspeita de stragglers instance/gpu/straggler_status A4X, A4, A3 Ultra ou A3 Mega Se uma VM é suspeita de ser um retardatário que está afetando o desempenho da carga de trabalho. Recomendamos que você tome medidas em relação a suspeitas de atrasos somente quando outras métricas indicarem que a carga de trabalho está com problemas.

Também é possível conferir as métricas de detecção de atrasos nas entradas de registro de uma instância A4X, A4, A3 Ultra ou A3 Mega. Por exemplo, use as seguintes consultas:

Descrição Consulta
Registros com suspeita de atrasos em VMs específicas. Use essa consulta para verificar se há suspeitas de stragglers em uma carga de trabalho específica no projeto. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Substitua INSTANCE_ID pelo ID de uma VM. Para cada VM adicional que você quiser especificar, adicione a seguinte condição à consulta:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Todos os registros da detecção de retardatários do seu projeto. Use essa consulta para verificar se o serviço de detecção de retardatários está em execução quando nenhum retardatário suspeito é detectado. Devido às limitações, não é possível filtrar os registros sem suspeita de retardatários por VMs específicas. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

As métricas de detecção de stragglers são particularmente úteis para cargas de trabalho de ML em grande escala pelos seguintes motivos:

  • As cargas de trabalho de ML em grande escala são muito suscetíveis a atrasos. As cargas de trabalho de ML em grande escala usam computação síncrona e massivamente distribuída. Em outras palavras, eles têm muitos componentes altamente interdependentes que são executados simultaneamente. Essa arquitetura torna as cargas de trabalho de ML em grande escala muito suscetíveis a falhas de ponto único, como retardatários.

  • É muito difícil identificar e localizar stragglers em cargas de trabalho de ML em grande escala. Para referência, considere que há dois tipos de falhas de ponto único:

    • Falhas de interrupção: falhas que causam a interrupção de todo o sistema, como erros de host e eventos de manutenção. Eles são relativamente fáceis de detectar e resolver.

    • Falhas lentas: falhas que causam degradação grave de desempenho sem falhas. Eles são muito difíceis de identificar e depurar.

    Devido à natureza de falha lenta, os retardatários são inerentemente difíceis de perceber e identificar, especialmente em cargas de trabalho síncronas de grande escala.

Métricas de detecção de carga de trabalho sem resposta

As métricas de detecção de cargas de trabalho sem resposta ajudam você a:

  • Perceber quando uma carga de trabalho inteira é interrompida (às vezes chamada de travamento da NCCL)
  • Entender por que a carga de trabalho foi interrompida, por exemplo, se foi causada por uma falha no processo ou uma rede travada.

Para detectar e diagnosticar cargas de trabalho que não respondem nas instâncias de computação, use as seguintes métricas:

Nome Tipo de métrica Série de máquinas compatível Descrição
Eventos de carga de trabalho sem resposta detectados usando a telemetria NCCL instance/gpu/nccl_hang A4X Max, A4X, A4 e A3 Ultra O número de eventos de carga de trabalho sem resposta detectados, como uma série temporal.

Ativar a detecção de cargas de trabalho que não respondem

Para ativar a detecção de cargas de trabalho que não respondem, ative o CoMMA com a telemetria de heartbeat, um sinal de ping periódico que indica que uma carga de trabalho está em execução. Nas versões recentes do CoMMA, isso é ativado por padrão. No entanto, se você estiver usando a versão do CoMMA da versão 1.1.1 do pacote NICCL/gIB, será necessário ativar manualmente a telemetria de heartbeat. Para verificar qual versão do pacote NICCL/gIB você está usando, consulte Verificar a versão do NCCL e do gIB.

Para ativar manualmente a telemetria de heartbeat para o CoMMA, especifique as seguintes variáveis de ambiente no ambiente de treinamento:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Use NCCL_PROFILER_HEARTBEAT para ativar ou desativar a telemetria de heartbeat e NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL para especificar a frequência da telemetria de heartbeat. Para mais informações, consulte Variáveis de ambiente do CoMMA.

Desativar a detecção de cargas de trabalho que não respondem

Para desativar a detecção de cargas de trabalho que não respondem, desative a telemetria de heartbeat no CoMMA especificando a seguinte variável de ambiente no ambiente de treinamento:

NCCL_PROFILER_HEARTBEAT=false

Entender por que as cargas de trabalho não estão respondendo

Para entender por que uma carga de trabalho não está respondendo, verifique o valor do rótulo hang_reason seguindo estas etapas:

  1. No console Google Cloud , acesse a página do  Metrics explorer:

    Acesse o Metrics Explorer

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.

  2. Pesquise a seguinte métrica:

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Use o recurso Agregação e selecione os seguintes rótulos:

    • instance_id
    • hang_reason

A tabela a seguir lista os valores possíveis para o rótulo, o que esses valores significam sobre as cargas de trabalho e as próximas etapas recomendadas.

Valor do rótulo Descrição Próximas etapas recomendadas
MissingHeartbeatIssue A telemetria de heartbeat foi interrompida para uma ou mais classificações, o que geralmente indica uma falha fatal de processo ou nó.
  • Verifique se a instância ainda está acessível.
  • Verifique se os processos de carga de trabalho falharam.
  • Verifique se há eventos de falta de memória (OOM, na sigla em inglês), como dmesg, nos registros do sistema.
  • Procure falhas de hardware ou erros NVIDIA XID.
StalledRankIssue A telemetria de heartbeat ainda está sendo recebida, mas as classificações não estão avançando nas operações do NCCL.
  • Investigue possíveis impasses em operações no nível do app.
  • Verifique se o processo do aplicativo está travado em uma operação que o impede de se comunicar com outros, como computação ou checkpointer.
MissingCommunicatorIssue Todas as classificações que pertencem a um comunicador NCCL pararam de progredir.
  • Sua carga de trabalho pode ter sido interrompida ou os comunicadores NCCL podem ter sido fechados abruptamente. Se você espera que uma carga de trabalho seja executada sem interrupções nessa instância de VM, verifique se ela foi interrompida ou encerrada de maneira anormal.
NoHangIssue O valor padrão. Nenhum problema foi detectado.
  • Você não precisa fazer nada.

Ver métricas

Para conferir as métricas das instâncias de computação e dos clusters do Slurm, use os painéis do Monitoring da seguinte maneira:

Se você tiver problemas ao usar um painel, consulte Resolver problemas de desempenho lento.

Usar painéis predefinidos

É possível usar os painéis do Monitoring pré-criados para o Hipercomputador de IA para conferir as métricas das instâncias de computação e dos clusters do Slurm. Também é possível criar uma cópia de um painel predefinido e modificá-la para atender às suas necessidades.

Para usar um painel predefinido para o AI Hypercomputer, faça o seguinte:

  1. No console Google Cloud , acesse a página  Painéis:

    Acesse Painéis

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.

  2. Na coluna Nome, clique no nome de um dos seguintes painéis, com base nas métricas que você quer visualizar:

    • Para monitorar a integridade da instância de computação, o desempenho da GPU e a detecção de retardatários, use o painel Monitoramento de integridade do Cluster Director.

      Para mais informações sobre como usar essas métricas para identificar e analisar problemas, use também o painel do manual Manual interativo do GCE: monitoramento de integridade do diretor de cluster.

    • Para monitorar a eficiência da transmissão de rede, use o painel Eficiência da transmissão do Cluster Director.

    • Para monitorar a eficiência da rede entre blocos e sub-blocos, use o painel Rede de blocos do Cluster Director.

      Para mais informações sobre como usar essas métricas para identificar e analisar problemas, use também o painel do playbook GCE Interactive Playbook - Cluster Director Block Network.

    A página de detalhes do painel escolhido é aberta. Use o seletor de período na barra de ferramentas para mudar o período dos dados.

  3. Opcional: para criar uma cópia de um painel e personalizá-la de acordo com suas necessidades, clique em Copiar painel.

Criar painéis personalizados

Para criar um painel personalizado do Monitoring, faça o seguinte:

  1. Escolha as métricas que você quer monitorar. Se ainda não tiver feito isso, consulte Métricas disponíveis neste documento.

  2. Criar e gerenciar painéis personalizados.

Ver registros de detecção de atrasos

Para conferir os registros de detecção de retardatários usando o Análise de registros, siga estas etapas:

  1. No console do Google Cloud , acesse a página Análise de registros:

    Acessar a Análise de registros

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

    Por padrão, a página consulta todos os registros no projeto. Clique em Interromper consulta.

  2. Use o seletor de período na barra de ferramentas para selecionar o período que você quer analisar.

  3. No painel Consulta, insira uma consulta para registros de detecção de stragglers.

  4. Selecione Executar consulta.

Veja a seguir um exemplo de entrada de registro de detecção de retardatários.

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }

A entrada de registro inclui os seguintes campos:

  • numNodes: o número de instâncias de computação suspeitas de serem retardatárias detectadas no projeto. No exemplo, quatro instâncias de computação suspeitas de serem retardatárias foram detectadas.
  • instanceId: o ID de uma instância de computação que foi detectada como um suspeito atrasado.

A seguir