Monitorar instâncias do Compute Engine e clusters do Slurm

Neste documento, explicamos como usar os painéis do Cloud Monitoring para monitorar instâncias A4X Max, A4X, A4, A3 Ultra e A3 Mega criadas com capacidade vinculada à reserva. Usar esses painéis ajuda a identificar e resolver problemas de gargalos de desempenho nas suas instâncias autônomas do Compute Engine ou clusters do Slurm, minimizando a inatividade nas suas cargas de trabalho.

Ao criar painéis personalizados ou usar painéis predefinidos 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 da 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 sem resposta

Para monitorar clusters do Cluster Director, consulte Monitorar a performance do cluster com painéis pré-criados.

Antes de começar

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

Quando você usa o console Google Cloud para acessar serviços Google Cloud e APIs, 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 critérios a seguir:

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

As métricas neste documento são compatíveis apenas 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 autônomas do Compute Engine ou como parte de um cluster do Slurm.
  • As instâncias de computação precisam ter sido criadas usando capacidade reservada.
  • As instâncias de computação precisam usar a série de máquinas A4X Max, A4X, A4, A3 Ultra ou A3 Mega.

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

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

As métricas de detecção de outliers 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 straggler só é compatível com instâncias de computação que permitem que a biblioteca Collective Communication Analyzer (CoMMA) exporte a telemetria do NCCL para serviços Google Cloud . Para mais informações, consulte a visão geral do CoMMA.
  • A detecção de atrasados geralmente leva até 10 minutos para informar um atrasado.
  • Ao contrário das outras métricas neste documento, não é possível filtrar as métricas de detecção de outliers para seus projetos por cluster, bloco, subbloco ou instância de computação. No entanto, é possível filtrar consultas para registros de detecção de atrasos pelo ID de uma ou mais instâncias de computação suspeitas.

Limitações da detecção de cargas de trabalho sem resposta

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 do NCCL para serviços do Google Cloud . Para mais informações, consulte a visão geral do CoMMA.

Funções exigidas

Para receber as permissões necessárias para monitorar métricas de cargas de trabalho do AI Hypercomputer, 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 métricas de cargas de trabalho do Hipercomputador de IA:

  • Para ver painéis: monitoring.dashboards.get no projeto
  • Para criar painéis: monitoring.dashboards.create no projeto
  • Para ver 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 suas instâncias de computação e 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 da rede das GPUs conectadas à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 integridade 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 Mostra se a máquina usada pela instância de computação está íntegra ou se ela não está 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 conectada a uma instância de computação está apresentando problemas.
Integridade da infraestrutura de VM instance/gpu/infra_health A4X, A4, A3 Ultra ou A3 Mega A integridade do cluster, do bloco, do subbloco e do host em que as instâncias de computação estão sendo executadas. 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 degradação do host em que a instância de computação é executada 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 a probabilidade de degradação da instância de computação. Nesse caso, recomendamos que você mova o job para outra instância de computação e, se encontrar problemas com a instância, informe o host dela como com falha.

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, 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 graus Celsius (℃) e em valores decimais que as GPUs individuais têm antes de precisarem reduzir a velocidade 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 da rede das GPUs, use as seguintes métricas. Para monitorar switches de rede ToR de back-end, consulte Métricas de switch ToR.

Nome Tipo de métrica Série de máquinas compatível Descrição
Mudanças na operadora do link 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 da rede instance/gpu/network_rtt A4X, A4, A3 Ultra ou A3 Mega O tempo de retorno, medido em microssegundos, para que os dados da 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 nível intra-sub-bloco 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 subbloco.
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 de switch ToR

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

  • Observe a integridade do switch e da porta.
  • Avalie a capacidade de largura de banda disponível e as profundidades da fila do buffer.
  • Diagnosticar eventos de descarte de pacotes, erros, oscilações de interface e 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:

Alternar métricas de integridade e status

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

  • Verifique o status operacional das portas do switch.
  • Monitore o uso de CPU e 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 operacional 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 principais: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 A utilização da CPU da troca de rede, medida 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 pelo switch 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 do switch 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 do switch de rede, em nanossegundos desde a época do Unix.
Rótulos principais:subblock_id, block_id, reservation_id, switch_type.
Alternar métricas de capacidade e fila

Para acompanhar a capacidade de rede de linha de base versus 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 potencial de largura de banda de referência de uma conexão de switch ToR com o superbloco, em quilobits por segundo (kbit/s).
Rótulos principais: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 corrompidos 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 a congestionamento ou esgotamento do buffer.
Rótulos de chave:port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Em descartes de buffer network_switch/in_buffer_discards A4X Max ou A4X A contagem cumulativa de pacotes de entrada descartados na entrada devido a 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 desistências, erros e controle de fluxo de chaves

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

  • Descarte de pacotes, erros de transmissão e flaps de link físico.
  • Erros de palavra de correção de erros de encaminhamento (FEC).
  • Eventos de gerenciamento de congestionamento, como pausas do controle de fluxo baseado em prioridade (PFC) e marcações de notificação explícita de congestionamento (ECN).
Nome Tipo de métrica Série de máquinas compatível Descrição
Abas da interface network_switch/interface_flaps_count A4X Max ou A4X A contagem cumulativa de transições de estado do 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 palavras fecais network_switch/fec_word_error_count A4X Max ou A4X A contagem cumulativa de erros de palavra da 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) devido a cruzamentos de limite de buffer.
Rótulos de chave:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pacotes de recebimento de 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) recebidos na porta.
Observação:válido apenas para 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 transmissão 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 pela porta para limitar o tráfego de entrada.
Observação:válido apenas para 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 de transmissão 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.
Em contagem de pacotes network_switch/in_packets_count A4X Max ou A4X A contagem cumulativa de pacotes recebidos na porta do switch.
Rótulos principais: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.
Na lixeira 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 pela 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 encontrados pelas GPUs 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 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) não corrigíveis em uma memória de acesso aleatório dinâmica (DRAM) 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 da GPU.
Falha no remapeamento de linhas da DRAM não corrigível instance/gpu/dram_row_remapping_failed A4X Max ou A4X Indica se um remapeamento de linhas em DRAMs de GPU falhou devido a um dos seguintes problemas:
  • Uma tentativa de remapeamento em um banco de memória falhou porque ele já tem oito linhas de erro não corrigíveis remapeadas.
  • Uma tentativa de remapeamento em uma linha falhou porque ela já estava remapeada.
  • Uma tentativa de remapeamento falhou porque ocorreram 512 remapeamentos totais.
Erros não corrigíveis de PCIe instance/gpu/pcie_fatal_error_count A4X Max ou A4X O número de erros incorrigí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 passa em atividades de goodput. Essas atividades são tarefas principais e úteis, como uma transmissão direta ou inversa durante o 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 carregamento ou pré-processamento de dados para treinamento.

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

As métricas de detecção de atrasados ajudam você a notar e identificar suspeitos. Retardatários são falhas de ponto único que não causam falhas, mas acabam atrasando toda a carga de trabalho.

Para monitorar a detecção de tarefas lentas nas suas 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 atraso 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, você pode usar as seguintes consultas:

Descrição Consulta
Registros com suspeita de atrasos para VMs específicas. Use esta consulta para verificar se há atrasos suspeitos em uma carga de trabalho específica no seu 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ê quer especificar, adicione a seguinte condição à consulta:

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

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

  • Cargas de trabalho de ML em grande escala são muito suscetíveis a atrasos. Cargas de trabalho de ML em grande escala usam computação síncrona e distribuída em massa. 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 atrasos.

  • É muito difícil notar e identificar outliers 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 paralisação de todo o sistema, por exemplo, erros de host e eventos de manutenção. Eles são relativamente simples de detectar e resolver.

    • Falhas lentas: falhas que causam degradação grave de desempenho sem falhas. É muito difícil identificar e depurar esses problemas.

    Devido à natureza de falha lenta, é difícil notar e identificar os atrasados, 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 carga de trabalho sem resposta ajudam você a:

  • Perceber quando uma carga de trabalho inteira está parada (às vezes chamada de NCCL hang)
  • Entenda por que a carga de trabalho foi interrompida, por exemplo, se foi causada por uma falha no processo ou por uma rede paralisada.

Para detectar e diagnosticar cargas de trabalho sem resposta nas suas 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 do 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 sem resposta

Para ativar a detecção de carga de trabalho sem resposta, é necessário ativar o CoMMA com a telemetria de pulsação, um sinal de ping periódico que indica que uma carga de trabalho está em execução. Para versões recentes do CoMMA, essa opção é ativada por padrão. No entanto, se você estiver usando a versão do CoMMA do pacote NICCL/gIB 1.1.1, será necessário ativar manualmente a telemetria de pulsação. 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 pulsação 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 pulsação e NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL para especificar a frequência dela. Para mais informações, consulte Variáveis de ambiente do CoMMA.

Desativar a detecção de carga de trabalho sem resposta

Para desativar a detecção de cargas de trabalho sem resposta, desative a telemetria de pulsação no CoMMA especificando a seguinte variável de ambiente no ambiente de treinamento:

NCCL_PROFILER_HEARTBEAT=false

Entenda por que as cargas de trabalho não respondem

Para entender por que uma carga de trabalho não responde, 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 suas cargas de trabalho e as próximas etapas recomendadas.

Valor do rótulo Descrição Próximas etapas recomendadas
MissingHeartbeatIssue A telemetria de pulsação foi interrompida para um ou mais ranks, o que geralmente indica uma falha fatal no processo ou no 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), como dmesg, nos registros do sistema.
  • Procure falhas de hardware ou erros XID da NVIDIA.
StalledRankIssue A telemetria de pulsação ainda está sendo recebida, mas as classificações não estão progredindo nas operações do NCCL.
  • Investigue possíveis impasses em operações no nível do app.
  • Verifique se o processo de aplicativo está preso em uma operação que impede a comunicação com outros, como computação ou ponto de verificação.
MissingCommunicatorIssue Todos os ranks 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 desligada 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 Solução de problemas de desempenho lento.

Usar painéis predefinidos

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

Para usar um painel predefinido para o Hipercomputador de IA, 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 atrasos, use o painel Monitoramento da 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 Playbook interativo do GCE: monitoramento da integridade do Cluster Director.

    • Para monitorar a eficiência da transmissão de rede, use o painel Eficiência de 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 interativo do GCE: rede de bloqueio do Cluster Director.

    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á-lo 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 a serem monitoradas. 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 straggler

Para conferir os registros de detecção de outliers usando a 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 seu projeto. Clique em Interromper consulta.

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

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

  4. Selecione Executar consulta.

Confira a seguir um exemplo de entrada de registro de detecção de atraso.

  {
    ...
    "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 lentas detectadas no projeto. No exemplo, foram detectadas quatro instâncias de computação suspeitas.
  • instanceId: o ID de uma instância de computação detectada como um possível elemento atrasado.

A seguir