永久性工作器

报告问题 查看源代码

本页面介绍了如何使用永久性工作器、其优势、要求以及工作器对沙盒的影响。

永久性工作器是由 Bazel 服务器启动的长时间运行的进程，它充当实际工具（通常是编译器）的封装容器，或者是工具本身。为了从永久性工作器中受益，该工具必须支持执行一系列编译，并且封装容器需要在该工具的 API 和下文所述的请求/响应格式之间进行转换。在同一 build 中，无论是否使用 --persistent_worker 标志都可以调用同一 worker，它负责正确启动该工具并与该工具进行通信，以及在退出时关闭 worker。每个工作器实例都会在 <outputBase>/bazel-workers 下分配（但不进行 chroot 到）一个单独的工作目录。

使用永久性工作器是一种执行策略，可以减少启动开销，支持更多的 JIT 编译，并支持在操作执行过程中缓存抽象语法树。为了实现这些改进，此策略通过向长时间运行的进程发送多个请求。

持久性工作器针对多种语言实现，包括 Java、Scala、Kotlin 等。

使用 NodeJS 运行时的程序可以使用 @bazel/worker 帮助程序库来实现工作器协议。

使用永久性工作器

Bazel 0.27 及更高版本在执行构建时默认使用永久性工作器，但远程执行优先。对于不支持永久性工作器的操作，Bazel 会回退为为每个操作启动工具实例。您可以通过针对适用的工具助记符设置 worker 策略，将构建明确设置为使用永久性工作器。根据最佳实践，此示例包括将 local 指定为 worker 策略的回退：

bazel build //my:target --strategy=Javac=worker,local

使用 worker 策略而不是本地策略可以显著提升编译速度，具体取决于实现。对于 Java，构建速度可以提高 2-4 倍；对于增量编译，构建速度有时会更快。使用工作器编译 Bazel 的速度大约是原来的 2.5 倍如需了解详情，请参阅“选择工作器数量”部分。

如果您还有与本地构建环境匹配的远程构建环境，则可以使用实验性动态策略，该策略会竞争远程执行和工作器执行。要启用动态策略，请传递 --experimental_spawn_scheduler 标志。此策略会自动启用工作器，因此无需指定 worker 策略，但您仍然可以使用 local 或 sandboxed 作为后备选项。

选择工作器数量

每个助记符的默认工作器实例数为 4，但可以使用 worker_max_instances 标志进行调整。您需要在充分利用可用的 CPU 和获得的 JIT 编译和缓存命中数量之间进行权衡。工作器越多，运行非 JIT 代码和访问冷缓存所需的启动费用就越多。如果您要构建少量目标，单个工作器可以在编译速度和资源用量之间取得最佳平衡（例如，请参阅问题 8586）。 worker_max_instances 标志用于设置每个助记符和标志集的工作器实例数量上限（见下文），因此在混合系统中，如果您保留默认值，最终可能会使用大量内存。对于增量构建，多个工作器实例的优势更小。

此图表显示了 Bazel（目标 //src:bazel）在具有 64 GB RAM 的 6 核超线程 Intel Xeon 3.5 GHz Linux 工作站上的从头开始编译时间。对于每个工作器配置，将运行五个整洁 build，并采用最后四个 build 的平均值。

图 1. 干净 build 的性能改进图。

对于此配置，两个 worker 的编译速度最快，但与一个 worker 相比，速度只提高了 14%。如果要使用的内存较少，一个工作器是不错的选择。

增量编译通常好处更多。干净 build 相对较少，但在两次编译之间更改单个文件是很常见的，尤其是在由测试驱动的开发中。上面的示例还包含一些非 Java 打包操作，这些操作可能会覆盖增量编译时间。

更改 AbstractContainerizingSandboxedSpawn.java 中的内部字符串常量后，仅重新编译 Java 源代码 (//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar) 可将速度提升到原来的 3 倍（平均进行 20 次增量构建，并舍弃一个预热构建）：

图 2. 增量构建的性能改进图。

加速时间取决于所做的更改。在上述情况下，当常用常量发生变化时测量到因数 6 的加速。

修改永久性工作器

您可以传递 --worker_extra_flag 标志，为工作器指定启动标志（由助记符键控）。例如，传递 --worker_extra_flag=javac=--debug 仅会为 Javac 开启调试功能。每次使用此标志时，只能设置一个工作器标志，并且只能为一个助记符设置一个工作器标志。您不仅要为每个助记符单独创建 worker，还要为其启动标志中的变体创建 worker。助记标记和启动标志的每个组合都会合并到一个 WorkerKey 中，并且可为每个 WorkerKey 创建最多 worker_max_instances 个工作器。请参阅下一部分，了解操作配置如何还可以指定设置标志。

您可以使用 --high_priority_workers 标志指定一个助记符，该助记符应优先于普通优先级助记符运行。这有助于优先考虑始终处于关键路径的操作。如果有两个或两个以上的高优先级工作器正在执行请求，则阻止所有其他工作器运行。此标志可以多次使用。

传递 --worker_sandboxing 标志会使每个工作器请求使用单独的沙盒目录来处理其所有输入。设置sandbox需要一些额外的时间（尤其是在 macOS 上），但可以更好地保证正确性。

--worker_quit_after_build 标志主要用于调试和性能剖析。此标志会在构建完成后强制所有工作器退出。您还可以传递 --worker_verbose 以获取有关工作器正在执行的操作的更多输出。此标志反映在 WorkRequest 的 verbosity 字段中，从而使得 worker 实现也更详细。

工作器将其日志存储在 <outputBase>/bazel-workers 目录中，例如 /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log。文件名包含工作器 ID 和助记符。由于每个助记符可能有多个 WorkerKey，因此您可能会看到给定助记符有多个 worker_max_instances 日志文件。

对于 Android build，请参阅 Android build 性能页面上的详细信息。

实现永久性工作器

如需详细了解如何创建工作器，请参阅创建永久性工作器页面。

以下示例展示了使用 JSON 的工作器的 Starlark 配置：

args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
    output = args_file,
    content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
    mnemonic = "SomeCompiler",
    executable = "bin/some_compiler_wrapper",
    inputs = inputs,
    outputs = outputs,
    arguments = [ "-max_mem=4G",  "@%s" % args_file.path],
    execution_requirements = {
        "supports-workers" : "1", "requires-worker-protocol" : "json" }
)

根据此定义，第一次使用时，首先会执行命令行 /bin/some_compiler -max_mem=4G --persistent_worker。编译 Foo.java 的请求将如下所示：

注意：虽然协议缓冲区规范使用“蛇形命名法”(request_id)，但 JSON 协议使用“驼峰式大小写”(requestId)。在本文档中，我们将在 JSON 示例中使用驼峰式大小写，但在讨论字段时（无论协议如何都是蛇形）。

{
  "arguments": [ "-g", "-source", "1.5", "Foo.java" ]
  "inputs": [
    { "path": "symlinkfarm/input1", "digest": "d49a..." },
    { "path": "symlinkfarm/input2", "digest": "093d..." },
  ],
}

工作器在 stdin 上以换行符分隔的 JSON 格式接收此字符串（因为 requires-worker-protocol 设置为 JSON）。然后，工作器会执行该操作，并将 JSON 格式的 WorkResponse 发送到其 stdout 上的 Bazel。然后，Bazel 会解析此响应并手动将其转换为 WorkResponse proto。如需使用二进制编码的 protobuf（而不是 JSON）与关联的工作器通信，应将 requires-worker-protocol 设置为 proto，如下所示：

  execution_requirements = {
    "supports-workers" : "1" ,
    "requires-worker-protocol" : "proto"
  }

如果您未在执行要求中添加 requires-worker-protocol，则 Bazel 会默认将工作器通信设置为使用 protobuf。

Bazel 从助记符和共享标志派生 WorkerKey，因此，如果此配置允许更改 max_mem 参数，系统将为每个使用的值生成一个单独的工作器。如果使用的变体过多，可能会导致内存消耗过多。

每个工作器目前一次只能处理一个请求。如果底层工具是多线程的，并且已将封装容器设置为理解多线程，则实验性的多路复用工作器功能允许使用多线程。

在此 GitHub 代码库中，您可以看到使用 Java 和 Python 编写的示例工作器封装容器。如果您使用 JavaScript 或 TypeScript，@bazel/worker 软件包和 nodejs worker 示例可能会有所帮助。

工作器如何影响沙盒？

默认情况下，使用 worker 策略时不会在sandbox中运行操作，这与 local 策略类似。您可以设置 --worker_sandboxing 标志以在沙盒内运行所有工作器，并确保该工具的每次执行都只能看到应该包含的输入文件。该工具可能仍会在内部请求之间泄露信息，例如通过缓存。使用 dynamic 策略需要对工作器进行沙盒化。

为了允许工作器正确使用编译器缓存，摘要会随每个输入文件一起传递。因此，编译器或封装容器可以检查输入是否仍然有效，而无需读取文件。

即使使用输入摘要来防止不必要的缓存，沙盒化 worker 提供的沙盒也不如纯沙盒，因为该工具可能会保留受先前请求影响的其他内部状态。

只有当工作器实现支持多路复用工作器时，才能对其进行沙盒化，并且必须使用 --experimental_worker_multiplex_sandboxing 标志单独启用此沙盒。如需了解详情，请参阅设计文档）。

深入阅读

如需详细了解永久性工作器，请参阅：

• 原始永久性工作器博文
• Haskell 实现说明 {: .external}
• Mike Morearty 的博文 {: .external}
• 使用 Bazel 进行前端开发：Angular/TypeScript 和使用 Asana 的持久性工作器 {: .external}
• Bazel 策略说明 {: .external}
• 在 bazel-discuss 邮寄名单中讨论信息丰富的工作器策略 {: .external}