動態執行是 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 電腦上，但請移除某些失敗的原因。