时间戳

首页 > 解决方案 > 为什么即使设置了构建选项“--jobs=240”，bazel 也会限制运行 24 个操作？

bazel - 为什么即使设置了构建选项“--jobs=240”，bazel 也会限制运行 24 个操作？

问题描述

我已经为 distcc 配置了一个工具链，参数通过包装脚本转发到 distcc。

distcc_wrapper_gcc.sh：

#!/bin/bash
set -euo pipefail
ccache distcc g++ "$@"

我想在之前启动 240 个并行任务，例如“make -j240”。构建命令是：

bazel build --action_env=HOME --action_env=DISTCC_HOSTS="***" --config=joint_compilation --jobs=240 target

但是输出是： 238 actions, 24 running

如果我将 --jobs 设置为低于 24，则运行操作的数量将等于它，否则无论参数中的值是什么，都会有多达 24 个进程在运行。

如果只运行 24 个动作，编译确实需要很长时间。跑步动作有硬性限制吗？（这台计算机每个核心有 12 个 cpu 和 2 个线程）

有没有办法打破或忽略这个限制？

下面是配置内容。

.bazelrc

# Create a new CROSSTOOL file for our toolchain.

build:joint_compilation --crosstool_top=//toolchain:distcc

# Use --cpu as a differentiator.

build:joint_compilation --cpu=joint_compilation

# Specify a "sane" C++ toolchain for the host platform.

build:joint_compilation --host_crosstool_top=@bazel_tools//tools/cpp:toolchain

工具链/构建

package(default_visibility = ['//visibility:public'])
cc_toolchain_suite(
    name = "distcc",
    toolchains = {
        "joint_compilation": ":joint_compilation_toolchain",
        "distcc|joint_compilation": ":joint_compilation_toolchain",
    },
)
filegroup(name = "empty")

filegroup(
name = "all",
srcs = [
   "distcc_wrapper_gcc.sh",
],
)

cc_toolchain(
    name = "joint_compilation_toolchain",
    toolchain_identifier = "joint_compilation-toolchain",
    all_files = ":all",
    compiler_files = ":all",
    cpu = "distcc",
    dwp_files = ":empty",
    dynamic_runtime_libs = [":empty"],
    linker_files = ":all",
    objcopy_files = ":empty",
    static_runtime_libs = [":empty"],
    strip_files = ":empty",
    supports_param_files = 0,
)

工具链/CROSSTOOL

major_version: "1"
minor_version: "0"
default_target_cpu: "joint_compilation"

toolchain {
  toolchain_identifier: "joint_compilation-toolchain"
  host_system_name: "i686-unknown-linux-gnu"
  target_system_name: "joint_compilation-unknown-distcc"
  target_cpu: "joint_compilation"
  target_libc: "unknown"
  compiler: "distcc"
  abi_version: "unknown"
  abi_libc_version: "unknown"
  tool_path {
      name: "gcc"
      path: "distcc_wrapper_gcc.sh"
  }
   tool_path {
      name: "g++"
      path: "distcc_wrapper_gcc.sh"
  }
  tool_path {
      name: "ld"
      path: "/usr/bin/ld"
  }
  tool_path {
      name: "ar"
      path: "/usr/bin/ar"
  }
  tool_path {
      name: "cpp"
      path: "distcc_wrapper_gcc.sh"
  }
  tool_path {
      name: "gcov"
      path: "/usr/bin/gcov"
  }
  tool_path {
      name: "nm"
      path: "/usr/bin/nm"
  }
  tool_path {
      name: "objdump"
      path: "/usr/bin/objdump"
  }
  tool_path {
      name: "strip"
      path: "/usr/bin/strip"
  }


  cxx_builtin_include_directory: "/usr/lib/gcc/"
  cxx_builtin_include_directory: "/usr/local/include"
  cxx_builtin_include_directory: "/usr/include"
}

标签： bazel

解决方案

除非我不知道 distcc 和 bazel 之间有一些集成，否则 bazel 认为它正在本地机器上执行所有内容，因此受到本地机器资源的限制。有一个可以调整的本地资源 arg，但我强烈建议按预期使用 bazel。远程构建时，这意味着使用支持 REAPI 的 buildfarm。

至少存在两个：

我已经尝试了前者，并且即将尝试后者 - 部分是由于缓存，部分是由于语言：我发现 go 比 java 更容易阅读（和编写）。

推荐阅读