La ejecución dinámica es una función de Bazel a partir de la versión 0.21, en la que la ejecución local y remota de la misma acción se inicia en paralelo mediante el resultado de la primera rama que finaliza y cancela la otra rama. Combina la potencia de ejecución o la gran caché compartida de un sistema de compilación remota con la baja latencia de la ejecución local, lo que proporciona lo mejor de ambos mundos para compilaciones incrementales y limpias por igual.
En esta página, se describe cómo habilitar, ajustar y depurar la ejecución dinámica. Si configuraste la ejecución local y remota, y tratas 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.
¿Quieres habilitar la ejecución dinámica?
El módulo de ejecución dinámica es parte de Bazel, pero para usar la ejecución dinámica, 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 estrategia de ejecución nueva llamada dynamic. Ahora puedes usarla como estrategia para los mnemónicos que deseas ejecutar de forma dinámica, por ejemplo, --strategy=Javac=dynamic. Consulta la siguiente sección a fin de saber cómo elegir para qué mnemónicos
se habilitará la ejecución dinámica.
En el caso de cualquier mnemotécnica que usa 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 de la rama
local de ejecución dinámica para probar con los trabajadores o la ejecución de zona de pruebas en ese
orden. Pasar --dynamic_local_strategy=Javac=worker anula el valor predeterminado solo para el valor mnemotécnico 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 con normalidad y viceversa.
Si tu sistema remoto tiene una caché, la marca --local_execution_delay
agrega un retraso en milisegundos a la ejecución local después de que el sistema remoto
indica un acierto de caché. De esta manera, se evita ejecutar una ejecución local cuando es probable que haya más aciertos de caché. El valor predeterminado es de 1,000 ms, pero se debe ajustar para que sea solo un poco más largo que el que suelen tardar los aciertos de caché. El tiempo real depende tanto del sistema remoto como del tiempo 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 creación de perfiles de Bazel para ver cuánto tardan los aciertos de caché típicos.
La ejecución dinámica se puede usar con una 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 multiplex. En los sistemas de 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 la estrategia standalone debe tomar el bloqueo de salida cuando comienza a ejecutarse, bloquea de forma efectiva la estrategia remota para que no finalice primero. La
marca --experimental_local_lockfree_output permite solucionar este problema, ya que permite que la ejecución local escriba directamente en el resultado, pero que la anule
la ejecución remota si eso finaliza primero.
Si una de las ramas de la ejecución dinámica finaliza primero, pero falla, toda la acción falla. Esta es una elección intencional para evitar que las diferencias entre la ejecución local y remota pasen desapercibidas.
Para obtener más información sobre el funcionamiento de 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. Por el momento, no es posible usar un sistema remoto solo de caché, ya que un error de caché se consideraría una acción con errores.
No todos los tipos de acciones son adecuados para la ejecución remota. Los mejores candidatos son aquellos que son más rápidos de manera inherente a nivel local, por ejemplo, mediante el 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 cierta cantidad de recursos de CPU y memoria, ejecutar acciones que no entran en esas categorías solo retrasa la ejecución de aquellas 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 trabajadores, incluido el tiempo dedicado a finalizar una solicitud de trabajo después de perder una carrera de ejecución dinámica. Si observas que los subprocesos de trabajo de ejecución dinámica dedican una gran cantidad de tiempo a adquirir recursos, o bien que pasan mucho tiempo en async-worker-finish, es posible que haya algunas acciones locales lentas que demoren los subprocesos de trabajo.
En el perfil anterior, que usa 8 trabajadores de Javac, vemos que muchos trabajadores de Javac perdieron las carreras y finalizaron su trabajo en los subprocesos async-worker-finish. Esto se debe a que un sistema mnemotécnico no trabajador que toma suficientes recursos para demorar a los trabajadores.
Cuando solo se ejecuta Javac con ejecución dinámica, solo aproximadamente la mitad de los trabajadores iniciados pierde la carrera después de comenzar 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 todos los mnemónicos, lo que a menudo generaría 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 pueden manifestarse con 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 o locales para facilitar la reproducción de los problemas.
Si tienes problemas con la ejecución dinámica con la estrategia standalone,
intenta ejecutarlo sin --experimental_local_lockfree_output o ejecuta
la zona de pruebas de acciones locales. Esto puede ralentizar un poco tu compilación (consulta más arriba si usas Mac o Windows), pero quita algunas causas posibles de fallas.