永久工作站

回報問題 查看原始碼 夜間 7.4 ,直接在 Google Cloud 控制台實際操作。 7.3 · 7.2 · 7.1 · 7.0 · 6.5

本頁面說明如何使用永久工作站、優點、要求及 瞭解工作站對沙箱的影響。

永久工作站是 Bazel 伺服器啟動的長時間執行程序, 函式做為實際工具 (通常是編譯器) 的包裝函式,或者 工具本身。為了讓持續性工作者發揮效益,工具必須支援執行一系列編譯作業,而包裝函式需要在工具的 API 和下方所述要求/回應格式之間進行轉譯。同一個 worker 可能會在相同版本中搭配或不搭配 --persistent_worker 標記呼叫,並負責適當地啟動並與工具對話,以及在退出時關閉 worker。每個 worker 例項都會指派 (但不會以 chroot 指派) <outputBase>/bazel-workers 底下的獨立工作目錄。

使用持續性工作者是一種執行策略,可減少啟動額外負擔、允許更多 JIT 編譯,並啟用動作執行作業中的抽象語法樹狀結構快取。這項策略會向長時間執行的程序傳送多個要求,進而達成這些改善。

持久性工作者已針對多種語言實作,包括 Java、ScalaKotlin 等。

使用 NodeJS 執行階段的程式可使用 @bazel/worker 輔助程式庫 實作工作站通訊協定

使用永久工作站

Bazel 0.27 以上版本 執行建構作業時預設會使用永久工作站,不過在執行建構作業時 優先順序較高。如果動作不支援永續性工作站,Bazel 會改為為每個動作啟動工具例項。您可以特別提出 將 worker 設為使用永久工作站,藉此將版本設為使用永久工作站 策略 助憶鍵最佳做法是將 local 指定為 回 worker 策略:

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

使用 worker 策略而非本機策略,可大幅提升編譯速度 (視實作方式而定)。Java 的建構作業可介於 2 至 4 之間 增加 1 倍,有時更多的漸進式編譯。使用 worker 編譯 Bazel 的速度約為 2.5 倍。詳情請參閱 「選擇工作站數量」專區。

如果您也有與本機建構環境相符的遠端建構環境,可以使用實驗性的動態策略,以便同時執行遠端執行作業和 worker 執行作業。如要啟用動態策略,請傳遞 --experimental_spawn_scheduler 標記。這項策略會自動啟用 worker,因此您不需要指定 worker 策略,但仍可使用 localsandboxed 做為備用。

選擇工作站數量

每個助憶法的工作站執行個體預設數量為 4,但可以使用 worker_max_instances 標記進行調整。妥善運用可用的 CPU 與 JIT 編譯和快取命中次數之間存在取捨。員工人數越多,就可獲得更多 目標將支付執行非 JIT 程式碼的啟動成本,以及冷到 快取。如果您要建構的目標數量不多,單一工作站可能會在編譯速度和資源使用量之間取得最佳平衡 (例如,請參閱 問題 #8586)。worker_max_instances 標記會設定每個助記符和標記集的 worker 例項數量上限 (請參閱下方說明),因此在混合系統中,如果您保留預設值,可能會使用大量記憶體。如果是漸進式建構作業 使用多個工作站執行個體 就能享有更小的優勢

此圖表顯示 Bazel (目標) 的從頭編譯時間 //src:bazel) (位於 6 核心超執行緒 Intel Xeon 3.5 GHz Linux 工作站) 搭載 64 GB RAM針對每個工作站設定,系統會執行五項簡潔建構作業,並 以及最後 4 格的平均分數

清理建構作業的效能改善圖

圖 1. 清理建構作業的效能改善圖表。

針對這項設定,兩個工作站的編譯速度最快,但只有 14% 與一個工作站相比。如果需要 減少記憶體用量

增量編譯通常更有益。乾淨的建構作業 但在編譯之間變更單一檔案很常見, 特別是以測試導向開發上述範例也有一些非 Java 項目 並包裝動作來覆蓋漸進式編譯時間。

AbstractContainerizingSandboxedSpawn.java 中變更內部字串常數後,只重新編譯 Java 來源 (//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar) 可加快 3 倍 (平均 20 次增量建構作業,其中 1 次為預熱建構作業):

漸進式建構作業的效能改善圖表

圖 2. 漸進式建構作業的效能改善圖表。

速度取決於變更。在上述情況下,當常用的常數發生變化時,系統會以 6 倍的速度進行測量。

修改永久工作站

您可以將 --worker_extra_flag 旗標,用於對工作站指定啟動標記,並以助憶鍵為索引鍵。舉例來說,傳遞 --worker_extra_flag=javac=--debug 只會為 Javac 啟用偵錯功能。每次使用此標記時,只能設定一個 worker 標記,且只能針對一個 mnemonic 設定。不僅可以為每個記憶式個別建立工作站, 初始化標記中的變化版本。每個助憶法和啟動旗標組合都會合併為 WorkerKey,且每個 WorkerKey 最多可建立 worker_max_instances 個 worker。請參閱下一節,瞭解如何 動作設定也可以指定設定旗標

您可以使用 --high_priority_workers 標記,指定要按一般優先度優先執行的記憶法 助憶鍵這有助於優先處理最重要的關鍵動作 路徑。如果有兩個或更多高優先順序的 worker 執行要求,系統會禁止所有其他 worker 執行。這個標記可以重複使用。

傳遞 --worker_sandboxing 標記,可讓每個 worker 要求為所有輸入內容使用專屬的沙箱目錄。設定沙箱需要額外時間,尤其是在 macOS 上,但可提供更準確的正確性保證。

--worker_quit_after_build 標記主要用於偵錯和剖析。此標記會在建構作業完成後,強制所有工作者離開。您也可以 --worker_verbose 到 取得更多 worker 作業相關資訊這個標記反映在 WorkRequest 中的 verbosity 欄位,可讓工作站實作 更詳細。

工作站會將記錄儲存在 <outputBase>/bazel-workers 目錄中,例如 /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log。檔案名稱包含工作站 ID 和記憶法。由於 每增加一次 WorkerKey,你可能會看到超過 worker_max_instances 特定記憶的記錄檔

如要進一步瞭解 Android 版本,請參閱 Android 版本效能頁面

實作持續性 worker

詳情請參閱「建立永久工作站」頁面 瞭解如何設定工作站。

下方範例為使用 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 的要求如下所示:

注意:雖然通訊協定緩衝區規格使用的是「Snake case」(request_id), JSON 通訊協定會使用「駝峰式大小寫」(requestId)。在本文件中,我們會使用 JSON 範例中的駝峰式大小寫,但在討論欄位時則使用蛇形大小寫 無論通訊協定為何

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

工作者會以 JSON (以換行符號分隔) 格式 (因為 requires-worker-protocol 已設為 JSON) 在 stdin 上接收此資料。接著,worker 會執行動作,並透過 stdout 將 JSON 格式的 WorkResponse 傳送至 Bazel。Bazel,然後 剖析此回應,然後手動將其轉換為 WorkResponse proto。如要使用二進位編碼的 protobuf 與相關聯的 worker 通訊,而非使用 JSON,requires-worker-protocol 會設為 proto,如下所示:

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

如果您沒有在執行要求中加入 requires-worker-protocol, Bazel 會將工作站通訊預設為使用 protobuf。

Bazel 會從助憶鍵和共用標記衍生出 WorkerKey,因此如有 設定允許變更 max_mem 參數,其他工作站 。這可能會導致記憶體用量過大 使用太多變化。

每個 worker 目前一次只能處理一個要求。如果基礎工具是多執行緒,且包裝函式已設定為瞭解這項功能,實驗性的多工工作站功能可讓您使用多個執行緒。

這個 GitHub 存放區中,您可以看到以 Java 和 Python 編寫的工作站包裝函式範例。如果您使用的是 JavaScript 或 TypeScript,@bazel/worker 套件nodejs worker 範例 可能會有所幫助。

worker 對沙箱有何影響?

根據預設,使用 worker 策略不會在 沙箱,與 local 策略類似。您可以設定 --worker_sandboxing 標記,用於在沙箱內執行所有工作站,確保每個 執行此工具時,只會看見該工具應有的輸入檔案。但這項工具仍可能在要求之間洩漏資訊,例如透過快取。採用「dynamic」策略 「工作站必須受到沙箱保護」

為了讓工作站正確使用編譯器快取,系統會傳送摘要 為每個輸入檔案建立容器因此,編譯器或包裝函式可以檢查輸入內容是否仍有效,而無須讀取檔案。

即使使用輸入摘要來防止不需要的快取,沙箱機制仍然有效 工作人員提供的沙盒技術比純沙盒來得低,因為這項工具 可保留先前要求所影響的其他內部狀態。

只有在 worker 實作支援的情況下,才能將 Multiplex worker 置入沙箱,且必須使用 --experimental_worker_multiplex_sandboxing 標記分別啟用此沙箱。詳情請參閱 設計文件)。

延伸閱讀

如要進一步瞭解持續性工作站,請參閱: