Почему bazel ограничивает выполнение 24 действий, даже если установлен параметр сборки "--jobs = 240"? - PullRequest
0 голосов
/ 08 октября 2018

Я настроил цепочку инструментов для 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 процессоров и 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

toolchain / BUILD

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,
)

toolchain / 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"
}

1 Ответ

0 голосов
/ 08 октября 2018

Если нет какой-либо интеграции между distcc и bazel, о которой я не знаю, bazel считает, что выполняет все на локальной машине и поэтому ограничен ресурсами локальной машины.Существует локальный аргумент ресурсов, который можно настроить, но вместо этого я настоятельно рекомендую использовать Bazel по назначению.При удаленном построении это означает использование REAPI-совместимого билда.

Существует как минимум два:

  • https://github.com/bazelbuild/bazel-buildfarm

    • официальныйimpl, запущенный Uber, используется многими
    • двумя компонентами в архитектуре: сервер (планировщик) и рабочий кеш
    • могут храниться на рабочих или в кеш на основе grpc
      • последний, похоже, пока мало что использовал
    • написано в java
  • https://github.com/EdSchouten/bazel-buildbarn

    • написано в go
    • несколько другая архитектура (интерфейс / планировщик / работник)
    • более гибкое кэширование

Я немного попробовал первое, и собираюсь попробовать второе - частично из-за кеширования, а частично из-за языка: я считаю, что читать и писать гораздо проще, чем Java.

...