細分建構效能

回報問題open_in_new 查看原始碼open_in_new 。 。 。 。 夜間 。 。 。 。 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：代表建構中建立的動作。 迴歸代表建構動作圖表的工作量較多注意事項 其中也包含可能尚未執行且未使用的動作。

   • 使用 aquery 對迴歸進行偵錯； 建議您先從 --output=summary敬上 再深入使用 --skyframe_state。

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 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。 這麼做可以避免下載不必要的中繼成果，藉此加快建構速度。

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