Bazel es complejo y realiza muchas acciones diferentes a lo largo de una compilación, algunas de las cuales pueden afectar el rendimiento de la compilación. En esta página, se intenta asignar algunos de estos conceptos de Bazel a sus implicaciones en el rendimiento de la compilación. Si bien no son extensos, incluimos algunos ejemplos de cómo detectar problemas de rendimiento de la compilación a través de la extracción de métricas y lo que puedes hacer para solucionarlos. Con esto, esperamos que puedas aplicar estos conceptos cuando investigues las regresiones de rendimiento de la compilación.
Comparación entre compilaciones limpias e incrementales
Una compilación limpia es aquella que compila todo desde cero, mientras que una compilación incremental reutiliza parte del trabajo ya completado.
Te sugerimos que analices las compilaciones limpias y las incrementales por separado, en especial cuando recopiles o agregues métricas que dependen del estado de las cachés de Bazel (por ejemplo, métricas de tamaño de la solicitud de compilación). También representan dos experiencias del usuario diferentes. En comparación con el inicio de una compilación limpia desde cero (que demora más debido a una caché fría), las compilaciones incrementales ocurren con mucha más frecuencia a medida que los desarrolladores iteran en el código (por lo general, son más rápidas, ya que la caché suele estar ya activada).
Puedes usar el campo CumulativeMetrics.num_analyses en el BEP para clasificar compilaciones. Si es num_analyses <= 1, es una compilación limpia. De lo contrario, podemos categorizarla de forma general como una compilación incremental, ya que el usuario podría haber cambiado a diferentes marcas o objetivos, lo que provocaría una compilación limpia. Es probable que cualquier definición más rigurosa de la incrementalidad deba presentarse en forma de heurística, por ejemplo, observando la cantidad de paquetes cargados (PackageMetrics.packages_loaded).
Métricas de compilación deterministas como proxy del rendimiento de la compilación
Medir el rendimiento de la compilación puede ser difícil debido a la naturaleza no determinista de ciertas métricas (por ejemplo, el tiempo de CPU de Bazel o los tiempos de cola en un clúster remoto). Por lo tanto, puede ser útil usar métricas deterministas como proxy para la cantidad de trabajo que realiza Bazel, lo que, a su vez, afecta su rendimiento.
El tamaño de una solicitud de compilación puede tener una implicación significativa en el rendimiento de la compilación. Una compilación más grande podría representar más trabajo en el análisis y la construcción de los gráficos de compilación. El crecimiento orgánico de las compilaciones se produce de forma natural con el desarrollo, a medida que se agregan o crean más dependencias, y, por lo tanto, aumenta la complejidad y se vuelve más costoso compilarlas.
Podemos dividir este problema en las diferentes fases de compilación y usar las siguientes métricas como métricas de proxy para el trabajo realizado en cada fase:
PackageMetrics.packages_loaded: Es la cantidad de paquetes cargados correctamente. Una regresión aquí representa más trabajo que se debe realizar para leer y analizar cada archivo BUILD adicional en la fase de carga.TargetMetrics.targets_configured: Representa la cantidad de destinos y aspectos configurados en la compilación. Una regresión representa más trabajo en la construcción y el recorrido del grafo de destino configurado.- Esto suele deberse a la adición de dependencias y a tener que construir el gráfico de su cierre transitivo.
- Usa cquery para encontrar dónde se podrían haber agregado dependencias nuevas.
ActionSummary.actions_created: Representa las acciones creadas en la compilación, y una regresión representa más trabajo en la construcción del gráfico de acciones. Ten en cuenta que esto también incluye acciones sin usar que podrían no haberse ejecutado.- Usa aquery para depurar regresiones. Te sugerimos que comiences con
--output=summaryantes de desglosar más con--skyframe_state.
- Usa aquery para depurar regresiones. Te sugerimos que comiences con
ActionSummary.actions_executed: La cantidad de acciones ejecutadas. Una regresión representa directamente más trabajo en la ejecución de estas acciones.- El BEP escribe las estadísticas de acciones
ActionDataque muestran los tipos de acciones más ejecutados. De forma predeterminada, recopila los 20 tipos de acciones principales, pero puedes pasar el--experimental_record_metrics_for_all_mnemonicspara recopilar estos datos para todos los tipos de acciones que se ejecutaron. - Esto debería ayudarte a descubrir qué tipo de acciones se ejecutaron (además).
- El BEP escribe las estadísticas de acciones
BuildGraphSummary.outputArtifactCount: Es la cantidad de artefactos que crean las acciones ejecutadas.- Si la cantidad de acciones ejecutadas no aumentó, es probable que se haya modificado una implementación de reglas.
Todas estas métricas se ven afectadas por el estado de la caché local, por lo que debes asegurarte de que las compilaciones de las que extraes estas métricas sean compilaciones limpias.
Notamos que una regresión en cualquiera de estas métricas puede ir acompañada de regresiones en el tiempo de ejecución, el tiempo de CPU y el uso de memoria.
Uso de recursos locales
Bazel consume una variedad de recursos en tu máquina local (tanto para analizar el gráfico de compilación y dirigir la ejecución como para ejecutar acciones locales). Esto puede afectar el rendimiento o la disponibilidad de tu máquina para realizar la compilación y otras tareas.
Tiempo transcurrido
Quizás las métricas más susceptibles al ruido (y que pueden variar mucho de una compilación a otra) sean el tiempo, en particular, el tiempo de ejecución, el tiempo de la CPU y el tiempo del sistema. Puedes usar bazel-bench para obtener una comparativa de estas métricas y, con una cantidad suficiente de --runs, puedes aumentar la importancia estadística de tu medición.
El tiempo real es el tiempo real transcurrido.
- Si solo el tiempo de ejecución retrocede, te sugerimos que recopiles un perfil de seguimiento JSON y busques diferencias. De lo contrario, es probable que sea más eficiente investigar otras métricas con regresión, ya que podrían haber afectado el tiempo de espera.
El tiempo de CPU es el tiempo que la CPU dedica a ejecutar el código del usuario.
- Si el tiempo de CPU retrocede en dos confirmaciones de proyecto, te sugerimos que recopiles un perfil de CPU de Starlark. Es probable que también debas usar
--nobuildpara restringir la compilación a la fase de análisis, ya que es allí donde se realiza la mayor parte del trabajo intensivo de la CPU.
- Si el tiempo de CPU retrocede en dos confirmaciones de proyecto, te sugerimos que recopiles un perfil de CPU de Starlark. Es probable que también debas usar
El tiempo del sistema es el tiempo que la CPU dedica al kernel.
- Si el tiempo del sistema retrocede, se correlaciona principalmente con la E/S cuando Bazel lee archivos de tu sistema de archivos.
Generación de perfiles de carga en todo el sistema
Con la marca --experimental_collect_load_average_in_profiler que se introdujo en Bazel 6.0, el generador de perfiles de seguimiento JSON recopila la carga promedio del sistema durante la invocación.
Figura 1: Es un perfil que incluye la carga promedio del sistema.
Una carga alta durante una invocación de Bazel puede ser un indicador de que Bazel programa demasiados acciones locales en paralelo para tu máquina. Te recomendamos que ajustes --local_cpu_resources y --local_ram_resources, en especial en entornos de contenedores (al menos hasta que se combine #16512).
Cómo supervisar el uso de memoria de Bazel
Hay dos fuentes principales para obtener el uso de memoria de Bazel: Bazel info y el BEP.
bazel info used-heap-size-after-gc: Es la cantidad de memoria utilizada en bytes después de una llamada aSystem.gc().- Bazel bench también proporciona comparativas para esta métrica.
- Además, existen
peak-heap-size,max-heap-size,used-heap-sizeycommitted-heap-size(consulta la documentación), pero son menos relevantes.
MemoryMetrics.peak_post_gc_heap_sizede BEP: Es el tamaño del montón máximo de JVM en bytes después de la GC (requiere la configuración de--memory_profileque intenta forzar una GC completa).
Por lo general, una regresión en el uso de la memoria es el resultado de una regresión en las métricas de tamaño de la solicitud de compilación, que a menudo se debe a la adición de dependencias o a un cambio en la implementación de la regla.
Para analizar el espacio en memoria de Bazel en un nivel más detallado, te recomendamos que uses el generador de perfiles de memoria integrado para las reglas.
Generación de perfiles de memoria de los trabajadores persistentes
Si bien los trabajadores persistentes pueden ayudar a acelerar las compilaciones de manera significativa (especialmente para los lenguajes interpretados), su huella de memoria puede ser problemática. Bazel recopila métricas sobre sus trabajadores, en particular, el campo WorkerMetrics.WorkerStats.worker_memory_in_kb indica cuánta memoria usan los trabajadores (por mnemotecnia).
El generador de perfiles de seguimiento de JSON también recopila el uso persistente de la memoria del trabajador durante la invocación pasando la marca --experimental_collect_system_network_usage (nueva en Bazel 6.0).
Figura 2: Perfil que incluye el uso de memoria de los trabajadores.
Reducir el valor de
--worker_max_instances
(4 predeterminado) podría ayudar a reducir
la cantidad de memoria que usan los trabajadores persistentes. Estamos trabajando de forma activa para que el administrador de recursos y el programador de Bazel sean más inteligentes, de modo que se requiera menos ajuste fino en el futuro.
Cómo supervisar el tráfico de red para compilaciones remotas
En la ejecución remota, Bazel descarga los artefactos que se compilaron como resultado de ejecutar acciones. Por lo tanto, el ancho de banda de tu red puede afectar el rendimiento de tu compilación.
Si usas la ejecución remota para tus compilaciones, te recomendamos que supervises
el tráfico de red durante la invocación con el proto NetworkMetrics.SystemNetworkStats del BEP
(requiere pasar --experimental_collect_system_network_usage).
Además, los perfiles de seguimiento de JSON te permiten ver el uso de la red en todo el sistema durante el transcurso de la compilación pasando la marca --experimental_collect_system_network_usage (nueva en Bazel 6.0).
Figura 3: Es un perfil que incluye el uso de red en todo el sistema.
Un uso alto, pero bastante plano, de la red cuando se usa la ejecución remota podría indicar que la red es el cuello de botella de tu compilación. Si aún no lo usas, considera activar la compilación sin los bytes pasando --remote_download_minimal.
Esto acelerará tus compilaciones, ya que evitará la descarga de artefactos intermedios innecesarios.
Otra opción es configurar una caché de disco local para ahorrar ancho de banda de descarga.