A execução dinâmica é um recurso no 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. Ele combina a potência de execução e/ou o grande cache compartilhado de um sistema de compilação remota com a baixa latência da execução local, oferecendo o melhor dos mundos para builds limpos e incrementais.
Esta página descreve como ativar, ajustar e depurar a execução dinâmica. Se você tiver as execuções 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 primeiro a Visão geral da execução remota do Bazel.
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 compilar local e remotamente a mesma configuração do Bazel.
Para ativar o módulo de execução dinâmica, transmita a sinalização --internal_spawn_scheduler
para o Bazel. Isso adiciona uma nova estratégia de execução chamada dynamic. Agora é possível
usar isso como sua estratégia para as mneumônicas que você quer executar dinamicamente, como
--strategy=Javac=dynamic. Consulte a próxima seção para saber como escolher para quais mnemônicas
ativar a execução dinâmica.
Para qualquer mnemônico que usa a estratégia dinâmica, as estratégias de execução remota são extraídas da sinalização --dynamic_remote_strategy e as estratégias locais da sinalização --dynamic_local_strategy. Transmitir
--dynamic_local_strategy=worker,sandboxed define o padrão para a ramificação
local da execução dinâmica testar com workers ou a execução em sandbox,
nessa ordem. Transmitir --dynamic_local_strategy=Javac=worker substitui o padrão somente para
mnemônicos Javac. A versão remota funciona da mesma forma. As duas sinalizações podem
ser especificadas várias vezes. Se uma ação não puder ser executada localmente, ela será
executada remotamente, como de costume, e vice-versa.
Se o sistema remoto tiver um cache, a flag --local_execution_delay
vai adicionar um atraso em milissegundos à execução local depois que o sistema remoto
indicar uma ocorrência em cache. Isso evita executar a execução local quando houver mais ocorrências em cache. O valor padrão é 1.000 ms, mas é necessário ajustar para ser um pouco mais longo do que as ocorrências em cache geralmente levam. O tempo real depende tanto do
sistema remoto quanto da duração de uma viagem de ida e volta. 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. Use os
recursos de criação de perfil do Bazel
para ver quanto tempo as ocorrências em cache típicas levam.
A execução dinâmica pode ser usada com a estratégia de sandbox local, bem como com
workers persistentes. Os workers persistentes são
executados automaticamente com o sandbox quando usados com a execução dinâmica e não podem
usar workers de multiplex. Nos sistemas Darwin e Windows,
a estratégia no modo 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. No entanto, como a
estratégia standalone precisa receber o bloqueio de saída quando começa a ser executada, ela
bloqueia efetivamente a estratégia remota de terminar primeiro. A sinalização --experimental_local_lockfree_output apresenta uma maneira de contornar esse problema, permitindo que a execução local grave diretamente na saída, mas seja cancelada pela execução remota, caso isso termine primeiro.
Se uma das ramificações da execução dinâmica terminar primeiro, mas for uma falha, toda a ação falhará. Essa é uma escolha intencional para evitar que as diferenças entre as execuções local e remota passem despercebidas.
Para mais informações sobre como a execução dinâmica e o bloqueio dela funcionam, consulte as excelentes postagens do blog (em inglês) de Julio Merino.
Quando devo usar a execução dinâmica?
A execução dinâmica requer alguma forma de sistema de execução remota. Atualmente, não é possível usar um sistema remoto apenas em cache, já que uma ausência no 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, com o uso de trabalhadores persistentes, ou aqueles que são executados rápido o suficiente para que a sobrecarga da execução remota domine o tempo de execução. Como cada ação executada localmente bloqueia uma quantidade de recursos de CPU e memória, a execução de ações que não se enquadram nessas categorias só atrasa a execução das demais.
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ê perceber que as linhas de execução
de workers de execução dinâmica passam um tempo significativo adquirindo recursos ou muito tempo
no async-worker-finish, pode haver algumas ações locais lentas que atrasam as
linhas de execução do worker.
No perfil acima, que usa oito workers Javac, muitos workers Javac
perderam as corridas e concluem o trabalho nas linhas de execução
async-worker-finish. Isso foi causado por um mnemônico que não é do worker tomando recursos suficientes para
atrasar os workers.
Quando apenas Javac é executado com execução dinâmica, apenas cerca de metade dos workers iniciados acaba perdendo a corrida depois de iniciar o trabalho.
A sinalização --experimental_spawn_scheduler recomendada anteriormente foi descontinuada.
Ela ativa a execução dinâmica e define dynamic como a estratégia padrão para todas
as mneumônicas, 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 só podem
se manifestar sob 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. Também é possível ajustar a
flag --local_execution_delay e o número de jobs remotos e locais
para facilitar a reprodução dos problemas.
Se você tiver problemas com a execução dinâmica usando a estratégia standalone,
tente executar sem --experimental_local_lockfree_output ou execute
suas ações locais no sandbox. Isso pode deixar seu build um pouco mais lento (confira acima se
você estiver no Mac ou Windows), mas remove algumas causas possíveis para falhas.