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

Informar um problema Mostrar fonte Por noite · 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ê tem um build e/ou teste que usa a execução remota, e você quer garantir que as 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. Ação com um resultado que de um cache remoto é exibida como remote cache hit.

Exemplo:

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

Neste exemplo, houve 6 ocorrências em cache remoto e duas ações não tiveram de 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. Local as ocorrências em cache não são incluídas nesse resumo. Se não houver processos (ou um número menor do que o esperado), execute bazel clean seguido pelo build/teste kubectl.

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. A primeira vez que um novo build é executado em uma pilha específica, não é esperado nenhum de ocorrências em cache. Como parte da execução remota, os resultados da ação são armazenados no no cache e uma execução subsequente vai buscá-los.
Execute bazel clean. Esse comando limpa o cache local, permitindo investigar ocorrências em cache remoto sem que os resultados sejam mascarados ocorrências em cache local.
Execute os builds e os testes que você está investigando novamente (no mesmo máquina virtual.
Verifique a linha INFO para 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 provável fonte de discrepância é algo não hermético na versão que causa as ações para receber 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 fornecem uma pista sobre as mudanças que ocorreram entre as é executado. 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 ocorrências em cache, na sua configuração está impedindo o armazenamento em cache. Continue nesta seção para e a verificação de problemas comuns.

Se não for preciso diferenciar registros de execução, use o a sinalização --execution_log_json_file legível por humanos. Ele não pode ser usada para diferenciação estável, já que contém tempo de execução e não tem garantir a ordenação.
Verifique se todas as ações no registro de execução têm cacheable definido como verdadeiro. Se cacheable não aparece no registro de execução de uma ação específica, que significa que a regra correspondente pode ter uma tag no-cache na no arquivo BUILD. Confira o progress_message legível por humanos 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, ela é possível que sua linha de comando inclua --noremote_accept_cached, que desativaria as pesquisas de cache para um build.

Se for difícil descobrir a linha de comando, use a na linha de comando Protocolo de evento de build da seguinte forma:

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 o 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.

Garanta o armazenamento em cache entre as máquinas

Depois que as ocorrências em cache ocorrerem como esperado na mesma máquina, execute o os mesmos builds/testes em outra máquina. Se você suspeita que o armazenamento em cache não acontecer 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

Executar o build na segunda máquina, garantindo a modificação da etapa 1 está incluído:
```
 bazel clean
 bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
```
Compare os registros de execução dos dois é executado. 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.

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 existe uma SpawnExec que contém todas as informações da tecla de ação. Assim, se o os registros são idênticos, então as chaves de cache de ação também são.

Para comparar registros de dois 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. /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 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. O seguinte invocação 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.