Detalhamento do desempenho do build

Informar um problemaopen_in_new Acessar a origemopen_in_new

Ele é complexo e faz muitas coisas diferentes durante um build, e algumas delas podem afetar o desempenho. Esta página tenta mapear alguns desses conceitos do Bazel para as implicações no desempenho do build. Embora não seja extenso, incluímos alguns exemplos de como detectar problemas de desempenho de build usando a extração de métricas e o que é possível fazer para corrigi-los. Esperamos que você possa aplicar esses conceitos ao investigar regressões de desempenho do build.

Builds limpos x incrementais

Um build limpo é aquele que cria tudo do zero, enquanto um build incremental reutiliza alguns trabalhos já concluídos.

Sugerimos analisar builds limpos e incrementais separadamente, especialmente quando você está coletando / agregando métricas que dependem do estado dos caches do Bazel (por exemplo, métricas de tamanho da solicitação de build). Elas também representam duas experiências de usuário diferentes. Em comparação com iniciar um build limpo do zero (que leva mais tempo devido a um cache frio), os builds incrementais acontecem com muito mais frequência à medida que os desenvolvedores iteram no código (geralmente mais rápido, porque o cache geralmente já está quente).

Você pode usar o campo CumulativeMetrics.num_analyses no BEP para classificar builds. Se num_analyses <= 1, é um build limpo. Caso contrário, podemos categorizá-lo amplamente como um build incremental, ou seja, o usuário pode ter mudado para diferentes flags ou diferentes destinos, resultando em um build eficientemente limpo. Qualquer definição mais rigorosa de incrementabilidade provavelmente terá que vir na forma de uma heurística, por exemplo, analisando o número de pacotes carregados (PackageMetrics.packages_loaded).

Métricas determinísticas do build como substitutos do desempenho do build

Medir o desempenho do build pode ser difícil devido à natureza não determinista de determinadas métricas, como o tempo de CPU do Bazel ou os tempos de fila em um cluster remoto. Por isso, pode ser útil usar métricas determinísticas como substitutos da quantidade de trabalho realizado pelo Bazel, que, por sua vez, afeta o desempenho dele.

O tamanho de uma solicitação de versão pode ter uma implicação significativa no desempenho da versão. Um build maior pode representar mais trabalho na análise e criação dos gráficos de build. O crescimento orgânico dos builds ocorre naturalmente com o desenvolvimento, à medida que mais dependências são adicionadas/criadas, o que aumenta a complexidade e a criação delas.

Podemos dividir esse problema nas várias fases de criação e usar as seguintes métricas como métricas de proxy para o trabalho realizado em cada fase:

1. PackageMetrics.packages_loaded: o número de pacotes carregados. Aqui, uma regressão representa a maior quantidade de trabalho a ser feito para ler e analisar cada arquivo BUILD extra na fase de carregamento.

   • Isso geralmente ocorre devido à adição de dependências e à necessidade de carregar o fechamento transitivo delas.
   • Use query / cquery para descobrir onde novas dependências podem ter sido adicionadas.

2. TargetMetrics.targets_configured: representa o número de destinos e aspectos configurados no build. Uma regressão representa mais trabalho na construção e passagem do gráfico de destino configurado.

   • Isso geralmente ocorre devido à adição de dependências e à necessidade de construir o gráfico do fechamento transitivo.
   • Use cquery para descobrir onde novas dependências podem ter sido adicionadas.

3. ActionSummary.actions_created: representa as ações criadas no build, e uma regressão representa mais trabalho na construção do gráfico de ações. Isso também inclui ações não usadas que podem não ter sido executadas.

   • Use aquery para depurar regressões. Sugerimos começar com --output=summary antes de detalhar mais com --skyframe_state.

4. ActionSummary.actions_executed: o número de ações executadas. Uma regressão representa diretamente mais trabalho na execução dessas ações.

   • O BEP grava as estatísticas de ação ActionData que mostram os tipos de ação mais executados. Por padrão, ela coleta os 20 principais tipos de ação, mas você pode transmitir o --experimental_record_metrics_for_all_mnemonics para coletar esses dados para todos os tipos de ação executados.
   • Isso ajudará você a descobrir que tipos de ação foram executados (além disso).

5. BuildGraphSummary.outputArtifactCount: o número de artefatos criados pelas ações executadas.

   • Se o número de ações executadas não aumentou, é provável que a implementação de uma regra tenha sido alterada.

Todas essas métricas são afetadas pelo estado do cache local. Portanto, verifique se os builds de que você extrai essas métricas são builds limpos.

Observamos que uma regressão em qualquer uma dessas métricas pode ser acompanhada por regressões no tempo decorrido, no tempo de CPU e no uso de memória.

Uso de recursos locais

Ele consome uma variedade de recursos na máquina local, tanto para analisar o gráfico do build quanto para executar a execução, além de executar ações locais. Isso pode afetar o desempenho e a disponibilidade da máquina ao executar o build, assim como outras tarefas.

Tempo gasto

Talvez as métricas mais suscetíveis a ruídos (e possam variar muito de build para build) sejam o tempo, principalmente o tempo decorrido, da CPU e do sistema. Você pode usar o bazel-bench para ter um comparativo para essas métricas e, com um número suficiente de --runs, será possível aumentar a significância estatística da sua medição.

• Tempo decorrido é o tempo decorrido real.

  • Se apenas o tempo decorrido regressa, sugerimos a coleta de um perfil de rastreamento JSON e a busca por diferenças. Caso contrário, provavelmente seria mais eficiente investigar outras métricas regressivas, porque elas podem ter afetado o tempo tempo decorrido.

• Tempo de CPU é o tempo que a CPU gasta executando o código do usuário.

  • Se o tempo de CPU regressar em duas confirmações de projeto, sugerimos a coleta de um perfil de CPU do Starlark. Você provavelmente também precisa usar --nobuild para restringir a criação à fase de análise, já que é nele que a maior parte do trabalho pesado da CPU é feita.

• O tempo do sistema é o tempo gasto pela CPU no kernel.

  • Se o tempo do sistema regressa, isso está relacionado principalmente à E/S quando o Bazel lê arquivos do seu sistema de arquivos.

Criação de perfil de carga em todo o sistema

Usando a sinalização --experimental_collect_load_average_in_profiler introduzida no Bazel 6.0, o criador de perfil de trace JSON coleta a média de carga do sistema durante a invocação.

Figura 1. Perfil que inclui a média de carga do sistema.

Uma carga alta durante uma invocação do Bazel pode ser uma indicação de que ele programa muitas ações locais em paralelo para sua máquina. É recomendável analisar o ajuste de --local_cpu_resources e --local_ram_resources, especialmente em ambientes de contêiner (pelo menos até o #16512 ser mesclado).

Como monitorar o uso de memória do Bazel

Há duas fontes principais para acessar o uso de memória do Bazel, info e BEP.

• bazel info used-heap-size-after-gc: a quantidade de memória usada em bytes após uma chamada para System.gc().

  • O Bazel bench também fornece comparativos para essa métrica.
  • Além disso, há peak-heap-size, max-heap-size, used-heap-size e committed-heap-size (consulte a documentação), mas são menos relevantes.

• MemoryMetrics.peak_post_gc_heap_size do BEP: tamanho do heap de pico da JVM em bytes após a GC (requer a configuração de --memory_profile que tenta forçar uma GC completa).

Uma regressão no uso da memória geralmente é resultado de uma regressão nas métricas de tamanho da solicitação de build, que geralmente ocorrem devido à adição de dependências ou a uma mudança na implementação da regra.

Para analisar o consumo de memória do Bazel em um nível mais granular, recomendamos usar o Memory Profiler integrado para regras.

Criação de perfil de memória de workers persistentes

Os trabalhadores permanentes podem ajudar a acelerar significativamente as versões (principalmente no caso de linguagens interpretadas), mas o consumo de memória pode ser problemático. O Bazel coleta métricas sobre os workers. Em particular, o campo WorkerMetrics.WorkerStats.worker_memory_in_kb informa a quantidade de memória usada pelos workers (por mnemônico).

O criador de perfil de trace JSON também coleta o uso de memória de worker persistente durante a invocação transmitindo a sinalização --experimental_collect_system_network_usage (nova no Bazel 6.0).

Figura 2. Perfil que inclui o uso de memória dos workers.

Reduzir o valor de --worker_max_instances (padrão 4) pode ajudar a diminuir a quantidade de memória usada pelos workers permanentes. Estamos trabalhando ativamente para tornar o gerenciador de recursos e o programador do Bazel mais inteligentes, para que esses ajustes sejam necessários com menos frequência no futuro.

Como monitorar o tráfego de rede para builds remotos

Na execução remota, o Bazel faz o download de artefatos que foram criados como resultado da execução de ações. Dessa forma, a largura de banda da rede pode afetar o desempenho do build.

Se você estiver usando a execução remota para suas builds, monitore o tráfego de rede durante a invocação usando o proto NetworkMetrics.SystemNetworkStats do BEP (requer a transmissão de --experimental_collect_system_network_usage).

Além disso, os perfis de rastreamento JSON permitem visualizar o uso da rede em todo o sistema durante o build transmitindo a sinalização --experimental_collect_system_network_usage (nova no Bazel 6.0).

Figura 3. Perfil que inclui o uso da rede em todo o sistema.

Um uso de rede alto, mas bastante simples, ao usar a execução remota pode indicar que a rede é o gargalo no build. Se você ainda não estiver usando ela, considere ativar o build sem os bytes transmitindo --remote_download_minimal. Isso acelera seus builds, evitando o download de artefatos intermediários desnecessários.

Outra opção é configurar um cache de disco local para economizar na largura de banda de download.