Bazel 較為複雜,而且在建構過程中會執行許多不同的工作 其中部分可能會影響建構效能這個網頁嘗試對應 其中部分 Bazel 概念對建構效能的影響。雖然 我們提供一些例子,說明如何偵測建構效能 擷取指標 以及如何修正我們希望您能透過這些概念 有助於調查建構效能迴歸問題
簡潔與漸進式版本
簡潔的建構作業就是從頭開始建構所有項目,而累加的建構作業 包括部分已完成的工作
建議您分別查看簡潔和漸進式的版本,尤其是在 需要收集 / 匯總的指標取決於 Bazel 的快取 (例如 建構要求大小指標 )。也代表兩種不同的使用者體驗。與開始相比 從零開始建構乾淨的建構作業 (冷快取需要較長時間)、漸進式 隨著開發人員疊代程式碼 因為快取通常已暖機)。
您可以使用 BEP 中的 CumulativeMetrics.num_analyses
欄位進行分類
建構應用程式如果是 num_analyses <= 1
,代表這是乾淨的建構作業;否則我們就能
該類別可能是漸進式版本,因為使用者可能
導致建構過程變得有效。不限
他們很有可能聽到更嚴格的成效增幅定義,例如
例如查看載入的包裹數量
(PackageMetrics.packages_loaded
)。
確定性建構指標可用來替代建構效能
由於非確定性的本質,因此難以評估建構效能 或監控遠端應用程式 (例如 Bazel 的 CPU 作業時間或遠端的佇列時間) 叢集)。因此,以確定性指標做為 而 Bazel 執行的工作量又會影響其效能。
建構要求的大小可能會對建構作業產生重大影響 才需進行建構大型版本代表更多的分析工作 建構圖表隨著版本自然增長 隨著依附元件增加/建立,也會越來越複雜 建構成本也更高
我們可以將這個問題分成各種建構階段,並使用以下方法 瞭解各階段執行工作時所用工作的替代指標:
PackageMetrics.packages_loaded
:成功載入的套件數量。 這裡的迴歸代表需完成更多讀取和剖析的工作 就會產生多個額外的 BUILD 檔案TargetMetrics.targets_configured
:代表目標數量 建構容器中執行的某些部分迴歸代表 建構及掃遍設定的目標圖- 這通常是因為加入依附元件 和必須建構 大眾運輸停靠圖。
- 使用 cquery 找出新位置 可能已加入依附元件
ActionSummary.actions_created
:代表建構中建立的動作。 迴歸代表建構動作圖表的工作量較多注意事項 其中也包含可能尚未執行且未使用的動作。- 使用 aquery 對迴歸進行偵錯;
建議您先從
--output=summary
敬上 再深入使用--skyframe_state
。
- 使用 aquery 對迴歸進行偵錯;
建議您先從
ActionSummary.actions_executed
:已執行的動作數量, 直接迴歸代表執行這些動作的更多工作。- BEP 會寫入動作統計資料
ActionData
,顯示最常執行的動作類型。根據預設 會收集前 20 種動作類型,但您可以傳入--experimental_record_metrics_for_all_mnemonics
敬上 收集所有已執行動作類型的資料 - 這有助於您瞭解所執行的操作類型 (額外考量)。
- BEP 會寫入動作統計資料
BuildGraphSummary.outputArtifactCount
:由 以及執行的動作- 如果執行的操作數量沒有增加,可能是因為 變更規則導入狀態
這些指標都受到本機快取狀態的影響 請務必確保擷取這些指標的建構作業 簡潔的建構。
我們注意到上述任一指標發生迴歸問題, 實際時間、CPU 時間和記憶體用量中的迴歸問題
使用本機資源
Bazel 會使用本機電腦上的各種資源 (兩者用來分析) 「建立圖表」及「啟動執行作業」和「執行本地動作」) 來執行 建構和建構其他工作
使用時間
也許是容易受到雜訊影響的指標 (在建構時可能大不相同)
時間;像是實際時間、CPU 時間和系統時間你可以
使用 bazel-bench
並提供足夠的 --runs
指標,即可
提高評估的統計顯著程度。
實際時間是指經過的實際時間,
- 如果「只有」實際時間迴歸,建議您收集 JSON 追蹤記錄設定檔,並查詢 比較兩者的差異否則從 其他迴歸指標可能影響了牆壁 讓應用程式從可以最快做出回應的位置 回應使用者要求
CPU 作業時間是指 CPU 執行使用者程式碼花費的時間。
- 如果兩個專案修訂版本都發生 CPU 時間迴歸現象
Starlark CPU 分析器建議您一併使用
--nobuild
限製版本只用於分析階段,因為這是 已完成大量 CPU 工作。
- 如果兩個專案修訂版本都發生 CPU 時間迴歸現象
Starlark CPU 分析器建議您一併使用
系統時間是指核心中 CPU 花費的時間。
- 如果系統時間迴歸,當 Bazel 讀取時,這通常與 I/O 有關 檔案。
整個系統負載剖析
使用
--experimental_collect_load_average_in_profiler
敬上
標記,
JSON 追蹤分析器會收集
系統在叫用期間達到平均負載
圖 1. 包含系統負載平均值的設定檔。
Bazel 在 Bazel 叫用期間出現高負載,這可能表示 Bazel 會安排時間
機器同時執行的本機動作過多。建議你查看
調整中
--local_cpu_resources
敬上
和 --local_ram_resources
,
尤其是在容器環境中
#16512 已合併)。
監控 Bazel 記憶體用量
如要取得 Bazel 的記憶體用量,有兩個主要來源:Bazel info
和
BEP。
bazel info used-heap-size-after-gc
:之後的記憶體用量,以位元組為單位 對System.gc()
發出的呼叫。- Bazel bench 也會提供這項指標的基準。
- 此外還有
peak-heap-size
、max-heap-size
、used-heap-size
和committed-heap-size
(請參閱 說明文件),但 較不相關。
BEP 的
MemoryMetrics.peak_post_gc_heap_size
:尖峰 JVM 堆積大小的規模 納入 GC 後的位元組 (需要設定--memory_profile
。 嘗試強制執行完整的 GC)。
記憶體用量出現迴歸通常是 建構要求大小指標 這通常是因為新增依附元件或變更規則 。
如要更精細地分析 Bazel 的記憶體用量,建議您使用 內建記憶體分析器 。
永久工作站的記憶體分析
雖然永久工作站可協助加快建構速度
(尤其是解譯語言) 記憶體用量可能會
可能會發生問題Bazel 會收集其工作站上的指標,尤其是
WorkerMetrics.WorkerStats.worker_memory_in_kb
欄位會說明
工作站用量 (即記憶式)。
JSON 追蹤記錄分析器
透過傳入
--experimental_collect_system_network_usage
敬上
標記 (在 Bazel 6.0 中使用)。
圖 2. 包括工作站記憶體用量的設定檔。
將
--worker_max_instances
敬上
(預設值 4) 或許有助減少
永久磁碟區使用的記憶體容量我們正在積極努力
讓 Bazel 的資源管理工具和排程器變得更聰明,以便微調
通常是日後減少使用頻率
監控遠端建構作業的網路流量
在遠端執行中,Bazel 會下載因 或是執行動作因此,網路頻寬可能會影響效能 建構容器
如果您要針對建構作業使用遠端執行功能,可以考慮採用
監控叫用期間的網路流量
來自 BEP 的 NetworkMetrics.SystemNetworkStats
proto
(需要傳遞 --experimental_collect_system_network_usage
)。
進一步瞭解 JSON 追蹤記錄設定檔
可讓您在建構過程中查看整個系統的網路用量
方法是將 --experimental_collect_system_network_usage
標記 (在 Bazel 新增)
6.0)。
圖 3. 包含整個系統網路用量的設定檔。
使用遠端執行作業時,如果網路用量偏高,可能表示網路用量偏高
找出您建構的瓶頸如果尚未開始使用
考慮在不使用位元組的情況下啟用 Build
--remote_download_minimal
。
這麼做可以避免下載不必要的中繼成果,藉此加快建構速度。
另一個做法是 可節省的磁碟快取 下載頻寬。