動態執行

回報問題 查看原始碼 。 。 。 。 夜間。 。 7.3 。 。 7.2 。 。 7.1 。 。 7.0 。 。 6.5

動態執行是 Bazel 中的一項功能,可將本機和遠端執行 使用第一個分支的輸出內容,同時啟動相同的動作 結束執行程序,取消另一個分支版本結合了執行能力 遠端建構系統和/或遠端建構系統的共用快取,同時享有低延遲 因此,為簡潔和漸進式建構提供兩全其最佳優勢 等號召,

本頁面說明如何啟用、調整及偵錯動態執行。如果發生以下情況: 必須設定本機和遠端執行作業,並嘗試調整 Bazel 您可以參考這個網頁如果還沒有 遠端執行設定,請前往 Bazel Remote Execution 請先概觀

要啟用動態執行功能嗎?

動態執行模組屬於 Bazel 的一部分,但要使用動態執行 因此,您必須已能在本機和遠端編譯兩者 使用相同的 Bazel 設定

如要啟用動態執行模組,請傳遞 --internal_spawn_scheduler 加到 Bazel這會新增名為 dynamic 的新執行策略。您現在可以 以此做為目標動態執行的策略,例如 --strategy=Javac=dynamic。請參閱下一節,瞭解如何挑選助聽器 即可啟用動態執行功能

對使用動態策略的任何記憶來說,遠端執行策略就是 取自 --dynamic_remote_strategy 旗標,以及來自 --dynamic_local_strategy 標記。傳球員 --dynamic_local_strategy=worker,sandboxed 會設定本機的 嘗試在工作站或沙箱執行環境中使用工作站或沙箱執行 順序。傳遞 --dynamic_local_strategy=Javac=worker 會覆寫預設值 只有 Javac 記憶法。遠端版本的運作方式相同。這兩種標記可以 可以多次指定如果動作無法在本機執行,則該動作會 遠端執行,反之亦然。

如果遠端系統有快取,請加上 --dynamic_local_execution_delay 旗標 在遠端系統取得 表示快取命中在快取命中時,避免執行本機執行 預設值為 1000 毫秒,但您應該稍微調整一下 所需時間會比快取命中更長實際時間取決於遙控器 以及往返時間通常這個值是 提供給特定遠端系統的所有使用者 (除非有部分距離太遠) 增加往返延遲時間您可以使用 Bazel 剖析 功能,方便你查看 快取命中數

動態執行可搭配本機沙箱策略使用,並搭配 永久性工作站。永久磁碟會自動執行 搭配動態執行使用時透過沙箱執行,且不能使用 multiplex 工作站。在 Darwin 和 Windows 系統上 可能會拖慢速度也可以傳遞 --reuse_sandbox_directories 無須額外費心建立沙箱

動態執行也可以使用 standalone 策略執行,不過因為 standalone 策略必須在開始執行時採用輸出鎖定, 有效地阻止遠端策略。 --experimental_local_lockfree_output 旗標可透過下列方式解決這個問題 允許本機執行作業直接寫入輸出中,但 遠端執行應該先完成這個動作

如果動態執行的其中一個分支版本先完成但失敗, 整個動作失敗這是我們刻意的選擇 本機和遠端執行之間不會被注意到

如需動態執行及其鎖定運作方式的更多背景資訊,請參閱 Julio Merino 的優質網誌 貼文

何時該使用動態執行?

動態執行需要某種形式的遠端執行系統。 目前無法使用僅快取的遠端系統造成快取失敗 系統會將視為失敗的動作

並非所有類型的動作都適合遠端執行。最佳 候選人是指本機速度更快的 您使用永久工作站或執行快速 遠端執行作業的負擔足以支配執行時間。開始時間 本機執行的每項動作都會鎖定一定數量的 CPU 和記憶體資源 執行不屬於這些類別的動作只會延遲執行 能幫我們達成目標

發布後 5.0.0-pre.20210708.4, 效能分析包含資料 工作站執行作業,包括在 導致無法贏得動態的執行競爭如果看到動態執行工作站執行緒 或花費大量時間取得資源 async-worker-finish,本機操作可能會延遲工作站 。

動態執行效能不佳分析資料

上述使用 8 Javac 工作站的設定檔中,看到許多 Javac 工作站 的比賽失敗,並在 async-worker-finish完成工作 。這可能是由於沒有員工的記憶庫 花費了足夠的資源 才能延遲工作站

以更動態的執行效能剖析資料

當只有 Javac 是在動態執行的情況下執行時,大約只有一半的開始執行 因為工人在開始工作之後,就沒辦法趕上賽跑

先前建議的 --experimental_spawn_scheduler 旗標已淘汰。 這項功能會開啟動態執行,並將 dynamic 設為所有 這種記憶法通常會導致這類問題。

成效

動態執行方法會假設可用資源充足 因此建議您投入一些額外資源來改進 整體成效。但過度使用資源可能會降低 Bazel 本身,或是 或對遠端系統造成意外的壓力另有 有幾種變更動態執行行為的選項:

--dynamic_local_execution_delay 會將特定數字延遲在本機分支的開頭 毫秒後讀取, 在目前的建構作業期間 發生遠端快取命中這麼一來 不會浪費本機資源 可以在快取中找到視快取品質而定 減少這個數量或許能改善建構速度,但增加本機資源用量時 再複習一下,機構節點 是所有 Google Cloud Platform 資源的根節點

--experimental_dynamic_local_load_factor 是實驗性質的進階資源 管理選項該設定的值從 0 到 1,0 會關閉。 設為高於 0 的值時,Bazel 會調整 許多動作等待 如果設為 1,就能以這個數量排定動作,數量不限 都是可用的 CPU (根據 --local_cpu_resources 計費)。值越小,設定的數字越小越好 動作的數量越多,所排定的動作數量就會越少 而且可供使用這聽起來可能不符合直覺,但隨附好遙控器 當同時執行許多動作時,本機執行作業沒有幫助 本機 CPU 較適合用來管理遠端動作

--experimental_dynamic_slow_remote_time 優先顯示起始本機分支版本 當遠端分支版本至少執行過此時間時。正常情況下 最近排定的動作會優先放送,因為該動作最有可能 不過,如果遠端系統有時會停止運作或花費較多時間 這應該可以建構前進的系統這項功能預設為停用,因為 遠端系統可能會隱藏問題,而且應修正。請確認 以便監控遠端系統的效能。

--experimental_dynamic_ignore_local_signals 可用於讓遙控器 當局部區域因特定訊號而離開時,分公司接管。這是 主要與工作站資源限制搭配使用 (請參閱 --experimental_worker_memory_limit_mb--experimental_worker_sandbox_hardening, 和 --experimental_sandbox_memory_limit_mb)), 例如工作站程序因使用過多資源而終止。

JSON 追蹤記錄設定檔包含 有助於您找出改善出價方式 並在效能和資源用量方面的取捨

疑難排解

動態執行的問題可能有些微小且難以偵錯, 只有本機和遠端執行作業的特定組合下,才會定義資訊清單。 --debug_spawn_scheduler 會從動態執行作業新增額外輸出內容 能協助偵錯問題的系統你也可以調整 --dynamic_local_execution_delay 旗標和遠端工作與本地職缺的數量, 讓問題更容易重現

如果您在使用 standalone 進行動態執行時遇到問題 策略、嘗試在不使用 --experimental_local_lockfree_output 的情況下執行 本機動作是採用沙箱機制這可能會使建構速度稍微變慢 (請參閱上方的 您是在 Mac 或 Windows 電腦上,但請移除某些失敗的原因。