Nesta página, descrevemos como verificar a taxa de ocorrência em cache e como investigar ausências no cache no contexto de execução remota.
Nesta página, presumimos que você tem uma versão e/ou teste que utiliza a execução remota com êxito e quer garantir que está usando o cache remoto de maneira eficaz.
Como verificar a taxa de ocorrência em cache
Na saída padrão da execução do Bazel, observe a linha INFO
que lista
os processos, que correspondem aproximadamente às ações do Bazel. Essa linha detalha
onde a ação foi executada. Procure o rótulo remote
, que indica uma ação
executada remotamente, linux-sandbox
para ações executadas em um sandbox local
e outros valores para outras estratégias de execução. Uma ação com resultado proveniente de um cache remoto é exibida como remote cache hit
.
Exemplo:
INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.
Nesse exemplo, houve 6 ocorrências em cache remoto e duas ações não tiveram ocorrências em cache e foram executadas remotamente. A parte interna 3 pode ser ignorada.
Normalmente são pequenas ações internas, como a criação de links simbólicos. As ocorrências em cache local não estão incluídas nesse resumo. Se você não estiver recebendo processos
(ou um número menor do que o esperado), execute bazel clean
seguido pelo comando
de build/teste.
Solução de problemas de ocorrências em cache
Se você não estiver recebendo a taxa de ocorrência em cache esperada, faça o seguinte:
Verifique se a nova execução do mesmo comando de build/teste produz ocorrências em cache
Execute os builds e/ou testes que você quer que preencham o cache. Na primeira vez que uma nova versão é executada em uma pilha específica, não é esperada nenhuma ocorrência em cache remoto. Como parte da execução remota, os resultados da ação são armazenados no cache e uma execução subsequente os seleciona.
Execute
bazel clean
. Esse comando limpa seu cache local, o que permite investigar ocorrências em cache remoto sem que os resultados sejam mascarados por ocorrências em cache local.Execute as compilações e os testes que você está investigando novamente (na mesma máquina).
Verifique a linha
INFO
para a taxa de ocorrência em cache. Se não forem exibidos processos, excetoremote cache hit
einternal
, significa que o cache está sendo preenchido e acessado corretamente. Nesse caso, pule para a próxima seção.Uma provável fonte de discrepância é algo não hermético na versão, fazendo com que as ações recebam chaves de ação diferentes nas duas execuções. Para encontrar essas ações, faça o seguinte:
a. Execute novamente os builds ou testes em questão para acessar os registros de execução:
bazel clean
bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
b. Compare os registros de execução entre as duas execuções. Verifique se as ações são idênticas nos dois arquivos de registro. As discrepâncias dão uma dica sobre as mudanças que ocorreram entre as execuções. Atualize seu build para eliminar essas discrepâncias.
Se você conseguir resolver os problemas de armazenamento em cache e agora a execução repetida produzir todas as ocorrências em cache, pule para a próxima seção.
Se os IDs de ação forem idênticos, mas não houver ocorrências em cache, algo na sua configuração está impedindo o armazenamento em cache. Continue com esta seção para verificar se há problemas comuns.
Verifique se todas as ações no registro de execução têm
cacheable
definido como verdadeiro. Secacheable
não aparecer no registro de execução de uma determinada ação, significa que a regra correspondente pode ter uma tagno-cache
na definição no arquivoBUILD
. Observe os camposmnemonic
etarget_label
no registro de execução para ajudar a determinar a origem da ação.Se as ações forem idênticas e
cacheable
, mas não houver ocorrências em cache, é possível que a linha de comando inclua--noremote_accept_cached
, que desativaria as pesquisas de cache para uma build.Se for difícil descobrir a linha de comando real, use a linha de comando canônica do Build Event Protocol, da seguinte maneira:
a. Adicione
--build_event_text_file=/tmp/bep.txt
ao seu comando Bazel para receber a versão em texto do registro.b. Abra a versão em texto do registro e procure a mensagem
structured_command_line
comcommand_line_label: "canonical"
. Todas as opções serão listadas após a expansão.c) Pesquise
remote_accept_cached
e verifique se ele está definido comofalse
.d) Se
remote_accept_cached
forfalse
, determine onde ele está sendo definido comofalse
: na linha de comando ou em um arquivo bazelrc.
Garanta o armazenamento em cache entre as máquinas
Depois que as ocorrências em cache estiverem acontecendo como esperado na mesma máquina, execute os mesmos builds/testes em uma máquina diferente. Se você suspeita que o armazenamento em cache não está acontecendo entre as máquinas, faça o seguinte:
Faça uma pequena modificação no build para evitar atingir os caches atuais.
Execute o build na primeira máquina:
bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec1.log
Execute o build na segunda máquina, garantindo que a modificação da etapa 1 esteja incluída:
bazel clean
bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
Compare os registros de execução das duas execuções. Se os registros não forem idênticos, verifique se há discrepâncias nas configurações do build, bem como as propriedades do ambiente do host que vazam para um dos builds.
Como comparar os registros de execução
Os registros de execução contêm todas as ações executadas durante o build. Para cada ação, há um elemento SpawnExec com todas as informações da chave de ação. Assim, se os registros forem idênticos, as chaves de cache de ação também serão.
Para comparar registros de duas builds que não estão compartilhando ocorrências em cache como esperado, faça o seguinte:
Acesse os registros de execução de cada build e armazene-os como
/tmp/exec1.log
e/tmp/exec2.log
.Faça o download do código-fonte do Bazel e vá para a pasta do Bazel usando o comando abaixo. Você precisa do código-fonte para analisar os registros de execução com o analisador de execlog.
git clone https://github.com/bazelbuild/bazel.git cd bazel
Usar o analisador de registros de execução para converter os registros em texto. A invocação a seguir também classifica as ações no segundo registro para corresponder à ordem das ações no primeiro registro para facilitar a comparação.
bazel build src/tools/execlog:parser bazel-bin/src/tools/execlog/parser \ --log_path=/tmp/exec1.log \ --log_path=/tmp/exec2.log \ --output_path=/tmp/exec1.log.txt \ --output_path=/tmp/exec2.log.txt
Use seu texto favorito para diferenciar
/tmp/exec1.log.txt
e/tmp/exec2.log.txt
.