La ejecución dinámica es una función de Bazel desde la versión 0.21 en la que la ejecución local y remota de la misma acción se inician en paralelo usando el resultado de la primera rama que finaliza y cancela la otra . Combina la potencia de ejecución o la gran caché compartida de un recurso remoto de compilación con la baja latencia de la ejecución local, lo que proporciona lo mejor de ambos mundos para compilaciones limpias e incrementales por igual.
En esta página, se describe cómo habilitar, ajustar y depurar la ejecución dinámica. Si tienen configurada la ejecución local y remota e intentan ajustar Bazel para lograr un mejor rendimiento, esta página es para ti. Si aún no tienes configuración de la ejecución remota, ve a Bazel Descripción general de la ejecución remota primero.
¿Quieres habilitar la ejecución dinámica?
El módulo de ejecución dinámica es parte de Bazel, pero para usar ya debes poder compilar de forma local y remota con la misma configuración de Bazel.
Para habilitar el módulo de ejecución dinámica, pasa --internal_spawn_scheduler.
a Bazel. Esto agrega una nueva estrategia de ejecución llamada dynamic. Ahora puedes
use esto como su estrategia para los mnemónicos que desea ejecutar dinámicamente, como
--strategy=Javac=dynamic Consulta la siguiente sección para saber cómo elegir los mnemónicos
para habilitar la ejecución dinámica.
Para cualquier mnemotécnico que usa la estrategia dinámica, las estrategias de ejecución remota
tomado de la marca --dynamic_remote_strategy, y las estrategias locales de la
--dynamic_local_strategy. Aprobación
--dynamic_local_strategy=worker,sandboxed establece el valor predeterminado de la configuración
de ejecución dinámica para probar con trabajadores o la ejecución de zona de pruebas
en el orden personalizado. Pasar --dynamic_local_strategy=Javac=worker anula el valor predeterminado para
solo el nombre nemotécnico Javac. La versión remota funciona de la misma manera. Ambas marcas pueden
especificar varias veces. Si una acción no se puede ejecutar localmente, es
se ejecuten de forma remota como de costumbre, y viceversa.
Si tu sistema remoto tiene una caché, --local_execution_delay
agrega un retraso en milisegundos a la ejecución local después de que el sistema
indicó un acierto de caché. Esto evita la ejecución local cuando hay más caché
es probable que tengan más éxito. El valor predeterminado es 1000 ms, pero se debe ajustar para que sea solo
un poco más de lo que suelen tardar los aciertos de caché. El tiempo real depende tanto del
en un sistema remoto
y el tiempo de ida y vuelta. Por lo general, el valor será
para todos los usuarios de un determinado sistema remoto, a menos que algunos de ellos
para agregar latencia de ida y vuelta. Puedes usar la
Funciones de generación de perfiles de Bazel
para determinar cuánto tardan los aciertos típicos de caché.
La ejecución dinámica se puede usar con la estrategia de zona de pruebas local y con
trabajadores persistentes. Los trabajadores persistentes
se ejecuta automáticamente con la zona de pruebas cuando se usa con la ejecución dinámica y no puede
usar trabajadores multiplex. En los sistemas Darwin y Windows,
la estrategia de espacio aislado
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 puede ejecutarse con la estrategia standalone, aunque, como
La estrategia standalone debe tomar el bloqueo de salida cuando comienza a ejecutarse.
bloquea eficazmente la estrategia remota para que no finalice primero. El
La marca --experimental_local_lockfree_output permite evitar este problema
lo que permite que la ejecución local escriba directamente en la salida, pero que la anule
y la ejecución remota, si esto debería terminar primero.
Si una de las ramas de la ejecución dinámica termina primero, pero es una falla, el falla toda la acción. Esta es una elección deliberada para evitar diferencias entre la ejecución local y remota.
Para obtener más información sobre cómo funciona la ejecución dinámica y su bloqueo, consulta Julio. Excelente entradas de blog
¿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 está es posible usar un sistema remoto que solo use caché, ya que se consideraría un error de caché una acción errónea.
No todos los tipos de acciones son adecuados para la ejecución remota. Los mejores candidatos son los que son inherentemente más rápidos a nivel local, por ejemplo, a través de el uso de trabajadores persistentes o aquellos que se ejecutan lo suficientemente rápido para que la sobrecarga de la ejecución remota domine el tiempo de ejecución. Dado que cada acción ejecutada localmente bloquea una cantidad de CPU y memoria recursos, ejecutar acciones que no pertenecen a esas categorías simplemente retrasa ejecución para aquellos que sí lo hacen.
Desde el lanzamiento
5.0.0-pre.20210708.4,
generación de perfiles de rendimiento
Contiene datos sobre la ejecución del trabajador, incluido el tiempo dedicado a finalizar un trabajo.
después de perder una carrera de ejecución dinámica. Si ves la ejecución dinámica
subprocesos de trabajo que pasan mucho tiempo adquiriendo recursos o mucho tiempo
en async-worker-finish, es posible que tengas algunas acciones locales lentas que retrasen la
subprocesos de trabajo.
En el perfil anterior, que usa 8 trabajadores Javac, vemos muchos trabajadores Javac.
perdieron las carreras y terminaron su trabajo en el async-worker-finish
conversaciones. Esto se debe a que un mnemotécnico no trabajador
que tomó suficientes recursos para
retrasar a los trabajadores.
Cuando solo se ejecuta Javac con ejecución dinámica, solo cerca de la mitad de terminan perdiendo la carrera después de comenzar su trabajo.
La marca --experimental_spawn_scheduler recomendada anteriormente dejó de estar disponible.
Se activa la ejecución dinámica y se establece dynamic como la estrategia predeterminada para todos.
mnemotécnicas que a menudo
daría lugar a este tipo de problemas.
Soluciona problemas
Los problemas con la ejecución dinámica pueden ser sutiles y difíciles de depurar, ya que pueden
el manifiesto solo con algunas combinaciones específicas de ejecución local y remota.
El elemento --debug_spawn_scheduler agrega resultados adicionales de la actividad
de ejecución que puede ayudar a depurar estos problemas. También puedes ajustar el
Marca de --local_execution_delay y cantidad de trabajos remotos y locales
para facilitar la reproducción de los problemas.
Si tienes problemas con la ejecución dinámica con standalone
prueba correr sin --experimental_local_lockfree_output o ejecuta
tu zona de pruebas de acciones locales. Esto puede ralentizar un poco la compilación (consulta la sección anterior si
está en Mac o Windows), pero quita algunas de las posibles causas de errores.