动态执行

报告问题 查看来源 每晚 · 7.2。 · 7.1敬上 · 7.0 · 6.5 条 · 6.4

动态执行是 Bazel 中的一项功能 从版本 0.21 开始 在本地和远程并行启动同一操作, 使用完成的第一个分支的输出,取消另一个分支 分支。它结合了遥控器的执行能力和/或大型共享缓存 具有低延迟的本地执行性能的构建系统,兼具两者的优势 无论是干净 build 还是增量 build。

本页介绍了如何启用、调整和调试动态执行。如果您 已设置本地和远程执行,并正在尝试调整 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 美利奴很棒 博文

何时应使用动态执行?

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

并非所有类型的操作都非常适合远程执行。最佳 候选版本是指那些本来可以较快的 使用永久性工作器或运行 足够快,以至于远程执行开销占据了执行时间。 由于每个本地执行的操作都会锁定一定数量的 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),但移除了一些可能导致故障的原因。