动态执行

报告问题 查看源代码

动态执行0.21 版之后 Bazel 中的一项功能,该功能支持在本地和远程并行启动同一操作,使用完成的第一个分支的输出,取消另一个分支。它将远程构建系统的执行能力和/或大型共享缓存与本地执行的低延迟相结合,从而在整洁构建和增量构建中各有优势。

本页介绍了如何启用、调整和调试动态执行。如果您同时设置了本地和远程执行,并想调整 Bazel 设置以获得更好的性能,那么本页面非常适合您。如果您尚未设置远程执行,请先转到 Bazel 远程执行概览

要启用动态执行功能吗?

动态执行模块是 Bazel 的一部分,但要利用动态执行,您必须能够从同一 Bazel 设置在本地和远程编译。

如需启用动态执行模块,请将 --internal_spawn_scheduler 标志传递给 Bazel。这会添加一个名为 dynamic 的新执行策略。您现在可以将其用作您要动态运行的助记符的策略,例如 --strategy=Javac=dynamic。请参阅下一部分,了解如何选择要为哪些助记符启用动态执行功能。

对于使用动态策略的任何助记符,远程执行策略从 --dynamic_remote_strategy 标志获取,本地策略从 --dynamic_local_strategy 标志获取。传递 --dynamic_local_strategy=worker,sandboxed 会设置动态执行的本地分支的默认值,以便按该顺序尝试工作器或沙盒化执行。传递 --dynamic_local_strategy=Javac=worker 会仅替换 Javac 助记符的默认值。遥控器版本的工作原理相同。这两个标志可以指定多次。如果某项操作无法在本地执行,则会照常远程执行,反之亦然。

如果您的远程系统具有缓存,--local_execution_delay 标志会在远程系统指示缓存命中后向本地执行添加延迟(以毫秒为单位)。这样可以避免在可能出现更多缓存命中时运行本地执行。默认值为 1000 毫秒,但应调整为略高于缓存命中通常所需的时间。实际时间取决于远程系统和往返所用的时间。通常,对于给定远程系统的所有用户,该值都是相同的,除非其中某些用户相隔太远,会增加往返延迟时间。您可以使用 Bazel 性能剖析功能来了解典型缓存命中需要多长时间。

动态执行可以与本地沙盒策略以及永久性工作器结合使用。与动态执行搭配使用时,永久性工作器将自动通过沙盒运行,并且不能使用多路复用工作器。在 Darwin 和 Windows 系统中,沙盒化策略可能速度很慢;您可以传递 --reuse_sandbox_directories 以减少在这些系统上创建沙盒的开销。

动态执行也可以使用 standalone 策略运行,不过,由于 standalone 策略在开始执行时必须获取输出锁,因此可以有效地阻止远程策略先完成。--experimental_local_lockfree_output 标志允许本地执行直接写入输出,但如果远程执行先完成,则会取消该输出,从而解决此问题。

如果动态执行的其中一个分支先完成但失败了,则整个操作都会失败。这是一种有意选择,可防止本地执行和远程执行之间的差异被忽视。

如需详细了解动态执行及其锁定的工作原理,请参阅 Julio Merino 精彩的博文

何时应使用动态执行?

动态执行需要某种形式的远程执行系统。目前无法使用仅缓存远程系统,因为缓存未命中会被视为失败操作。

并非所有类型的操作都非常适合远程执行。最佳候选者是那些本身在本地速度更快(例如,通过使用永久性工作器的工作器)的工作负载,或者那些运行速度足够快以至于远程执行开销占用大量执行时间的工作器。由于每个本地执行的操作都会锁定一定数量的 CPU 和内存资源,因此运行不属于这些类别的操作只会延迟执行这些操作的执行。

从版本 5.0.0-pre.20210708.4 开始,性能分析包含有关工作器执行情况的数据,其中包括在动态执行争用失败后完成工作请求所花费的时间。如果您在 async-worker-finish 中看到动态执行工作器线程花费大量时间获取资源或花费大量时间,则可能存在某些缓慢的本地操作导致工作器线程延迟。

在动态执行性能不佳时分析数据

在上面的配置文件(使用 8 个 Javac 工作器)中,我们看到许多 Javac 工作器落败了比赛,并在 async-worker-finish 线程上完成了其工作。这是由于非工作器助记符占用了足够的资源来延迟工作器。

通过更好的动态执行性能分析数据

当只有 Javac 通过动态执行运行时,只有大约一半的已启动工作器在开始工作后最终输掉比赛。

之前建议的 --experimental_spawn_scheduler 标志已被弃用。它会启用动态执行功能,并将 dynamic 设置为所有助记符的默认策略,这通常会导致这类问题。

问题排查

动态执行的问题可能细微且难以调试,因为它们只有在本地和远程执行的某些特定组合下才会显现。--debug_spawn_scheduler 会添加来自动态执行系统的额外输出,帮助调试这些问题。您还可以调整 --local_execution_delay 标志以及远程作业与本地作业的数量,以便更轻松地重现问题。

如果您在使用 standalone 策略进行动态执行时遇到问题,请尝试在不使用 --experimental_local_lockfree_output 的情况下运行,或在沙盒化模式下运行本地操作。这可能会稍微减慢您的构建速度(如果您使用的是 Mac 或 Windows,请参阅上文),但可以排除一些可能导致构建失败的原因。