La ejecución dinámica es una función de Bazel desde la versión 0.21, en la que se inicia en paralelo la ejecución local y remota de la misma acción, con el resultado de la primera rama que finaliza y se cancela la otra rama. Combina la potencia de ejecución o la gran caché compartida de un sistema de compilación remoto con la baja latencia de la ejecución local, lo que proporciona lo mejor de ambos mundos para compilaciones incrementales y limpias.
En esta página, se describe cómo habilitar, ajustar y depurar la ejecución dinámica. Si tienes configurada la ejecución local y remota y estás tratando de ajustar la configuración de Bazel para obtener un mejor rendimiento, esta página es para ti. Si aún no tienes configurada la ejecución remota, primero ve a la Descripción general de la ejecución remota de Bazel.
¿Habilitaste la ejecución dinámica?
El módulo de ejecución dinámica es parte de Bazel, pero para usar la ejecución diagnóstica, ya debes poder compilar de forma local y remota desde la misma configuración de Bazel.
Para habilitar el módulo de ejecución dinámica, pasa la marca --internal_spawn_scheduler a Bazel. Esto agrega una nueva estrategia de ejecución llamada dynamic. Ahora puedes
usar esto como estrategia para las mnemotecnias que deseas ejecutar de forma dinámica, como
--strategy=Javac=dynamic. Consulta la siguiente sección para saber cómo elegir para qué mnemotecnias habilitar la ejecución dinámica.
Para cualquier mnemónico que use la estrategia dinámica, las estrategias de ejecución remota se toman de la marca --dynamic_remote_strategy y las estrategias locales de la marca --dynamic_local_strategy. Pasar --dynamic_local_strategy=worker,sandboxed establece el valor predeterminado para la rama local de la ejecución dinámica para probar con trabajadores o ejecución en zona de pruebas en ese orden. Pasar --dynamic_local_strategy=Javac=worker anula el valor predeterminado solo para la mnemónica de Javac. La versión remota funciona de la misma manera. Ambas marcas se pueden especificar varias veces. Si una acción no se puede ejecutar de forma local, se ejecuta de forma remota como de costumbre y viceversa.
Si tu sistema remoto tiene una caché, la marca --local_execution_delay
añade una demora en milisegundos a la ejecución local después de que el sistema remoto
haya indicado un acierto de caché. De esta manera, se evita ejecutar la ejecución local cuando es probable que haya más hits de caché. El valor predeterminado es de 1,000 ms, pero se debe ajustar para que sea un poco más largo que el tiempo que suelen tardar los aciertos de caché. El tiempo real depende del sistema remoto y de la duración de un viaje de ida y vuelta. Por lo general, el valor será el
mismo para todos los usuarios de un sistema remoto determinado, a menos que algunos de ellos estén lo
suficientemente lejos como para agregar latencia de ida y vuelta. Puedes usar las
funciones de generación de perfiles de Bazel
para ver cuánto tiempo tardan los hits de caché típicos.
La ejecución dinámica se puede usar con la estrategia de zona de pruebas local y con
trabajadores persistentes. Los trabajadores persistentes se ejecutarán automáticamente con zona de pruebas cuando se usen con ejecución dinámica y no pueden usar trabajadores multiplexados. En los sistemas Darwin y Windows, la estrategia de zona de pruebas puede ser lenta. Puedes pasar --reuse_sandbox_directories para reducir la sobrecarga de crear zonas de pruebas en estos sistemas.
La ejecución dinámica también se puede ejecutar con la estrategia standalone, aunque, como esta estrategia debe tomar el bloqueo de salida cuando comienza a ejecutarse, bloquea de manera eficaz que la estrategia remota termine primero.standalone La marca --experimental_local_lockfree_output permite evitar este problema, ya que permite que la ejecución local escriba directamente en el resultado, pero que la ejecución remota la cancele si esta termina primero.
Si una de las ramas de la ejecución dinámica termina primero, pero falla, falla toda la acción. Esta es una opción intencional para evitar que pasen desapercibidas las diferencias entre la ejecución local y la remota.
Para obtener más información sobre cómo funcionan la ejecución dinámica y su bloqueo, consulta las excelentes entradas de blog de Julio Merino.
¿Cuándo debo usar la ejecución dinámica?
La ejecución dinámica requiere algún tipo de sistema de ejecución remota. Actualmente, no es posible usar un sistema remoto solo de caché, ya que una omisión de caché se consideraría una acción fallida.
No todos los tipos de acciones son adecuados para la ejecución remota. Los mejores candidatos son aquellos que son, de forma inherente, más rápidos de forma local, por ejemplo, a través del uso de trabajadores persistentes, o aquellos que se ejecutan lo suficientemente rápido como para que la sobrecarga de la ejecución remota domine el tiempo de ejecución. Dado que cada acción ejecutada de forma local bloquea una cantidad de recursos de CPU y memoria, ejecutar acciones que no se encuentran en esas categorías solo retrasa la ejecución de las que sí lo hacen.
A partir de la versión 5.0.0-pre.20210708.4, la generación de perfiles de rendimiento contiene datos sobre la ejecución de los trabajadores, incluido el tiempo dedicado a finalizar una solicitud de trabajo después de perder una carrera de ejecución dinámica. Si ves que los subprocesos de trabajo de ejecución dinámica dedican tiempo significativo a adquirir recursos o a pasar mucho tiempo en async-worker-finish, es posible que tengas algunas acciones locales lentas que retrasan los subprocesos de trabajo.
En el perfil anterior, que usa 8 trabajadores de Javac, vemos que muchos trabajadores de Javac perdieron las carreras y terminaron su trabajo en los subprocesos async-worker-finish. Esto se debió a que una mnemotecnia que no es de trabajador tomó suficientes recursos para retrasar a los trabajadores.
Cuando solo se ejecuta Javac con ejecución dinámica, solo la mitad de los trabajadores iniciados terminan perdiendo la carrera después de iniciar su trabajo.
La marca --experimental_spawn_scheduler recomendada anteriormente dejó de estar disponible.
Activa la ejecución dinámica y establece dynamic como la estrategia predeterminada para todas las mnemotecnias, lo que suele generar este tipo de problemas.
Solución de problemas
Los problemas con la ejecución dinámica pueden ser sutiles y difíciles de depurar, ya que solo se pueden manifestar en algunas combinaciones específicas de ejecución local y remota.
--debug_spawn_scheduler agrega una salida adicional del sistema de ejecución dinámico que puede ayudar a depurar estos problemas. También puedes ajustar la marca --local_execution_delay y la cantidad de trabajos remotos en comparación con los locales para facilitar la reproducción de los problemas.
Si tienes problemas con la ejecución dinámica con la estrategia standalone, intenta ejecutar sin --experimental_local_lockfree_output o ejecuta tus acciones locales en la zona de pruebas. Esto puede ralentizar un poco la compilación (consulta lo anterior si usas Mac o Windows), pero quita algunas posibles causas de fallas.