Eksekusi dinamis adalah fitur di Bazel yang memungkinkan eksekusi lokal dan jarak jauh dari tindakan yang sama dimulai secara paralel, menggunakan output dari cabang pertama yang selesai, dan membatalkan cabang lainnya. Fitur 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. Penerusan
--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 --dynamic_local_execution_delay
akan menambahkan penundaan dalam milidetik pada eksekusi lokal setelah sistem jarak jauh
menunjukkan hit cache. Hal ini menghindari eksekusi lokal saat kemungkinan lebih banyak hit cache. 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 jika beberapa di antaranya cukup jauh
untuk menambahkan latensi pulang pergi. Anda dapat menggunakan fitur pembuatan profil Bazel untuk melihat durasi hit cache standar.
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 pekerja
multiplex. 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 memblokir strategi jarak jauh agar tidak 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, Anda tidak dapat menggunakan sistem jarak jauh khusus cache, karena cache miss 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 untuk tindakan yang termasuk dalam kategori tersebut.
Mulai rilis
5.0.0-pre.20210708.4,
pemrofilan 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.
Performa
Pendekatan eksekusi dinamis mengasumsikan bahwa ada cukup resource yang tersedia secara lokal dan jarak jauh sehingga layak untuk membelanjakan beberapa resource tambahan guna meningkatkan performa secara keseluruhan. Namun, penggunaan resource yang berlebihan dapat memperlambat Bazel itu sendiri atau mesin tempat Bazel berjalan, atau memberikan tekanan yang tidak terduga pada sistem jarak jauh. Ada beberapa opsi untuk mengubah perilaku eksekusi dinamis:
--dynamic_local_execution_delay menunda dimulainya cabang lokal dengan sejumlah
milidetik setelah cabang jarak jauh dimulai, tetapi hanya jika ada
hit cache jarak jauh selama build saat ini. Hal ini membuat build yang diuntungkan
dari caching jarak jauh tidak membuang-buang resource lokal saat kemungkinan besar
sebagian besar output dapat ditemukan di cache. Bergantung pada kualitas cache, mengurangi hal ini dapat meningkatkan kecepatan build, dengan biaya penggunaan lebih banyak resource lokal.
--experimental_dynamic_local_load_factor adalah opsi pengelolaan resource lanjutan eksperimental. Nilainya berkisar dari 0 hingga 1, dengan 0 menonaktifkan fitur ini.
Jika ditetapkan ke nilai di atas 0, Bazel akan menyesuaikan jumlah
tindakan yang dijadwalkan secara lokal saat banyak tindakan menunggu
untuk dijadwalkan. Menyetelnya ke 1 memungkinkan sebanyak mungkin tindakan dijadwalkan sesuai dengan jumlah CPU yang tersedia (sesuai dengan --local_cpu_resources). Nilai yang lebih rendah menetapkan jumlah tindakan yang dijadwalkan menjadi lebih sedikit karena jumlah tindakan yang lebih tinggi tersedia untuk dijalankan. Mungkin ini terdengar berlawanan dengan intuisi, tetapi dengan sistem jarak jauh yang baik, eksekusi lokal tidak banyak membantu saat banyak tindakan sedang dijalankan, dan CPU lokal lebih baik digunakan untuk mengelola tindakan jarak jauh.
--experimental_dynamic_slow_remote_time memprioritaskan memulai cabang lokal
jika cabang jarak jauh telah berjalan setidaknya selama ini. Biasanya, tindakan yang dijadwalkan paling baru akan mendapatkan prioritas, karena memiliki peluang terbesar untuk memenangkan persaingan, tetapi jika sistem jarak jauh terkadang mengalami error atau membutuhkan waktu yang sangat lama, hal ini dapat membuat build berjalan. Fitur ini tidak diaktifkan secara default, karena dapat menyembunyikan masalah pada sistem jarak jauh yang seharusnya diperbaiki. Pastikan
untuk memantau performa sistem jarak jauh Anda jika Anda mengaktifkan opsi ini.
--experimental_dynamic_ignore_local_signals dapat digunakan untuk memungkinkan cabang jarak jauh mengambil alih saat proses lokal keluar karena sinyal tertentu. Hal ini
terutama berguna bersama dengan batas resource pekerja (lihat
--experimental_worker_memory_limit_mb,
--experimental_worker_sandbox_hardening,
dan
--experimental_sandbox_memory_limit_mb)),
dengan proses pekerja dapat dihentikan jika menggunakan terlalu banyak resource.
Profil rekaman aktivitas JSON berisi sejumlah grafik terkait performa yang dapat membantu mengidentifikasi cara meningkatkan keseimbangan antara performa dan penggunaan resource.
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 tambahan dari sistem eksekusi dinamis yang dapat membantu men-debug masalah ini. Anda juga dapat menyesuaikan tanda --dynamic_local_execution_delay dan jumlah tugas jarak jauh vs. tugas 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 dapat memperlambat build Anda sedikit (lihat di atas jika Anda menggunakan Mac atau Windows), tetapi menghilangkan beberapa kemungkinan penyebab kegagalan.