Bazel 持久化 Worker 完全指南原理、配置与协议实现【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel持久化 WorkerPersistent Worker是 Bazel 中一项关键的加速执行策略由 Bazel server 启动一个常驻进程作为真实工具通常是编译器的包装器通过反复向该进程发送请求来复用 JVM 预热、JIT 编译结果与 AST 等缓存从而大幅降低每次 action 的启动开销。本文以 Bazel 官方文档《Persistent Workers》为骨架结合当前仓库的 worker 协议定义与核心实现源码系统讲解持久化 Worker 的工作原理、启用方式、参数调优、沙箱影响以及协议实现细节帮助读者在实际项目中安全、高效地用好这一策略。什么是持久化 Worker持久化 Worker 是一个由 Bazel server 启动的长驻进程它既可以是真实工具编译器本身也可以是包裹在工具外层的 wrapper 进程。为了从持久化 Worker 中获益工具必须支持连续执行多次编译任务而 wrapper 需要负责在工具的 API 与下文描述的请求/响应格式之间做转换。同一 Worker 在一次构建中可能被带或不带--persistent_worker标志调用它需要负责正确地启动、通信并在退出时关闭工具进程。每个 Worker 实例会被分配但不是 chroot 到一个独立的工作目录位于outputBase/bazel-workers下。使用持久化 Worker 是一种执行策略它降低启动开销、允许更多 JIT 编译、并能在 action 执行中缓存例如抽象语法树等数据。该策略通过向长驻进程连续发送多个请求来实现这些改进。持久化 Worker 已在多种语言生态中得到实现包括 Java、Scala、Kotlin 等使用 NodeJS 运行时的程序则可以通过bazel/worker辅助库来实现 worker 协议。从源码结构看Bazel 的 worker 子系统集中在 src/main/java/com/google/devtools/build/lib/worker/ 目录下核心组件包括WorkerSpawnStrategyworker 执行策略的入口toString()返回workerWorkerSpawnRunner真正执行 spawn 的 runner负责构造WorkRequest、与 Worker 进程通信、读取WorkResponseWorkerKey唯一标识一类 Worker 进程的数据容器用作 Worker 池的键WorkerFactory由池用来创建、销毁、校验 Worker 进程SingleplexWorker/WorkerProxy/SandboxedWorker等不同模式下的 Worker 具体实现。启用持久化 WorkerBazel 0.27 及以上版本在默认情况下就会对支持持久化 Worker 的 action 使用该策略远程执行优先级更高。对于不支持持久化 Worker 的 actionBazel 会回退到为每个 action 启动一个工具实例的方式。你可以通过为适用的工具 mnemonic 显式设置worker策略来启用它。作为最佳实践示例中为worker策略指定了local作为回退bazel build //varmy:target/var --strategyJavacworker,local与local策略相比使用 worker 策略可以显著提升编译速度取决于实现对 Java 而言构建可快 2–4 倍增量编译有时更快用 worker 编译 Bazel 本身大约快 2.5 倍。具体收益与 Worker 数量选取相关见下文「Worker 数量选择」一节。如果你的远程构建环境与本地环境匹配还可以使用实验性的dynamic策略它让远程执行与本地 Worker 执行赛跑race谁先完成用谁的结果。启用方式为传入--experimental_spawn_scheduler标志。该策略会自动启用 worker因此无需再显式指定worker策略但仍可把local或sandboxed作为回退。Worker 策略的判定逻辑从源码看Worker 策略并非对所有 action 都适用。WorkerSpawnRunner.canExec()见 WorkerSpawnRunner.java会做三重检查action 的 execution requirements 中必须声明supports-workers或supports-multiplex-workers如果设置了--experimental_worker_allowlistmnemonic 必须在允许列表内action 必须带有工具文件toolFiles非空。当 action 不满足这些条件时Bazel 会回退到其他策略这与文档所述「对不支持持久化 Worker 的 action 启动独立工具实例」一致。Worker 数量选择每个 mnemonic 的默认 Worker 实例数为 4可用worker_max_instances标志调整。这里存在权衡一方面要充分利用可用 CPU另一方面要考虑 JIT 编译与缓存命中。Worker 越多越多的 target 需要承担非 JIT 代码的启动成本与冷缓存命中的代价。如果待构建 target 数量较少单个 Worker 可能在编译速度与资源占用之间取得最佳平衡。worker_max_instances是按 mnemonic与 flag 组合WorkerKey来限制的因此在混合系统中若保持默认值最终可能占用相当多的内存。对于增量构建多 Worker 实例的收益更小。该标志还支持[name]value形式的按 mnemonic 配置--worker_max_instancesJavac2只为 Javac 设限value则为未指定的 mnemonic 设置默认值auto表示按机器容量计算合理默认。在 WorkerOptions.java 中该选项由MultiResourceConverter解析其注释明确指出「auto 目前返回默认值」。下图展示了在 6 核超线程 Intel Xeon 3.5 GHz Linux 工作站64 GB 内存上从零编译 Bazel目标//src:bazel的时间对比。每种 Worker 配置运行 5 次干净构建取后 4 次的平均值。不同 Worker 实例数下干净构建的性能对比图图 1.干净构建的性能提升对比。在该配置下2 个 Worker 的编译最快但相比 1 个 Worker 只提升了 14%。如果希望少占内存1 个 Worker 是很好的选择。增量编译通常受益更大——干净构建相对少见而两次编译之间改动单个文件是常见场景尤其在测试驱动开发中。上述示例还包含一些非 Java 的打包 action会掩盖增量编译的时间。只重编译 Java 源码//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar改动AbstractContainerizingSandboxedSpawn.java中的一个内部字符串常量可带来 3 倍加速20 次增量构建取平均丢弃 1 次预热构建不同 Worker 实例数下增量构建的性能对比图图 2.增量构建的性能提升对比。加速幅度取决于改动内容在上述场景中改动一个常用常量可测得 6 倍加速。修改持久化 Worker 行为传递启动标志--worker_extra_flag--worker_extra_flag用于按 mnemonic 为 Worker 指定启动标志。例如--worker_extra_flagjavac--debug只为 Javac 开启调试。该标志每次只能为一个 mnemonic 设置一个 flag。Worker 不仅按 mnemonic 分开创建也按启动标志的差异分开创建每个 mnemonic 与启动标志的组合会合并成一个WorkerKey而每个WorkerKey最多可创建worker_max_instances个 Worker。从 WorkerKey.java 的实现看WorkerKey的相等性比较覆盖了启动参数args、环境变量env、执行根execRoot、mnemonic、是否 multiplex、是否可取消、是否沙箱化、是否内存跟踪以及协议格式等字段——因此任何一项变化都会产生新的 WorkerKey进而可能派生新的 Worker 进程。这正是文档警告的「flag 组合过多会导致内存过度消耗」的根源。按 mnemonic 控制沙箱--worker_sandboxing--worker_sandboxing标志让每个 Worker 请求为其全部输入使用独立的沙箱目录。搭建沙箱会花费额外时间尤其在 macOS 上但能提供更好的正确性保证。除了纯布尔形式该标志还可以按 worker-key mnemonic 限定为--worker_sandboxingmnemonicboolean例如bazel build //my:target --worker_sandboxing --worker_sandboxingJavacno后面的值会覆盖前面值对所影响 mnemonic 的设置因此后面再跟一个裸--worker_sandboxing会为所有 mnemonic 重新启用沙箱。在 WorkerOptions.java 中该解析由MnemonicBooleanConverter完成不带的输入以空字符串作为 key作用于所有 mnemonic同时兼容旧的布尔风格形式裸--worker_sandboxing/--noworker_sandboxinggetWorkerSandboxingMap()则按「后者覆盖前者」的语义把多次出现解析为最终 map。调试与日志--worker_quit_after_build强制所有 Worker 在一次构建完成后退出主要用于调试与性能剖析。--worker_verbose输出更多关于 Worker 行为的日志。该标志会反映到WorkRequest的verbosity字段中让 Worker 实现也可以更啰嗦。从 WorkerSpawnRunner.java 的源码看VERBOSE_LEVEL为 10设置该标志时createWorkRequest()会把verbosity设为 10 一并发送。Worker 日志存放在outputBase/bazel-workers目录例如/tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log文件名包含 worker id 与 mnemonic。由于一个 mnemonic 可能存在多个WorkerKey因此你可能会看到多于worker_max_instances个日志文件。从 WorkerFactory.java 的create()实现可确认日志路径的生成规则workerBaseDir.getRelative(workTypeName - workerId - key.getMnemonic() .log)。其他与 Worker 相关的标志在 WorkerOptions.java 中还可看到一批用于进阶调优的标志例如--worker_multiplex默认 trueWorker 支持时使用 multiplex 复用--worker_max_multiplex_instances单个 multiplex Worker 进程可并行接收的 WorkRequest 数--experimental_worker_cancellation允许 Bazel 向支持取消的 Worker 发送取消请求--experimental_worker_multiplex_sandboxing为带supports-multiplex-sandboxing需求的 multiplex Worker 开启每请求独立沙箱--experimental_total_worker_memory_limit_mb/--experimental_worker_memory_limit_mb超过限制时可能杀死空闲或超限 Worker--experimental_worker_allowlist只允许指定的 worker-key mnemonic 使用持久化 Worker。Android 构建场景请参考文档中的 Android Build Performance 相关说明。实现持久化 Worker如何自己编写一个 Worker详见创建持久化 Worker页面。下面给出一个使用 JSON 协议、通过 Starlark 声明 Worker 动作的完整示例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_mem4G, %s % args_file.path], execution_requirements { supports-workers : 1, requires-worker-protocol : json } )该动作第一次被使用时Bazel 会以命令行/bin/some_compiler -max_mem4G --persistent_worker启动 Worker。随后一个编译Foo.java的请求形如{ arguments: [ -g, -source, 1.5, Foo.java ] inputs: [ { path: symlinkfarm/input1, digest: d49a... }, { path: symlinkfarm/input2, digest: 093d... }, ], }注意协议缓冲规范使用 snake caserequest_id而 JSON 协议使用 camel caserequestId。Worker 从stdin接收这个按行分隔的 JSON 请求因为requires-worker-protocol设为json执行动作后在stdout上向 Bazel 发送 JSON 格式的WorkResponse。Bazel 解析该响应并手动转换为WorkResponseproto。若希望改用二进制编码的 protobuf 通信只需把requires-worker-protocol设为protoexecution_requirements { supports-workers : 1 , requires-worker-protocol : proto }设置requires-worker-protocol还会确保所选协议通过persistentWorkerProtocol平台属性转发给任何远程执行服务器。如果不设置它Bazel 默认使用 protobuf 与 Worker 通信。Worker 协议定义源码级协议的消息格式定义在 src/main/protobuf/worker_protocol.proto 中Input包含path相对于执行根或绝对路径与digest内容哈希作为不透明令牌某些情况下可为空。WorkRequest包含arguments参数列表、inputs允许读取的输入、request_id单工为 0复用模式下必须是唯一正整数且原样带回、cancel实验性取消请求标志、verbosity0 时允许输出额外调试信息--worker_verbose默认使其为 10以及sandbox_dir复用模式下为沙箱隔离而设的相对目录前缀。WorkResponse包含exit_code、output相当于独立进程的 stdout/stderr 合并输出UTF-8 编码、request_id须与对应 WorkRequest 一致用于复用模式下定位归属以及实验性的was_cancelled。Bazel 侧在 WorkerSpawnRunner.java 的createWorkRequest()中为每个输入文件附带摘要digest这样编译器或 wrapper 无需读取文件即可判断输入是否仍然有效——这正是文档「为允许 Worker 正确使用编译器缓存每个输入文件都会附带 digest」的实现基础。而expandArgument()负责递归展开flagfile参数可转义外部仓库标签形如repo//...不会被误展开。Bazel 从 mnemonic 与共享标志推导出WorkerKey因此如果上述配置允许改变max_mem参数每个取值都会派生独立的 Worker。若变化过多会导致内存消耗过大——与文档警告一致。并发与多路复用Multiplex目前每个 Worker 一次只能处理一个请求。实验性的 multiplex worker 特性允许在底层工具支持多线程且 wrapper 理解多路复用时使用多个线程。从WorkerKey的multiplex字段与WorkerFactory.create()的分支可以看出复用 Worker 走WorkerProxy共享一个WorkerMultiplexer底层进程沙箱化复用 Worker 则走SandboxedWorkerProxy每种模式下请求都通过request_id归属到对应的 proxy 实例。更多实现参考仓库的示例代码目录examples/提供了多种语言的构建示例可作为理解 action 定义与策略触发的补充材料关于 Worker 的创建流程、请求/响应规范、取消机制与「Work action requirements」的完整说明请继续阅读创建持久化 Worker页面。Worker 如何影响沙箱默认情况下worker策略与local策略类似不会在沙箱中执行 action。你可以设置--worker_sandboxing让所有 Worker 在沙箱内运行确保工具每次执行只能看到它应该看到的输入文件也可以按 mnemonic 限定为--worker_sandboxingmnemonicboolean。但工具仍可能在内部请求之间泄漏信息例如通过缓存。使用dynamic策略时要求 Worker 必须沙箱化从源码结构看dynamic 执行下 singleplex worker 无论该标志如何设置都强制沙箱。为了让 Worker 正确使用编译器缓存Bazel 会为每个输入文件附带 digest编译器或 wrapper 无需读文件即可校验输入是否仍然有效。尽管如此即便使用了输入 digest 来防止意外缓存沙箱化的 Worker 提供的沙箱严格程度仍不如纯沙箱——因为工具可能保留受先前请求影响的内部状态。multiplex Worker 只有在实现支持时才能被沙箱化且必须通过--experimental_worker_multiplex_sandboxing标志单独启用。沙箱相关源码佐证--worker_sandboxing的解析与合并语义见 WorkerOptions.javaMnemonicBooleanConverter与getWorkerSandboxingMap()沙箱化 Worker 的具体实现为SandboxedWorker/SandboxedWorkerProxy创建逻辑见 WorkerFactory.java沙箱的一般性介绍见 沙箱Sandboxing文档。性能调优建议小结综合本文内容实践中可参考以下经验优先启用默认 worker 策略Bazel 0.27 默认对支持 worker 的 action 启用Java 编译可获 2–4 倍加速增量编译收益更大Worker 数量按需调整目标多、机器核多时用--worker_max_instances适度上调目标少、内存敏感时 1 个 Worker 往往是最佳折中警惕 WorkerKey 爆炸--worker_extra_flag或 action 中可变的启动参数如max_mem会按组合派生独立 Worker过多组合会导致内存膨胀需要正确性保证时开启--worker_sandboxing并接受其搭建沙箱的额外时间开销macOS 上更明显调试定位问题时用--worker_verbose观察 Worker 行为用--worker_quit_after_build强制退出日志位于outputBase/bazel-workers/下以worker-id-Mnemonic.log命名的文件并发场景如需单进程多请求并发研究 multiplex worker 特性并确保底层工具线程安全。进一步阅读创建持久化 Worker完整实现 Worker 的协议细节、取消机制与规则编写Multiplex Workers单进程多请求并发的实验特性沙箱Sandboxing沙箱机制的一般原理用户手册执行策略策略选择与优先级Worker 协议消息定义src/main/protobuf/worker_protocol.protoWorker 命令行选项定义src/main/java/com/google/devtools/build/lib/worker/WorkerOptions.javaWorker 核心执行逻辑src/main/java/com/google/devtools/build/lib/worker/WorkerSpawnRunner.java。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考