Como depurar ocorrências em cache remoto para execução remota

Informar um problema Ver a fonte Nightly · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Esta página descreve como verificar a taxa de ocorrência em cache e como investigar as ausências de cache no contexto de execução remota.

Esta página pressupõe que você tenha um build e/ou teste que utilize a execução remota e que você queira garantir que está usando o cache remoto.

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 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 executados remotamente, linux-sandbox para ações executadas em sandbox local e outros valores para outras estratégias de execução. Uma ação cujo resultado veio de um cache remoto é exibida como remote cache hit.

Exemplo:

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

Neste exemplo, houve seis hits de cache remoto, e duas ações não tiveram hits de cache e foram executadas remotamente. A terceira parte interna pode ser ignorada. Normalmente são pequenas ações internas, como a criação de links simbólicos. Local as ocorrências em cache não são incluídas nesse resumo. Se você receber 0 processos (ou um número menor do que o esperado), execute bazel clean seguido do comando de build/teste.

Solução de problemas de ocorrências em cache

Se você não estiver recebendo a taxa de acertos de 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ê espera que preencham o cache. Na primeira vez que um novo build é executado em uma pilha específica, não há acertos de cache remoto. Como parte da execução remota, os resultados da ação são armazenados no cache, e uma execução subsequente precisa coletá-los.
Execute bazel clean. Esse comando limpa o cache local, o que permite investigar ocorrências de cache remoto sem que os resultados sejam mascarados por ocorrências de cache local.
Execute as compilações e os testes que você está investigando novamente (na mesma máquina).
Verifique a linha INFO para conferir a taxa de ocorrência em cache. Se não houver processos, exceto remote cache hit e internal, isso significa que seu cache está sendo preenchido corretamente e acessados. Nesse caso, pule para a próxima seção.
Uma possível fonte de discrepância é algo não hermético no build que faz 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_compact_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 fornecem uma pista sobre as mudanças que ocorreram entre as execuções. Atualize seu build para eliminar essas discrepâncias.

Se você puder resolver os problemas de armazenamento em cache e executar a execução repetida produz 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 correspondências de cache, algo na configuração está impedindo o armazenamento em cache. Continue nesta seção para verificar problemas comuns.
Verifique se todas as ações no registro de execução têm cacheable definido como verdadeiro. Se cacheable não aparecer no registro de execução de uma determinada ação, isso significa que a regra correspondente pode ter uma tag no-cache na definição no arquivo BUILD. Analise os campos mnemonic e target_label no registro de execução para determinar de onde a ação está vendo.
Se as ações forem idênticas e cacheable, mas não houver acertos de cache, é possível que a linha de comando inclua --noremote_accept_cached, o que desativaria as pesquisas de cache para um 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 pelo structured_command_line mensagem com command_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 como false.

d. Se remote_accept_cached for false, determine onde ele está sendo definido como false: na linha de comando ou em uma arquivo bazelrc.

Garantir o armazenamento em cache em várias máquinas

Depois que as ocorrências em cache estiverem acontecendo na mesma máquina como esperado, execute o os mesmos builds/testes em outra máquina. Se você suspeitar que o armazenamento em cache não está acontecendo em todas 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_compact_file=/tmp/exec1.log

Execute o build na segunda máquina, garantindo que a modificação da etapa 1 seja incluída:
```
 bazel clean
 bazel ... build ... --execution_log_compact_file=/tmp/exec2.log
```
Compare os registros de execução das duas execuções. Se os registros não forem idênticos, investigue suas configurações de build para discrepâncias e propriedades do ambiente do host com vazamento a qualquer um dos builds.

Comparar os registros de execução

O registro "Execution" (Execução) contém registros de ações executadas durante o build. Cada registro descreve ambas as entradas (não apenas arquivos, mas também argumentos, variáveis de ambiente etc.) e as saídas da ação. Assim, do registro pode revelar por que uma ação foi executada novamente.

O registro de execução pode ser produzido em um dos três formatos: compacto (--execution_log_compact_file), binário (--execution_log_binary_file) ou JSON (--execution_log_json_file). O formato compacto é recomendado, pois produz arquivos muito menores com o overhead do ambiente de execução. As instruções a seguir funcionam para qualquer formato. Também é possível converter entre eles usando a ferramenta //src/tools/execlog:converter.

Para comparar os registros de dois builds que não estão compartilhando acertos de cache como esperado, faça o seguinte:

Receba os registros de execução de cada build e os armazene como /tmp/exec1.log e /tmp/exec2.log.
Faça o download do código-fonte do Bazel e crie a ferramenta //src/tools/execlog:parser:

git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser
Use a ferramenta //src/tools/execlog:parser para converter os registros em um formato de texto legível por humanos. Nesse formato, as ações no segundo registro são classificados para corresponder à ordem do primeiro registro, facilitando a comparação.
```
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 preferido para comparar /tmp/exec1.log.txt e /tmp/exec2.log.txt.