Depuración de hits de caché remota para ejecución remota

Informar un problema Ver fuente . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

En esta página, se describe cómo verificar la tasa de aciertos de caché y cómo investigarla errores de caché en el contexto de ejecución remota.

En esta página, se da por sentado que tienes una compilación o prueba que utiliza la ejecución remota, y quieres asegurarte de que estás con el almacenamiento en caché remoto.

Verifica la tasa de aciertos de caché

En el resultado estándar de tu ejecución de Bazel, observa la línea INFO que enumera que corresponden, a grandes rasgos, a las acciones de Bazel. Los detalles de esa línea dónde se ejecutó la acción. Busca la etiqueta remote, que indica una acción. ejecutado de forma remota, linux-sandbox para acciones ejecutadas en una zona de pruebas local, y otros valores para otras estrategias de ejecución. Una acción cuyo resultado se obtuvo 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. La 3 parte interna se puede ignorar. Por lo general, se trata de acciones internas muy pequeñas, como la creación de vínculos simbólicos. Locales los aciertos de caché no se incluyen en este resumen. Si no obtienes ningún proceso (o un número inferior al esperado), ejecuta bazel clean seguido de tu compilación o prueba. kubectl.

Solución de problemas de aciertos de caché

Si no obtienes la tasa de aciertos de caché que esperabas, haz lo siguiente:

Asegúrate de volver a ejecutar el mismo comando de compilación o prueba que produzca aciertos de caché

  1. Ejecuta las compilaciones o pruebas que esperas que propaguen la caché. El primera vez que se ejecuta una nueva compilación en una pila en particular, no se puede esperar aciertos de caché. Como parte de la ejecución remota, los resultados de acciones se almacenan en la y una ejecución posterior debería recogerlos.

  2. Ejecuta bazel clean. Este comando limpia tu caché local, lo que permite te permite investigar los aciertos de caché remota sin que los resultados se oculten aciertos de caché local.

  3. Ejecuta las compilaciones y las pruebas que investigas nuevamente (en el mismo máquina).

  4. Revisa la línea INFO para ver la tasa de aciertos de caché. Si no ves ningún proceso, excepto remote cache hit y internal, la caché se está propagando correctamente. a las que se accede. En ese caso, pasa a la siguiente sección.

  5. Una probable fuente de discrepancia es algo no hermético en la compilación las acciones para recibir diferentes teclas de acción en las dos ejecuciones. Para buscar 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_binary_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 brindan una pista sobre los cambios que ocurrieron entre o en cualquier plataforma que ejecute Knative. Actualiza tu compilación para eliminar esas discrepancias.

    Si puedes resolver los problemas de almacenamiento en caché y ahora la ejecución repetida produce todos los aciertos de caché, pasa a la siguiente sección.

    Si tus IDs de acción son idénticos, pero no hay aciertos de caché, es posible que algo de tu configuración impide el almacenamiento en caché. Continúa con esta sección para comprueba si hay problemas comunes.

    Si no necesitas diferenciar los registros de ejecución, puedes usar el legible por humanos --execution_log_json_file. No se puede se usa para el diffing estable, ya que contiene el tiempo de ejecución y no que garantiza un orden de garantía.

  6. Comprueba que todas las acciones del registro de ejecución tengan cacheable establecido como verdadero. Si cacheable no aparece en el registro de ejecución para una acción proporcionada, que significa que la regla correspondiente puede tener una etiqueta no-cache en su en el archivo BUILD. Observa el objeto progress_message legible por humanos en el registro de ejecución para ayudar a determinar de dónde proviene la acción.

  7. Si las acciones son idénticas y cacheable, pero no hay aciertos de caché, es posible que tu línea de comandos incluya --noremote_accept_cached, que inhabilitaría las búsquedas en caché para una compilación.

    Si descubrir la línea de comandos real es difícil, usa la canónica desde la línea de comandos 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 structured_command_line mensaje con command_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á establecido en false.

    d. Si remote_accept_cached es false, determina dónde se encuentra. configurado en false, ya sea en la línea de comandos o en una bazelrc.

Garantizar el almacenamiento en caché entre máquinas

Una vez que los aciertos de caché ocurran en la misma máquina como se espera, ejecuta el comando las mismas compilaciones o pruebas en otra máquina. Si sospechas que el almacenamiento en caché que no se realice en distintas máquinas, haz lo siguiente:

  1. Realiza una pequeña modificación en tu compilación para evitar que llegue a las cachés existentes.

  2. Ejecuta la compilación en la primera máquina:

     bazel clean
     bazel ... build ... --execution_log_binary_file=/tmp/exec1.log
    
  3. Ejecuta la compilación en la segunda máquina y asegúrate de realizar la modificación del paso 1. se incluye:

     bazel clean
     bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
    
  4. Compara los registros de ejecución de los dos tipos o en cualquier plataforma que ejecute Knative. Si los registros no son idénticos, investiga tus configuraciones de compilación para detectar discrepancias y filtraciones de propiedades del entorno del host en cualquiera de las compilaciones.

Compara los registros de ejecución

Los registros de ejecución contienen registros de todas las acciones ejecutadas durante la compilación. Para cada acción hay un SpawnExec que contiene toda la información de la clave de acción. Por lo tanto, si la son idénticos, entonces también lo son las claves de caché de acciones.

Para comparar los registros de dos compilaciones que no comparten los aciertos de caché como se espera, haz lo siguiente: haz lo siguiente:

  1. Obtén los registros de ejecución de cada compilación y almacénalos como /tmp/exec1.log. /tmp/exec2.log

  2. Descarga el código fuente de Bazel y navega a la carpeta de Bazel usando el siguiente comando. Necesitas el código fuente para analizar los registros de ejecución con el analizador de execlog.

    git clone https://github.com/bazelbuild/bazel.git
    cd bazel
    
  3. Usa el analizador de registros de ejecución para convertir los registros en texto. Lo siguiente invocación también ordena las acciones del segundo registro para que coincidan con el orden en el primer registro para facilitar la comparación.

    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
    
  4. Utiliza la diferencia de texto de tu preferencia para diferenciar /tmp/exec1.log.txt y /tmp/exec2.log.txt