动态执行

从 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 会针对动态执行的本地分支设置默认值,以按该顺序尝试使用 worker 或沙盒化执行。传递 --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 线程上完成工作。这是由于非 worker 助记符占用了足够的资源来延迟 worker。

以更好的动态执行性能来分析数据

当仅 Javac 通过动态执行运行时,只有大约一半已启动的工作器在开始其工作后最终失败了。

之前推荐的 --experimental_spawn_scheduler 标志已废弃。该操作会动态执行,并将 dynamic 设为所有助记符的默认策略,而这通常会导致此类问题。

问题排查

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

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