Eksekusi dinamis adalah fitur di Bazel sejak versi 0.21, dengan eksekusi lokal dan jarak jauh dari tindakan yang sama dimulai secara paralel, menggunakan output dari cabang pertama yang selesai, membatalkan cabang lainnya. Hal ini menggabungkan daya eksekusi dan/atau cache bersama yang besar dari sistem build jarak jauh dengan latensi rendah dari eksekusi lokal, sehingga memberikan yang terbaik dari kedua dunia untuk build bersih dan inkremental.
Halaman ini menjelaskan cara mengaktifkan, menyesuaikan, dan men-debug eksekusi dinamis. Jika Anda telah menyiapkan eksekusi lokal dan jarak jauh serta mencoba menyesuaikan setelan Bazel untuk performa yang lebih baik, halaman ini ditujukan untuk Anda. Jika Anda belum menyiapkan eksekusi jarak jauh, buka Ringkasan Eksekusi Jarak Jauh Bazel terlebih dahulu.
Mengaktifkan eksekusi dinamis?
Modul eksekusi dinamis adalah bagian dari Bazel, tetapi untuk memanfaatkan eksekusi dinamis, Anda harus sudah dapat mengompilasi secara lokal dan jarak jauh dari penyiapan Bazel yang sama.
Untuk mengaktifkan modul eksekusi dinamis, teruskan tanda --internal_spawn_scheduler
ke Bazel. Tindakan ini akan menambahkan strategi eksekusi baru yang disebut dynamic. Sekarang Anda dapat
menggunakannya sebagai strategi untuk mnemonik yang ingin Anda jalankan secara dinamis, seperti
--strategy=Javac=dynamic. Lihat bagian berikutnya untuk mengetahui cara memilih mnemonik yang akan diaktifkan untuk eksekusi dinamis.
Untuk mnemonik apa pun yang menggunakan strategi dinamis, strategi eksekusi jarak jauh diambil dari flag --dynamic_remote_strategy, dan strategi lokal dari flag --dynamic_local_strategy. Meneruskan
--dynamic_local_strategy=worker,sandboxed menetapkan default untuk
cabang eksekusi dinamis lokal agar mencoba dengan pekerja atau eksekusi sandbox dalam urutan tersebut. Penerusan --dynamic_local_strategy=Javac=worker akan menggantikan default untuk
mnemonic Javac saja. Versi jarak jauh berfungsi dengan cara yang sama. Kedua tanda dapat
ditentukan beberapa kali. Jika tindakan tidak dapat dieksekusi secara lokal, tindakan tersebut akan dieksekusi dari jarak jauh seperti biasa, dan sebaliknya.
Jika sistem jarak jauh Anda memiliki cache, tanda --local_execution_delay
akan menambahkan penundaan dalam milidetik pada eksekusi lokal setelah sistem jarak jauh
menunjukkan hit cache. Hal ini menghindari eksekusi lokal saat lebih banyak cache
hit cenderung terjadi. Nilai defaultnya adalah 1000 md, tetapi harus disesuaikan agar sedikit lebih lama dari waktu yang biasanya diperlukan untuk cache ditemukan. Waktu sebenarnya bergantung pada sistem jarak jauh dan durasi perjalanan pulang pergi. Biasanya, nilai akan sama untuk semua pengguna sistem jarak jauh tertentu, kecuali beberapa di antaranya cukup jauh untuk menambahkan latensi pulang pergi. Anda dapat menggunakan
fitur pembuatan profil Bazel
untuk melihat berapa lama waktu yang dibutuhkan untuk hit cache umum.
Eksekusi dinamis dapat digunakan dengan strategi sandbox lokal serta dengan
pekerja persisten. Pekerja persisten akan otomatis berjalan dengan sandbox saat digunakan dengan eksekusi dinamis, dan tidak dapat menggunakan multiplex worker. Pada sistem Darwin dan Windows, strategi sandbox dapat berjalan lambat; Anda dapat meneruskan --reuse_sandbox_directories untuk mengurangi overhead pembuatan sandbox di sistem ini.
Eksekusi dinamis juga dapat berjalan dengan strategi standalone, meskipun karena strategi
standalone harus mengambil kunci output saat mulai dieksekusi, strategi ini
secara efektif mencegah strategi jarak jauh selesai terlebih dahulu. Flag
--experimental_local_lockfree_output memungkinkan cara untuk mengatasi masalah ini dengan
mengizinkan eksekusi lokal menulis langsung ke output, tetapi dibatalkan oleh
eksekusi jarak jauh, jika eksekusi jarak jauh selesai terlebih dahulu.
Jika salah satu cabang eksekusi dinamis selesai terlebih dahulu tetapi gagal, seluruh tindakan akan gagal. Ini adalah pilihan yang disengaja untuk mencegah perbedaan antara eksekusi lokal dan jarak jauh tidak diketahui.
Untuk mengetahui latar belakang selengkapnya tentang cara kerja eksekusi dinamis dan pengunciannya, lihat postingan blog Julio Merino yang sangat bagus.
Kapan saya harus menggunakan eksekusi dinamis?
Eksekusi dinamis memerlukan beberapa bentuk sistem eksekusi jarak jauh. Saat ini tidak mungkin menggunakan sistem jarak jauh khusus cache, karena cache yang tidak ditemukan akan dianggap sebagai tindakan yang gagal.
Tidak semua jenis tindakan cocok untuk eksekusi jarak jauh. Kandidat terbaik adalah kandidat yang secara inheren lebih cepat secara lokal, misalnya melalui penggunaan pekerja persisten, atau kandidat yang berjalan cukup cepat sehingga overhead eksekusi jarak jauh mendominasi waktu eksekusi. Karena setiap tindakan yang dijalankan secara lokal mengunci sejumlah resource CPU dan memori, menjalankan tindakan yang tidak termasuk dalam kategori tersebut hanya menunda eksekusi tindakan yang termasuk dalam kategori tersebut.
Mulai rilis
5.0.0-pre.20210708.4,
profil performa
berisi data tentang eksekusi pekerja, termasuk waktu yang dihabiskan untuk menyelesaikan permintaan kerja
setelah kalah dalam persaingan eksekusi dinamis. Jika Anda melihat thread pekerja eksekusi dinamis menghabiskan banyak waktu untuk mendapatkan resource, atau banyak waktu di async-worker-finish, Anda mungkin memiliki beberapa tindakan lokal yang lambat yang menunda thread pekerja.
Dalam profil di atas, yang menggunakan 8 pekerja Javac, kita melihat banyak pekerja Javac yang kalah dalam persaingan dan menyelesaikan pekerjaannya di thread async-worker-finish. Hal ini disebabkan oleh mnemonik non-worker yang menggunakan resource yang cukup untuk menunda pekerja.
Jika hanya Javac yang dijalankan dengan eksekusi dinamis, hanya sekitar setengah dari pekerja yang memulai tugasnya yang kalah setelah memulai tugasnya.
Bendera --experimental_spawn_scheduler yang sebelumnya direkomendasikan tidak digunakan lagi.
Hal ini mengaktifkan eksekusi dinamis dan menetapkan dynamic sebagai strategi default untuk semua
mnemonik, yang sering kali menyebabkan masalah semacam ini.
Pemecahan masalah
Masalah pada eksekusi dinamis bisa sulit dideteksi dan di-debug, karena hanya dapat
terjadi pada beberapa kombinasi spesifik eksekusi lokal dan jarak jauh.
--debug_spawn_scheduler menambahkan output ekstra dari sistem eksekusi dinamis yang dapat membantu men-debug masalah ini. Anda juga dapat menyesuaikan flag
--local_execution_delay dan jumlah tugas jarak jauh vs. lokal
untuk mempermudah mereproduksi masalah.
Jika Anda mengalami masalah dengan eksekusi dinamis menggunakan strategi standalone, coba jalankan tanpa --experimental_local_lockfree_output, atau jalankan tindakan lokal Anda dalam sandbox. Hal ini mungkin memperlambat build Anda sedikit (lihat di atas jika Anda menggunakan Mac atau Windows), tetapi menghilangkan beberapa kemungkinan penyebab kegagalan.