O Bazel é complexo e faz muitas coisas diferentes ao longo de um build, algumas das quais podem afetar o desempenho. Nesta página, tentamos mapear alguns desses conceitos do Bazel e suas implicações na performance da build. Embora não seja extensa, incluímos alguns exemplos de como detectar problemas de desempenho de build extraindo métricas e o que você pode fazer para corrigi-los. Assim, esperamos que você possa aplicar esses conceitos ao investigar regressões de desempenho de build.
Builds limpos x incrementais
Um build limpo cria tudo do zero, enquanto um build incremental reutiliza alguns trabalhos já concluídos.
Sugerimos analisar builds limpos e incrementais separadamente, principalmente ao coletar / agregar métricas que dependem do estado dos caches do Bazel (por exemplo, métricas de tamanho da solicitação de build). Eles também representam duas experiências de usuário diferentes. Em comparação com o início de 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 (normalmente mais rápido, já que 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 categorizar de forma geral como um build incremental. O usuário pode ter mudado para flags ou destinos diferentes, causando um build efetivamente limpo. Qualquer definição mais rigorosa de incrementalidade provavelmente terá que vir na forma de uma heurística, por exemplo, analisando o número de pacotes carregados (PackageMetrics.packages_loaded).
Métricas de build determinísticas como um proxy para o desempenho do build
Medir o desempenho da build pode ser difícil devido à natureza não determinística de certas métricas, por exemplo, o tempo de CPU do Bazel ou os tempos de fila em um cluster remoto. Por isso, é útil usar métricas determinísticas como um proxy para a quantidade de trabalho feita pelo Bazel, o que afeta a performance dele.
O tamanho de uma solicitação de build pode ter uma implicação significativa no desempenho do build. Um build maior pode representar mais trabalho na análise e construção dos gráficos de build. O crescimento orgânico dos builds acontece naturalmente com o desenvolvimento, à medida que mais dependências são adicionadas/criadas e, portanto, aumentam em complexidade e ficam mais caras para serem criadas.
Podemos dividir esse problema nas várias fases de build e usar as seguintes métricas como proxy para o trabalho realizado em cada fase:
PackageMetrics.packages_loaded: o número de pacotes carregados com sucesso. Uma regressão aqui representa mais trabalho que precisa ser feito para ler e analisar cada arquivo BUILD adicional na fase de carregamento.TargetMetrics.targets_configured: representando o número de destinos e aspectos configurados no build. Uma regressão representa mais trabalho na construção e no percurso do gráfico de destino configurado.- Isso geralmente acontece devido à adição de dependências e à necessidade de construir o gráfico do fechamento transitivo delas.
- Use cquery para encontrar onde novas dependências podem ter sido adicionadas.
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=summaryantes de detalhar mais com--skyframe_state.
- Use aquery para depurar regressões. Sugerimos começar com
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
ActionDataque mostram os tipos de ação mais executados. Por padrão, ele coleta os 20 principais tipos de ação, mas você pode transmitir--experimental_record_metrics_for_all_mnemonicspara coletar esses dados de todos os tipos de ação executados. - Isso vai ajudar você a descobrir que tipo de ações foram executadas (além disso).
- O BEP grava as estatísticas de ação
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 uma implementação de 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.
Notamos que uma regressão em qualquer uma dessas métricas pode ser acompanhada por regressões no tempo real, no tempo de CPU e no uso de memória.
Uso de recursos locais
O Bazel consome vários recursos na sua máquina local (tanto para analisar o gráfico de build e conduzir a execução quanto para executar ações locais). Isso pode afetar o desempenho / disponibilidade da máquina ao realizar o build e outras tarefas.
Tempo gasto
Talvez as métricas mais suscetíveis a ruídos (e que podem variar muito de build para build) sejam tempo, em especial, tempo real, tempo de CPU e tempo de sistema. Você pode usar o bazel-bench para receber um comparativo dessas métricas e, com um número suficiente de --runs, aumentar a significância estatística da sua medição.
O tempo real é o tempo decorrido no mundo real.
- Se apenas o tempo real regredir, recomendamos coletar um perfil de rastreamento JSON e procurar diferenças. Caso contrário, provavelmente seria mais eficiente investigar outras métricas de regressão, já que elas podem ter afetado o tempo real.
Tempo de CPU é o tempo gasto pela CPU executando o código do usuário.
- Se o tempo de CPU regredir em dois commits de projeto, recomendamos coletar um perfil de CPU do Starlark. Também é recomendável usar
--nobuildpara restringir o build à fase de análise, já que é nela que a maior parte do trabalho pesado da CPU é feita.
- Se o tempo de CPU regredir em dois commits de projeto, recomendamos coletar um perfil de CPU do Starlark. Também é recomendável usar
O tempo do sistema é o tempo gasto pela CPU no kernel.
- Se o tempo do sistema regredir, isso estará correlacionado principalmente com E/S quando o Bazel ler arquivos do seu sistema de arquivos.
Criação de perfis de carga em todo o sistema
Usando a flag
--experimental_collect_load_average_in_profiler
introduzida no Bazel 6.0, o
criador de perfil de rastreamento 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 indicar que ele programa muitas ações locais em paralelo para sua máquina. Talvez seja necessário ajustar --local_cpu_resources e --local_ram_resources, principalmente em ambientes de contêineres (pelo menos até que #16512 seja mesclado).
Como monitorar o uso de memória do Bazel
Há duas fontes principais para saber o uso de memória do Bazel: o Bazel info e o
BEP.
bazel info used-heap-size-after-gc: a quantidade de memória usada em bytes após uma chamada paraSystem.gc().- O Bazel bench também fornece comparativos de mercado para essa métrica.
- Além disso, há
peak-heap-size,max-heap-size,used-heap-sizeecommitted-heap-size(consulte a documentação), mas são menos relevantes.
BEP’s
MemoryMetrics.peak_post_gc_heap_size: tamanho do pico do heap da JVM em bytes após a coleta de lixo (requer a definição de--memory_profileque tenta forçar uma coleta de lixo 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 são causadas pela adição de dependências ou uma mudança na implementação da regra.
Para analisar o uso de memória do Bazel em um nível mais granular, recomendamos usar o profiler de memória integrado para regras.
Criação de perfil de memória de workers persistentes
Embora os workers persistentes possam ajudar a acelerar os builds
significativamente (especialmente para linguagens interpretadas), o consumo de memória deles pode
ser problemático. O Bazel coleta métricas sobre os workers. Em particular, o campo
WorkerMetrics.WorkerStats.worker_memory_in_kb informa quanta memória
os workers usam (por mnemônico).
O criador de perfil de rastreamento JSON também coleta o uso de memória do worker persistente durante a invocação transmitindo a flag --experimental_collect_system_network_usage (nova no Bazel 6.0).
Figura 2. Perfil que inclui o uso da memória pelos workers.
Diminuir o valor de
--worker_max_instances
(padrão 4) pode ajudar a reduzir
a quantidade de memória usada por workers persistentes. Estamos trabalhando para tornar o gerenciador de recursos e o programador do Bazel mais inteligentes. Assim, esse ajuste fino será necessário com menos frequência no futuro.
Monitorar o tráfego de rede para builds remotos
Na execução remota, o Bazel faz o download de artefatos criados como resultado da execução de ações. Por isso, a largura de banda da sua rede pode afetar o desempenho do build.
Se você estiver usando a execução remota para seus builds, considere monitorar o tráfego de rede durante a invocação usando o proto NetworkMetrics.SystemNetworkStats do BEP (exige 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 processo de build transmitindo a flag --experimental_collect_system_network_usage (novidade no Bazel 6.0).
Figura 3. Perfil que inclui o uso da rede em todo o sistema.
Um uso de rede alto, mas relativamente estável, ao usar a execução remota pode indicar que a rede é o gargalo no seu build. Se você ainda não estiver usando, considere ativar o Build without the Bytes transmitindo --remote_download_minimal.
Isso acelera os builds, evitando o download de artefatos intermediários desnecessários.
Outra opção é configurar um cache de disco local para economizar largura de banda de download.