Dynamic execution adalah fitur di Bazel sejak versi 0.21, di mana eksekusi lokal dan jarak jauh dari tindakan yang sama dimulai secara paralel, menggunakan {i>output<i} dari cabang pertama yang selesai, membatalkan cabang yang lain . Alat ini menggabungkan kekuatan eksekusi dan/atau cache bersama yang besar dari remote dengan latensi rendah dalam eksekusi lokal, memberikan yang terbaik untuk build bersih dan inkremental.
Halaman ini menjelaskan cara mengaktifkan, menyesuaikan, dan men-debug eksekusi dinamis. Jika Anda menyiapkan eksekusi lokal dan jarak jauh dan mencoba menyesuaikan Bazel untuk performa yang lebih baik, halaman ini adalah untuk Anda. Jika Anda belum memiliki pengaturan eksekusi jarak jauh, buka Bazel Remote Execution Overview terlebih dahulu.
Mengaktifkan eksekusi dinamis?
Modul eksekusi dinamis adalah bagian dari Bazel, tetapi untuk memanfaatkan dalam eksekusinya, Anda harus sudah dapat mengompilasi baik secara lokal maupun jarak jauh dari pengaturan Bazel yang sama.
Untuk mengaktifkan modul eksekusi dinamis, teruskan --internal_spawn_scheduler
kepada Bazel. Tindakan ini menambahkan strategi eksekusi baru yang disebut dynamic
. Anda sekarang dapat
gunakan ini sebagai strategi untuk mnemonik yang ingin Anda jalankan secara dinamis, seperti
--strategy=Javac=dynamic
. Lihat bagian berikutnya untuk mengetahui cara memilih mnemonik
yang membutuhkan eksekusi dinamis.
Untuk semua mnemonik yang menggunakan strategi dinamis, strategi eksekusi jarak jauh
yang diambil dari flag --dynamic_remote_strategy
, dan strategi lokal dari flag
tanda --dynamic_local_strategy
. Lulus
--dynamic_local_strategy=worker,sandboxed
menetapkan default untuk lokal
cabang dari eksekusi dinamis untuk dicoba dengan pekerja atau eksekusi dalam sandbox
pesanan. Meneruskan --dynamic_local_strategy=Javac=worker
akan menggantikan default untuk
hanya mnemonik Javac. Versi jarak jauh berfungsi dengan cara yang sama. Kedua penanda dapat
ditentukan beberapa kali. Jika suatu tindakan tidak dapat dijalankan secara lokal,
dijalankan dari jarak jauh
seperti biasa, dan sebaliknya.
Jika sistem jarak jauh Anda memiliki cache, --local_execution_delay
flag menambahkan penundaan dalam milidetik ke eksekusi lokal setelah sistem jarak jauh
telah mengindikasikan cache ditemukan. Hal ini menghindari eksekusi lokal jika cache lebih banyak
besar. Nilai defaultnya adalah 1000 md, tetapi harus disesuaikan menjadi
sedikit lebih lama dari yang
biasanya dibutuhkan oleh hit cache. Waktu yang sebenarnya bergantung pada
sistem jarak jauh dan berapa lama
waktu yang dibutuhkan untuk pulang pergi. Biasanya, nilainya adalah
sama untuk semua pengguna dari sistem jarak jauh
tertentu, kecuali beberapa dari mereka cukup jauh
untuk menambah latensi bolak-balik. Anda dapat menggunakan
Fitur pembuatan profil Bazel
untuk melihat berapa lama waktu yang dibutuhkan
dengan hit cache biasa.
Eksekusi dinamis dapat digunakan dengan strategi
sandbox lokal serta dengan
pekerja persisten. Pekerja persisten akan
secara otomatis berjalan dengan {i>sandbox<i} bila
digunakan dengan eksekusi dinamis, dan tidak dapat
menggunakan pekerja multipleks. Pada sistem Darwin dan Windows,
strategi {i>sandbox <i}bisa jadi lambat; Anda bisa melewati
--reuse_sandbox_directories
untuk mengurangi overhead pembuatan sandbox di sistem ini.
Eksekusi dinamis juga dapat dijalankan dengan strategi standalone
, meskipun
Strategi standalone
harus mengambil kunci output saat mulai dieksekusi.
efektif menghalangi strategi jarak jauh
agar tidak selesai lebih dulu. Tujuan
Flag --experimental_local_lockfree_output
memungkinkan Anda mengatasi masalah ini dengan
memungkinkan eksekusi lokal untuk menulis
langsung ke {i>output<i}, tetapi dibatalkan oleh
eksekusi jarak jauh, jika
itu selesai terlebih dahulu.
Jika salah satu cabang dari eksekusi dinamis selesai lebih dahulu tetapi mengalami kegagalan, seluruh tindakan gagal. Ini adalah pilihan yang disengaja untuk mencegah perbedaan antara eksekusi lokal dan jarak jauh tidak diperhatikan.
Untuk latar belakang selengkapnya tentang cara kerja eksekusi dinamis dan pengunciannya, lihat Julio Merino yang luar biasa postingan blog
Kapan saya harus menggunakan eksekusi dinamis?
Eksekusi dinamis membutuhkan beberapa sistem eksekusi jarak jauh. Saat ini tidak sistem jarak jauh khusus cache, karena cache tidak ditemukan akan dianggap tindakan yang gagal.
Tidak semua jenis tindakan cocok untuk eksekusi jarak jauh. Terbaik kandidat adalah kandidat yang secara inheren lebih cepat secara lokal, misalnya melalui penggunaan pekerja persisten, atau mereka yang menjalankan cukup cepat sehingga {i>overhead<i} eksekusi jarak jauh mendominasi waktu eksekusi. Karena setiap tindakan yang dieksekusi secara lokal mengunci sejumlah CPU dan memori sumber daya, menjalankan tindakan yang tidak termasuk dalam kategori tersebut hanya akan menunda bagi mereka yang melakukannya.
Per rilis
5.0.0-pre.20210708.4,
pembuatan profil performa
berisi data tentang eksekusi pekerja, termasuk waktu yang dihabiskan untuk menyelesaikan pekerjaan
yang diminta setelah kalah dalam perlombaan eksekusi dinamis. Jika Anda melihat eksekusi dinamis
thread pekerja yang menghabiskan banyak waktu untuk mendapatkan resource, atau banyak waktu
di async-worker-finish
, Anda mungkin memiliki beberapa tindakan lokal lambat yang menunda
thread pekerja.
Pada profil di atas, yang menggunakan 8 pekerja Javac, kita melihat banyak pekerja Javac
setelah kalah dalam lomba dan menyelesaikan pekerjaannya di async-worker-finish
. Ini disebabkan oleh mnemonik non-pekerja yang mengambil cukup sumber daya untuk
menunda para pekerja.
Jika hanya Javac yang dijalankan dengan eksekusi dinamis, hanya sekitar setengah dari para pekerja akhirnya kalah dalam perlombaan setelah memulai pekerjaan mereka.
Flag --experimental_spawn_scheduler
yang sebelumnya direkomendasikan sudah tidak digunakan lagi.
Fitur ini mengaktifkan eksekusi dinamis dan menetapkan dynamic
sebagai strategi default untuk semua
yang sering kali menyebabkan
permasalahan seperti ini.
Pemecahan masalah
Masalah dengan eksekusi dinamis bisa halus dan sulit untuk di-debug, karena mereka dapat
manifes hanya pada beberapa kombinasi
tertentu dari eksekusi lokal dan jarak jauh.
--debug_spawn_scheduler
menambahkan output ekstra dari output 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 proses reproduksi masalah.
Jika Anda mengalami masalah dengan eksekusi dinamis menggunakan standalone
strategi, coba jalankan tanpa --experimental_local_lockfree_output
, atau jalankan
tindakan lokal Anda akan
di-sandbox. Ini mungkin sedikit memperlambat build Anda (lihat di atas jika
Anda menggunakan Mac atau Windows), tetapi menghapus
beberapa kemungkinan penyebab kegagalan.