Bazel bersifat kompleks dan melakukan banyak hal yang berbeda selama build, beberapa di antaranya dapat memengaruhi performa build. Halaman ini mencoba memetakan beberapa konsep Bazel ini dengan implikasinya terhadap performa build. Meskipun tidak luas, kami telah menyertakan beberapa contoh cara mendeteksi masalah performa build melalui ekstraksi metrik dan tindakan yang dapat Anda lakukan untuk memperbaikinya. Dengan demikian, kami harap Anda dapat menerapkan konsep ini saat menyelidiki regresi performa build.
Build bersih vs. Inkremental
Build bersih adalah build yang membangun semuanya dari awal, sedangkan build inkremental menggunakan kembali beberapa pekerjaan yang sudah selesai.
Sebaiknya lihat build bersih dan inkremental secara terpisah, terutama saat Anda mengumpulkan / menggabungkan metrik yang bergantung pada status cache Bazel (misalnya, metrik ukuran permintaan build). Keduanya juga merepresentasikan dua pengalaman pengguna yang berbeda. Dibandingkan dengan memulai build bersih dari awal (yang membutuhkan waktu lebih lama karena cache dingin), build inkremental terjadi jauh lebih sering saat developer melakukan iterasi pada kode (biasanya lebih cepat karena cache biasanya sudah hangat).
Anda dapat menggunakan kolom CumulativeMetrics.num_analyses di BEP untuk mengklasifikasikan
build. Jika num_analyses <= 1, ini adalah build bersih; jika tidak, kita dapat secara luas
mengategorikannya sebagai build inkremental - pengguna mungkin telah beralih
ke flag atau target yang berbeda yang menyebabkan build bersih. Definisi
inkrementalitas yang lebih ketat kemungkinan harus berupa
heuristik, misalnya melihat jumlah paket yang dimuat
(PackageMetrics.packages_loaded).
Metrik build determenistik sebagai proxy untuk performa build
Mengukur performa build dapat menjadi sulit karena sifat non-determenistik metrik tertentu (misalnya waktu CPU atau waktu antrean Bazel di cluster jarak jauh). Dengan demikian, sebaiknya gunakan metrik determenistik sebagai proxy untuk jumlah pekerjaan yang dilakukan oleh Bazel, yang pada akhirnya memengaruhi performanya.
Ukuran permintaan build dapat memiliki implikasi yang signifikan terhadap performa build. Build yang lebih besar dapat mewakili lebih banyak pekerjaan dalam menganalisis dan membuat grafik build. Pertumbuhan organik build terjadi secara alami seiring pengembangan, karena semakin banyak dependensi yang ditambahkan/dibuat, sehingga kompleksitasnya meningkat dan menjadi lebih mahal untuk dibangun.
Kita dapat memecah masalah ini ke dalam berbagai fase build, dan menggunakan metrik berikut sebagai metrik proxy untuk pekerjaan yang dilakukan di setiap fase:
PackageMetrics.packages_loaded: jumlah paket yang berhasil dimuat. Regresi di sini menunjukkan lebih banyak pekerjaan yang perlu dilakukan untuk membaca dan mengurai setiap file BUILD tambahan dalam fase pemuatan.TargetMetrics.targets_configured: mewakili jumlah target dan aspek yang dikonfigurasi dalam build. Regresi mewakili lebih banyak pekerjaan dalam membuat dan melintasi grafik target yang dikonfigurasi.- Hal ini sering kali disebabkan oleh penambahan dependensi dan harus membuat grafik penutupan transitifnya.
- Gunakan cquery untuk menemukan di mana dependensi baru mungkin telah ditambahkan.
ActionSummary.actions_created: merepresentasikan tindakan yang dibuat dalam build, dan regresi merepresentasikan lebih banyak pekerjaan dalam membuat grafik tindakan. Perhatikan bahwa hal ini juga mencakup tindakan yang tidak digunakan yang mungkin belum dieksekusi.- Gunakan aquery untuk men-debug regresi;
sebaiknya mulai dengan
--output=summarysebelum menelusuri lebih lanjut dengan--skyframe_state.
- Gunakan aquery untuk men-debug regresi;
sebaiknya mulai dengan
ActionSummary.actions_executed: jumlah tindakan yang dijalankan, regresi secara langsung menunjukkan lebih banyak pekerjaan dalam menjalankan tindakan ini.- BEP menulis statistik tindakan
ActionDatayang menunjukkan jenis tindakan yang paling banyak dijalankan. Secara default, BEP mengumpulkan 20 jenis tindakan teratas, tetapi Anda dapat meneruskan--experimental_record_metrics_for_all_mnemonicsuntuk mengumpulkan data ini untuk semua jenis tindakan yang dijalankan. - Hal ini akan membantu Anda mengetahui jenis tindakan yang dijalankan (sebagai tambahan).
- BEP menulis statistik tindakan
BuildGraphSummary.outputArtifactCount: jumlah artefak yang dibuat oleh tindakan yang dijalankan.- Jika jumlah tindakan yang dijalankan tidak meningkat, kemungkinan implementasi aturan telah diubah.
Semua metrik ini dipengaruhi oleh status cache lokal, sehingga Anda harus memastikan bahwa build tempat Anda mengekstrak metrik ini adalah build bersih.
Kami melihat bahwa regresi dalam salah satu metrik ini dapat disertai dengan regresi dalam waktu proses, waktu CPU, dan penggunaan memori.
Penggunaan resource lokal
Bazel menggunakan berbagai resource di mesin lokal Anda (baik untuk menganalisis grafik build dan mendorong eksekusi, maupun untuk menjalankan tindakan lokal). Hal ini dapat memengaruhi performa / ketersediaan mesin Anda dalam melakukan build, dan juga tugas lainnya.
Waktu yang dihabiskan
Mungkin metrik yang paling rentan terhadap derau (dan dapat sangat bervariasi dari build
ke build) adalah waktu; khususnya - waktu proses, waktu CPU, dan waktu sistem. Anda dapat
menggunakan bazel-bench untuk mendapatkan
benchmark untuk metrik ini, dan dengan jumlah --runs yang memadai, Anda dapat
meningkatkan signifikansi statistik pengukuran.
Waktu proses adalah waktu dunia nyata yang telah berlalu.
- Jika hanya waktu proses yang mengalami regresi, sebaiknya kumpulkan profil trace JSON dan cari perbedaannya. Jika tidak, sebaiknya Anda menyelidiki metrik regresi lainnya karena metrik tersebut dapat memengaruhi waktu proses.
Waktu CPU adalah waktu yang dihabiskan oleh CPU untuk mengeksekusi kode pengguna.
- Jika waktu CPU mengalami regresi di dua commit project, sebaiknya kumpulkan
profil CPU Starlark. Anda mungkin juga harus menggunakan
--nobuilduntuk membatasi build ke fase analisis karena sebagian besar pekerjaan berat CPU dilakukan di sana.
- Jika waktu CPU mengalami regresi di dua commit project, sebaiknya kumpulkan
profil CPU Starlark. Anda mungkin juga harus menggunakan
Waktu sistem adalah waktu yang dihabiskan oleh CPU di kernel.
- Jika waktu sistem mengalami regresi, hal ini sebagian besar berkorelasi dengan I/O saat Bazel membaca file dari sistem file Anda.
Pembuatan profil beban di seluruh sistem
Dengan menggunakan flag
--experimental_collect_load_average_in_profiler
yang diperkenalkan di Bazel 6.0, profiler trace JSON mengumpulkan
rata-rata beban sistem selama pemanggilan.
Gambar 1. Profil yang mencakup rata-rata beban sistem.
Beban yang tinggi selama pemanggilan Bazel dapat menjadi indikasi bahwa Bazel menjadwalkan
terlalu banyak tindakan lokal secara paralel untuk mesin Anda. Sebaiknya pertimbangkan untuk
menyesuaikan
--local_cpu_resources
dan --local_ram_resources,
terutama di lingkungan container (setidaknya hingga
#16512 digabungkan).
Memantau penggunaan memori Bazel
Ada dua sumber utama untuk mendapatkan penggunaan memori Bazel, info Bazel dan
BEP.
bazel info used-heap-size-after-gc: Jumlah memori yang digunakan dalam byte setelah panggilan keSystem.gc().- Bazel bench juga memberikan tolok ukur untuk metrik ini.
- Selain itu, ada
peak-heap-size,max-heap-size,used-heap-sizedancommitted-heap-size(lihat dokumentasi), tetapi kurang relevan.
MemoryMetrics.peak_post_gc_heap_sizeBEP: Ukuran puncak heap JVM dalam byte setelah GC (memerlukan setelan--memory_profileyang mencoba memaksa GC penuh).
Regresi dalam penggunaan memori biasanya merupakan akibat dari regresi dalam metrik ukuran permintaan build, yang sering kali disebabkan oleh penambahan dependensi atau perubahan dalam penerapan aturan.
Untuk menganalisis jejak memori Bazel pada tingkat yang lebih terperinci, sebaiknya gunakan profiler memori bawaan untuk aturan.
Pembuatan profil memori worker persisten
Meskipun worker persisten dapat membantu mempercepat build
secara signifikan (terutama untuk bahasa pemrograman tafsiran), jejak memorinya dapat
bermasalah. Bazel mengumpulkan metrik pada worker-nya, khususnya, kolom WorkerMetrics.WorkerStats.worker_memory_in_kb yang menunjukkan jumlah memori
yang digunakan worker (dengan mnemonik).
Profiler trace JSON juga mengumpulkan penggunaan memori worker persisten selama pemanggilan dengan meneruskan flag --experimental_collect_system_network_usage (baru di Bazel 6.0).
Gambar 2. Profil yang mencakup penggunaan memori pekerja.
Menurunkan nilai
--worker_max_instances
(default 4) dapat membantu mengurangi
jumlah memori yang digunakan oleh worker persisten. Kami sedang berupaya secara aktif untuk membuat pengelola resource dan penjadwal Bazel lebih cerdas sehingga penyesuaian seperti ini akan lebih jarang diperlukan pada masa mendatang.
Memantau traffic jaringan untuk build jarak jauh
Dalam eksekusi jarak jauh, Bazel mendownload artefak yang dibuat sebagai hasil dari mengeksekusi tindakan. Dengan demikian, bandwidth jaringan Anda dapat memengaruhi performa build Anda.
Jika menggunakan eksekusi jarak jauh untuk build, Anda dapat mempertimbangkan untuk memantau traffic jaringan selama pemanggilan menggunakan proto NetworkMetrics.SystemNetworkStats dari BEP (memerlukan penerusan --experimental_collect_system_network_usage).
Selain itu, profil trace JSON
memungkinkan Anda melihat penggunaan jaringan seluruh sistem selama proses build
dengan meneruskan flag --experimental_collect_system_network_usage (baru di Bazel
6.0).
Gambar 3. Profil yang mencakup penggunaan jaringan di seluruh sistem.
Penggunaan jaringan yang tinggi tetapi agak datar saat menggunakan eksekusi jarak jauh dapat menunjukkan bahwa jaringan adalah bottleneck dalam build Anda. Pertimbangkan untuk mengaktifkan Build tanpa Byte dengan meneruskan --remote_download_minimal, jika Anda belum menggunakannya.
Tindakan ini akan mempercepat build Anda dengan menghindari download artefak perantara yang tidak diperlukan.
Opsi lainnya adalah mengonfigurasi cache disk lokal untuk menghemat bandwidth download.