En esta página, se describe cómo verificar el porcentaje de aciertos de la caché y cómo investigar los errores de caché en el contexto de la ejecución remota.
En esta página, se supone que tienes una compilación o prueba que usa correctamente la ejecución remota y que deseas asegurarte de usar de manera eficaz la caché remota.
Cómo verificar la tasa de aciertos de la caché
En el resultado estándar de la ejecución de Bazel, observa la línea INFO
que enumera los procesos, que corresponden aproximadamente a las acciones de Bazel. Esa línea detalla dónde se ejecutó la acción. Busca la etiqueta remote
, que indica una acción ejecutada de forma remota, linux-sandbox
para las acciones ejecutadas en una zona de pruebas local y otros valores para otras estrategias de ejecución. Una acción cuyo resultado provino de una caché remota se muestra como remote cache hit
.
Por ejemplo:
INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.
En este ejemplo, hubo 6 aciertos de caché remota y 2 acciones no tenían
aciertos de caché y se ejecutaron de forma remota. Se puede ignorar la 3ª parte interna.
Por lo general, son acciones internas diminutas, como la creación de vínculos simbólicos. Los aciertos de caché local no se incluyen en este resumen. Si obtienes 0 procesos (o un número menor al esperado), ejecuta bazel clean
seguido de tu comando de compilación o prueba.
Soluciona problemas de aciertos de caché
Si no obtienes la tasa de aciertos de la caché que esperas, haz lo siguiente:
Asegúrate de volver a ejecutar el mismo comando de compilación o prueba que produzca aciertos de caché
Ejecuta las compilaciones o pruebas que esperas que propaguen la caché. La primera vez que se ejecuta una compilación nueva en una pila en particular, no se esperan hits de caché remotos. Como parte de la ejecución remota, los resultados de las acciones se almacenan en la caché, y una ejecución posterior debería recuperarlos.
Ejecuta
bazel clean
. Este comando limpia tu caché local, lo que te permite investigar los aciertos de caché remota sin que los resultados se enmasquen por los aciertos de caché local.Ejecuta las compilaciones y las pruebas que estés investigando de nuevo (en la misma máquina).
Revisa la línea
INFO
para ver la tasa de aciertos de caché. Si no ves ningún proceso, exceptoremote cache hit
yinternal
, significa que se está completando y accediendo a la caché correctamente. En ese caso, pasa a la siguiente sección.Una probable fuente de discrepancia es algo no hermético en la compilación que hace que las acciones reciban diferentes teclas de acción en las dos ejecuciones. Para encontrar esas acciones, haz lo siguiente:
a. Vuelve a ejecutar las compilaciones o pruebas en cuestión para obtener los registros de ejecución:
bazel clean
bazel --optional-flags build //your:target --execution_log_compact_file=/tmp/exec1.log
b. Compara los registros de ejecución entre las dos ejecuciones. Asegúrate de que las acciones sean idénticas en los dos archivos de registro. Las discrepancias proporcionan una pista sobre los cambios que se produjeron entre las ejecuciones. Actualiza tu compilación para eliminar esas discrepancias.
Si puedes resolver los problemas de almacenamiento en caché y la ejecución repetida produce todos los hits de caché, ve a la siguiente sección.
Si los IDs de acción son idénticos, pero no hay hits de caché, significa que algo en tu configuración impide la creación de caché. Continúa con esta sección para verificar si hay problemas habituales.
Comprueba que todas las acciones del registro de ejecución tengan
cacheable
establecido como verdadero. Sicacheable
no aparece en el registro de ejecución de una acción determinada, significa que la regla correspondiente puede tener una etiquetano-cache
en su definición en el archivoBUILD
. Observa los camposmnemonic
ytarget_label
en el registro de ejecución para determinar de dónde proviene la acción.Si las acciones son idénticas y
cacheable
, pero no hay coincidencias en la caché, es posible que tu línea de comandos incluya--noremote_accept_cached
, lo que inhabilitaría las búsquedas en la caché para una compilación.Si es difícil descubrir la línea de comandos real, usa la línea de comandos canónica del protocolo de eventos de compilación de la siguiente manera:
a. Agrega
--build_event_text_file=/tmp/bep.txt
a tu comando de Bazel para obtener la versión de texto del registro.b. Abre la versión de texto del registro y busca el mensaje
structured_command_line
concommand_line_label: "canonical"
. Aparecerá una lista con todas las opciones después de la expansión.c. Busca
remote_accept_cached
y verifica si está configurado comofalse
.d. Si
remote_accept_cached
esfalse
, determina dónde se configura comofalse
: en la línea de comandos o en un archivo bazelrc.
Garantizar el almacenamiento en caché en las máquinas
Después de que los hits de caché se produzcan como se espera en la misma máquina, ejecuta las mismas compilaciones o pruebas en una máquina diferente. Si sospechas que la caché no se está realizando en todas las máquinas, haz lo siguiente:
Haz una pequeña modificación en tu compilación para evitar que se carguen las cachés existentes.
Ejecuta la compilación en la primera máquina:
bazel clean
bazel ... build ... --execution_log_compact_file=/tmp/exec1.log
Ejecuta la compilación en la segunda máquina y asegúrate de que se incluya la modificación del paso 1:
bazel clean
bazel ... build ... --execution_log_compact_file=/tmp/exec2.log
Compara los registros de ejecución de las dos ejecuciones. Si los registros no son idénticos, investiga la configuración de tu compilación en busca de discrepancias, así como las propiedades del entorno de host que se filtren en cualquiera de las compilaciones.
Compara los registros de ejecución
El registro de ejecución contiene registros de acciones ejecutadas durante la compilación. Cada registro describe las entradas (no solo los archivos, sino también los argumentos de línea de comandos, las variables de entorno, etc.) y los resultados de la acción. Por lo tanto, el examen del registro puede revelar por qué se volvió a ejecutar una acción.
El registro de ejecución se puede generar en uno de los siguientes tres formatos: compact (--execution_log_compact_file
), binario (--execution_log_binary_file
) o JSON (--execution_log_json_file
). Se recomienda el formato compacto, ya que produce archivos mucho más pequeños con una sobrecarga de tiempo de ejecución muy pequeña. Las siguientes instrucciones funcionan para cualquier formato. También puedes convertir entre ellos con la herramienta //src/tools/execlog:converter
.
Para comparar los registros de dos compilaciones que no comparten los hits de caché como se espera, haz lo siguiente:
Obtén los registros de ejecución de cada compilación y almacénalos como
/tmp/exec1.log
y/tmp/exec2.log
.Descarga el código fuente de Bazel y compila la herramienta
//src/tools/execlog:parser
:git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser
Usa la herramienta
//src/tools/execlog:parser
para convertir los registros en un formato de texto legible. En este formato, las acciones del segundo registro se ordenan para que coincidan con el orden del primer registro, lo que facilita la comparación.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
Usa la diferencia de texto que prefieras para diferenciar
/tmp/exec1.log.txt
y/tmp/exec2.log.txt
.