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. Ele combina o poder de execução e/ou o grande cache compartilhado de um servidor com a baixa latência da execução local, oferecendo o melhor de ambos para builds limpos e incrementais.
Esta página descreve como ativar, ajustar e depurar a execução dinâmica. Se você com a execução local e remota configuradas e tentando ajustar o Bazel configurações para melhorar o desempenho, esta página é para você. Se você ainda não tiver configuração da execução remota, acesse o arquivo Visão geral da execução remota primeiro.
Ativar a execução dinâmica?
O módulo de execução dinâmica faz parte do Bazel, mas para usar o você já deve ser capaz de compilar local e remotamente a mesma configuração do Bazel.
Para ativar o módulo de execução dinâmica, transmita o --internal_spawn_scheduler
para o Bazel. Isso adiciona uma nova estratégia de execução chamada dynamic. Agora você pode
use isso como estratégia para as mnemônicas que você quer executar dinamicamente, como
--strategy=Javac=dynamic: Confira a próxima seção para saber como escolher quais mnemônicas
ativar a execução dinâmica.
Para qualquer mnemônica que use a estratégia dinâmica, as estratégias de execução remota são
retirado da sinalização --dynamic_remote_strategy e as estratégias locais do
sinalização --dynamic_local_strategy. Em aprovação
--dynamic_local_strategy=worker,sandboxed define o padrão para o
de execução dinâmica para testar com workers ou execução em sandbox
ordem. A transmissão de --dynamic_local_strategy=Javac=worker substitui o padrão
somente mnemônico do Javac. A versão remota funciona da mesma maneira. As duas sinalizações podem
ser especificado várias vezes. Se uma ação não pode ser executada localmente, ela
executada remotamente como de costume e vice-versa.
Se o sistema remoto tiver um cache, o --local_execution_delay
adiciona um atraso em milissegundos à execução local após o sistema remoto
indicou uma ocorrência em cache. Isso evita a execução local quando há mais caches
a probabilidade de hits. O valor padrão é 1.000 ms, mas deve ser ajustado para ser apenas
um pouco mais do que as ocorrências em cache costumam levar. O tempo real depende
sistema remoto e a duração de uma ida e volta. Normalmente, o valor será
o mesmo para todos os usuários de um determinado sistema remoto, a menos que alguns deles tenham distância suficiente
para aumentar a latência de ida e volta. Você pode usar o
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 permanentes. Os workers persistentes vão
são executadas automaticamente com sandbox quando usadas com a execução dinâmica e não podem
usam workers multiplex. Nos sistemas Darwin e Windows,
a estratégia de sandbox pode ser lenta, é possível transmitir
--reuse_sandbox_directories para reduzir a sobrecarga da criação de sandboxes nesses sistemas.
A execução dinâmica também pode ser realizada com a estratégia standalone, já que o
A estratégia standalone precisa usar o bloqueio de saída quando começar a ser executada,
impede que a estratégia remota termine primeiro. O
A flag --experimental_local_lockfree_output possibilita uma solução com esse problema:
permitindo que a execução local grave diretamente na saída, mas seja cancelada pelo
a execução remota, se isso terminar primeiro.
Se uma das ramificações da execução dinâmica terminar primeiro, mas falhar, o toda a ação falhar. Essa é uma escolha intencional para evitar diferenças entre a execução local e remota passe despercebida.
Para mais informações sobre como a execução dinâmica e o bloqueio funcionam, consulte Julio A excelente do Merino postagens do blog
Quando devo usar a execução dinâmica?
A execução dinâmica requer alguma forma sistema de execução remota. No momento, não é possível usar um sistema remoto somente 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 naturalmente mais rápidos localmente, por exemplo, através o uso de workers permanentes ou aqueles que executam rápido o suficiente para que o overhead da execução remota domine o tempo de execução. Como cada ação executada localmente bloqueia parte da CPU e da memória executar ações que não se enquadrem nessas categorias apenas atrasa e a execução para quem tem.
Na versão
5.0.0-pre.20210708.4,
criação de perfis de performance
contém dados sobre a execução do worker, incluindo o tempo gasto para concluir um trabalho
após perder uma corrida de execução dinâmica. Se houver execução dinâmica
linhas de execução de workers que passam muito tempo adquirindo recursos
no async-worker-finish, algumas ações locais lentas podem atrasar a
linhas de execução de worker.
No perfil acima, que usa oito workers Javac, vemos muitos workers Javac
depois de perder as corridas e terminar o trabalho na async-worker-finish
fios Isso foi causado por uma mnemônica não relacionada ao trabalho consumindo recursos suficientes para
atrasam os workers.
Quando apenas Javac é executado com execução dinâmica, apenas cerca da metade do tempo iniciado trabalhadores acabam 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
mnemônicas, o que geralmente levaria a esse tipo de problema.
Solução de problemas
Problemas com a execução dinâmica podem ser sutis e difíceis de depurar, pois podem
apenas sob algumas combinações específicas de execução local e remota.
O --debug_spawn_scheduler adiciona uma saída extra da classe
que pode ajudar a depurar esses problemas. Também é possível ajustar
Sinalização --local_execution_delay e número de jobs remotos x locais
para facilitar a reprodução dos problemas.
Se você tiver problemas com a execução dinâmica usando o standalone
estratégia, 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
está usando um Mac ou Windows), mas remove algumas possíveis causas de falhas.