細分建構效能

回報問題 查看來源 。 。 夜間。 。 7.3 。 。 7.2 。 。 7.1 。 。 7.0 。 。 6.5

Bazel 較為複雜,而且在建構過程中會執行許多不同的工作 其中部分可能會影響建構效能這個網頁嘗試對應 其中部分 Bazel 概念對建構效能的影響。雖然 我們提供一些例子,說明如何偵測建構效能 擷取指標 以及如何修正我們希望您能透過這些概念 有助於調查建構效能迴歸問題

簡潔與漸進式版本

簡潔的建構作業就是從頭開始建構所有項目,而累加的建構作業 包括部分已完成的工作

建議您分別查看簡潔和漸進式的版本,尤其是在 需要收集 / 匯總的指標取決於 Bazel 的快取 (例如 建構要求大小指標 )。也代表兩種不同的使用者體驗。與開始相比 從零開始建構乾淨的建構作業 (冷快取需要較長時間)、漸進式 隨著開發人員疊代程式碼 因為快取通常已暖機)。

您可以使用 BEP 中的 CumulativeMetrics.num_analyses 欄位進行分類 建構應用程式如果是 num_analyses <= 1,代表這是乾淨的建構作業;否則我們就能 該類別可能是漸進式版本,因為使用者可能 導致建構過程變得有效。不限 他們很有可能聽到更嚴格的成效增幅定義,例如 例如查看載入的包裹數量 (PackageMetrics.packages_loaded)。

確定性建構指標可用來替代建構效能

由於非確定性的本質,因此難以評估建構效能 或監控遠端應用程式 (例如 Bazel 的 CPU 作業時間或遠端的佇列時間) 叢集)。因此,以確定性指標做為 而 Bazel 執行的工作量又會影響其效能。

建構要求的大小可能會對建構作業產生重大影響 才需進行建構大型版本代表更多的分析工作 建構圖表隨著版本自然增長 隨著依附元件增加/建立,也會越來越複雜 建構成本也更高

我們可以將這個問題分成各種建構階段,並使用以下方法 瞭解各階段執行工作時所用工作的替代指標:

  1. PackageMetrics.packages_loaded:成功載入的套件數量。 這裡的迴歸代表需完成更多讀取和剖析的工作 就會產生多個額外的 BUILD 檔案

    • 這通常是因為加入依附元件,且必須載入其 及遞移性關閉。
    • 使用 query / cquery 尋找 可能已加入新的依附元件
  2. TargetMetrics.targets_configured:代表目標數量 建構容器中執行的某些部分迴歸代表 建構及掃遍設定的目標圖

    • 這通常是因為加入依附元件 和必須建構 大眾運輸停靠圖。
    • 使用 cquery 找出新位置 可能已加入依附元件
  3. ActionSummary.actions_created:代表建構中建立的動作。 迴歸代表建構動作圖表的工作量較多注意事項 其中也包含可能尚未執行且未使用的動作。

  4. ActionSummary.actions_executed:已執行的動作數量, 直接迴歸代表執行這些動作的更多工作。

    • BEP 會寫入動作統計資料 ActionData,顯示最常執行的動作類型。根據預設 會收集前 20 種動作類型,但您可以傳入 --experimental_record_metrics_for_all_mnemonics敬上 收集所有已執行動作類型的資料
    • 這有助於您瞭解所執行的操作類型 (額外考量)。
  5. BuildGraphSummary.outputArtifactCount:由 以及執行的動作

    • 如果執行的操作數量沒有增加,可能是因為 變更規則導入狀態

這些指標都受到本機快取狀態的影響 請務必確保擷取這些指標的建構作業 簡潔的建構

我們注意到上述任一指標發生迴歸問題, 實際時間、CPU 時間和記憶體用量中的迴歸問題

使用本機資源

Bazel 會使用本機電腦上的各種資源 (兩者用來分析) 「建立圖表」及「啟動執行作業」和「執行本地動作」) 來執行 建構和建構其他工作

使用時間

也許是容易受到雜訊影響的指標 (在建構時可能大不相同) 時間;像是實際時間、CPU 時間和系統時間你可以 使用 bazel-bench 並提供足夠的 --runs 指標,即可 提高評估的統計顯著程度。

  • 實際時間是指經過的實際時間,

    • 如果「只有」實際時間迴歸,建議您收集 JSON 追蹤記錄設定檔,並查詢 比較兩者的差異否則從 其他迴歸指標可能影響了牆壁 讓應用程式從可以最快做出回應的位置 回應使用者要求
  • CPU 作業時間是指 CPU 執行使用者程式碼花費的時間。

    • 如果兩個專案修訂版本都發生 CPU 時間迴歸現象 Starlark CPU 分析器建議您一併使用 --nobuild 限製版本只用於分析階段,因為這是 已完成大量 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 infoBEP

  • bazel info used-heap-size-after-gc:之後的記憶體用量,以位元組為單位 對 System.gc() 發出的呼叫。

    • Bazel bench 也會提供這項指標的基準。
    • 此外還有 peak-heap-sizemax-heap-sizeused-heap-sizecommitted-heap-size (請參閱 說明文件),但 較不相關。
  • BEPMemoryMetrics.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 會下載因 或是執行動作因此,網路頻寬可能會影響效能 建構容器

如果您要針對建構作業使用遠端執行功能,可以考慮採用 監控叫用期間的網路流量 來自 BEPNetworkMetrics.SystemNetworkStats proto (需要傳遞 --experimental_collect_system_network_usage)。

進一步瞭解 JSON 追蹤記錄設定檔 可讓您在建構過程中查看整個系統的網路用量 方法是將 --experimental_collect_system_network_usage 標記 (在 Bazel 新增) 6.0)。

含整個系統網路用量的設定檔

圖 3. 包含整個系統網路用量的設定檔。

使用遠端執行作業時,如果網路用量偏高,可能表示網路用量偏高 找出您建構的瓶頸如果尚未開始使用 考慮在不使用位元組的情況下啟用 Build --remote_download_minimal。 這麼做可以避免下載不必要的中繼成果,藉此加快建構速度。

另一個做法是 可節省的磁碟快取 下載頻寬。