A execução dinâmica é um recurso do Bazel desde a versão 0.21, em que a execução local e remota da mesma ação são iniciadas em paralelo, usando a saída da primeira ramificação que termina, cancelando a outra ramificação. Ela combina o poder de execução e/ou o grande cache compartilhado de um sistema de build remoto com a baixa latência da execução local, oferecendo o melhor dos dois mundos para builds limpos e incrementais.
Esta página descreve como ativar, ajustar e depurar a execução dinâmica. Se você tiver a execução local e remota configuradas e estiver tentando ajustar as configurações do Bazel para melhorar o desempenho, esta página é para você. Se você ainda não configurou a execução remota, acesse a Visão geral da execução remota do Bazel primeiro.
Como ativar a execução dinâmica?
O módulo de execução dinâmica faz parte do Bazel, mas, para usar a execução dinâmica , você já precisa conseguir compilar local e remotamente na mesma configuração do Bazel.
Para ativar o módulo de execução dinâmica, transmita a --internal_spawn_scheduler
flag para o Bazel. Isso adiciona uma nova estratégia de execução chamada dynamic. Agora você pode
usar essa estratégia para os mnemônicos que quer executar dinamicamente, como
--strategy=Javac=dynamic. Consulte a próxima seção para saber como escolher os mnemônicos
para ativar a execução dinâmica.
Para qualquer mnemônico que use a estratégia dinâmica, as estratégias de execução remota são
extraídas da flag --dynamic_remote_strategy e as estratégias locais da
--dynamic_local_strategy flag. A transmissão de
--dynamic_local_strategy=worker,sandboxed define o padrão para a ramificação local da execução dinâmica para tentar com workers ou execução em sandbox nessa
ordem. A transmissão de --dynamic_local_strategy=Javac=worker substitui o padrão para
o mnemônico Javac apenas. A versão remota funciona da mesma maneira. As duas flags podem
ser especificadas várias vezes. Se uma ação não puder ser executada localmente, ela será
executada remotamente como normal e vice-versa.
Se o sistema remoto tiver um cache, a --local_execution_delay
flag vai adicionar um atraso em milissegundos à execução local depois que o sistema remoto
indicar um acerto de cache. Isso evita a execução local quando é mais provável que haja mais acertos de cache. O valor padrão é de 1.000 ms, mas precisa ser ajustado para ser apenas
um pouco maior do que os acertos de cache normalmente levam. O tempo real depende do
sistema remoto e de quanto tempo uma viagem de ida e volta leva. Normalmente, o valor será o
mesmo para todos os usuários de um determinado sistema remoto, a menos que alguns deles estejam longe o suficiente
para adicionar latência de ida e volta. Você pode usar os
recursos de criação de perfil do Bazel
para conferir quanto tempo os acertos de cache típicos levam.
A execução dinâmica pode ser usada com a estratégia de sandbox local e com
workers persistentes. Os workers persistentes serão
executados automaticamente com o sandbox quando usados com a execução dinâmica e não poderão
usar workers multiplexados. Em sistemas Darwin e Windows,
a estratégia de sandbox pode ser lenta. Você pode transmitir
--reuse_sandbox_directories para reduzir a sobrecarga da criação de sandboxes nesses sistemas.
A execução dinâmica também pode ser executada com a estratégia standalone, embora, como a estratégia
standalone precise usar o bloqueio de saída quando começa a ser executada, ela
efetivamente impede que a estratégia remota termine primeiro. A flag
--experimental_local_lockfree_output permite contornar esse problema, permitindo que a execução local grave diretamente na saída, mas seja interrompida pela execução remota, caso ela termine primeiro.
Se uma das ramificações da execução dinâmica terminar primeiro, mas for uma falha, a ação inteira falhará. Essa é uma escolha intencional para evitar que diferenças entre a execução local e remota passem despercebidas.
Para mais informações sobre como a execução dinâmica e o bloqueio funcionam, consulte as excelentes postagens do blog de Julio Merino (links em inglês).
Quando devo usar a execução dinâmica?
A execução dinâmica requer alguma forma de sistema de execução remota. No momento, não é possível usar um sistema remoto somente de cache, já que uma falha de cache seria considerada uma ação com falha.
Nem todos os tipos de ações são adequados para execução remota. Os melhores candidatos são aqueles que são inerentemente mais rápidos localmente, por exemplo, usando o uso de workers persistentes, ou aqueles que são executados com rapidez suficiente para que a sobrecarga da execução remota domine o tempo de execução. Como cada ação executada localmente bloqueia uma certa quantidade de recursos de CPU e memória, a execução de ações que não se enquadram nessas categorias apenas atrasa a execução daquelas que se enquadram.
A partir da versão
5.0.0-pre.20210708.4,
a criação de perfil de desempenho
contém dados sobre a execução do worker, incluindo o tempo gasto para concluir uma solicitação de trabalho
após perder uma corrida de execução dinâmica. Se você notar que as linhas de execução do worker de execução dinâmica
gastam muito tempo adquirindo recursos ou muito tempo
no async-worker-finish, talvez você tenha algumas ações locais lentas atrasando as
linhas de execução do worker.
No perfil acima, que usa oito workers Javac, vemos muitos workers Javac
que perderam as corridas e terminaram o trabalho nas async-worker-finish
linhas de execução. Isso foi causado por um mnemônico não worker que consumiu recursos suficientes para
atrasar os workers.
Quando apenas o Javac é executado com execução dinâmica, apenas cerca de metade dos workers iniciados acabam perdendo a corrida após iniciar o trabalho.
A flag --experimental_spawn_scheduler recomendada anteriormente foi descontinuada.
Ela ativa a execução dinâmica e define dynamic como a estratégia padrão para todos os
mnemônicos, o que geralmente leva a esses tipos de problemas.
Solução de problemas
Os problemas com a execução dinâmica podem ser sutis e difíceis de depurar, já que podem
se manifestar apenas em algumas combinações específicas de execução local e remota.
O --debug_spawn_scheduler adiciona uma saída extra do sistema de execução dinâmica
que pode ajudar a depurar esses problemas. Você também pode ajustar a
--local_execution_delay flag e o número de jobs remotos e locais
para facilitar a reprodução dos problemas.
Se você estiver com problemas na execução dinâmica usando a standalone
estratégia, tente executar sem --experimental_local_lockfree_output ou execute
as ações locais em sandbox. Isso pode deixar seu build um pouco mais lento (consulte acima se
você estiver no Mac ou Windows), mas remove algumas possíveis causas de falhas.