Eksekusi Dinamis

Laporkan masalah Lihat sumber

Eksekusi dinamis adalah fitur di Bazel yang memungkinkan eksekusi lokal dan jarak jauh atas tindakan yang sama dimulai secara paralel menggunakan output dari cabang pertama yang selesai, sehingga membatalkan cabang lainnya. Library ini menggabungkan daya eksekusi dan/atau cache bersama yang besar dari sistem build jarak jauh dengan latensi rendah eksekusi lokal, sehingga memberikan yang terbaik dari kedua dunia untuk build bersih dan inkremental yang serupa.

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 mendapatkan performa yang lebih baik, halaman ini cocok untuk Anda. Jika Anda belum menyiapkan eksekusi jarak jauh, buka Remote Execution Overview Bazel.

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 konfigurasi Bazel yang sama.

Untuk mengaktifkan modul eksekusi dinamis, teruskan flag --internal_spawn_scheduler ke Bazel. Tindakan ini menambahkan strategi eksekusi baru yang disebut dynamic. Kini Anda dapat menggunakan ini sebagai strategi untuk mnemonik yang ingin dijalankan secara dinamis, seperti --strategy=Javac=dynamic. Lihat bagian berikutnya untuk mengetahui cara memilih mnemonik yang akan diaktifkan untuk eksekusi dinamis.

Untuk mnemonik 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 akan menetapkan default untuk cabang lokal eksekusi dinamis yang akan dicoba dengan pekerja atau eksekusi dengan sandbox dalam urutan tersebut. Meneruskan --dynamic_local_strategy=Javac=worker akan menggantikan default untuk mnemonik Javac saja. Versi jarak jauh berfungsi dengan cara yang sama. Kedua flag dapat ditentukan beberapa kali. Jika suatu tindakan tidak dapat dijalankan secara lokal, tindakan tersebut akan dijalankan dari jarak jauh seperti biasa, dan sebaliknya.

Jika sistem jarak jauh Anda memiliki cache, tanda --dynamic_local_execution_delay menambahkan penundaan dalam milidetik ke eksekusi lokal setelah sistem jarak jauh menunjukkan cache ditemukan. Tindakan ini akan menghindari eksekusi lokal saat lebih banyak cache ditemukan. Nilai defaultnya adalah 1.000 md, tetapi harus disesuaikan agar sedikit lebih panjang daripada biasanya cache ditemukan. Waktu sebenarnya bergantung pada sistem jarak jauh dan berapa lama waktu yang dibutuhkan untuk pulang pergi. Biasanya, nilainya akan sama untuk semua pengguna sistem jarak jauh tertentu, kecuali jika beberapa dari mereka cukup jauh untuk menambahkan latensi bolak-balik. Anda dapat menggunakan fitur pembuatan profil Bazel untuk melihat berapa lama waktu yang diperlukan untuk mencapai cache pada umumnya.

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 yang di-sandbox mungkin berjalan lambat; Anda dapat meneruskan --reuse_sandbox_directories untuk mengurangi overhead pembuatan sandbox di sistem ini.

Eksekusi dinamis juga dapat dijalankan dengan strategi standalone. Namun, karena strategi standalone harus mengambil kunci output saat mulai dijalankan, strategi ini secara efektif memblokir strategi jarak jauh agar tidak selesai terlebih dahulu. Tanda --experimental_local_lockfree_output memungkinkan cara mengatasi masalah ini dengan mengizinkan eksekusi lokal menulis langsung ke output, tetapi dibatalkan oleh eksekusi jarak jauh, jika eksekusi tersebut selesai terlebih dahulu.

Jika salah satu cabang eksekusi dinamis selesai terlebih dahulu tetapi gagal, seluruh tindakan akan gagal. Hal ini adalah pilihan yang disengaja agar perbedaan antara eksekusi lokal dan jarak jauh tidak terlihat.

Untuk 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, penggunaan sistem jarak jauh khusus cache tidak dapat dilakukan, karena cache yang tidak ditemukan akan dianggap sebagai tindakan yang gagal.

Tidak semua jenis tindakan cocok untuk eksekusi jarak jauh. Kandidat terbaik adalah yang secara inheren lebih cepat secara lokal, misalnya melalui penggunaan pekerja persisten, atau yang berjalan cukup cepat sehingga overhead eksekusi jarak jauh mendominasi waktu eksekusi. Karena setiap tindakan yang dieksekusi secara lokal mengunci sejumlah resource CPU dan memori, menjalankan tindakan yang tidak termasuk dalam kategori tersebut hanya akan menunda eksekusi untuk tindakan yang melakukannya.

Mulai rilis 5.0.0-pre.20210708.4, pembuatan profil performa berisi data tentang eksekusi pekerja, termasuk waktu yang dihabiskan untuk menyelesaikan permintaan pekerjaan setelah kehilangan race 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.

Membuat profil data dengan performa eksekusi dinamis yang buruk

Dalam profil di atas, yang menggunakan 8 pekerja Javac, kita melihat banyak pekerja Javac yang kalah dalam balapan dan menyelesaikan pekerjaan mereka di thread async-worker-finish. Hal ini disebabkan oleh mnemonik non-pekerja yang mengambil cukup resource untuk menunda pekerja.

Membuat profil data dengan performa eksekusi dinamis yang lebih baik

Jika hanya Javac yang dijalankan dengan eksekusi dinamis, hanya sekitar setengah pekerja yang memulai yang akhirnya kalah dalam race setelah memulai pekerjaan mereka.

Flag --experimental_spawn_scheduler yang direkomendasikan sebelumnya tidak digunakan lagi. Tindakan ini akan mengaktifkan eksekusi dinamis dan menetapkan dynamic sebagai strategi default untuk semua mnemonik, yang sering kali menyebabkan masalah semacam ini.

Performa

Pendekatan eksekusi dinamis mengasumsikan ada cukup resource yang tersedia secara lokal dan jarak jauh, sehingga ada baiknya menghabiskan beberapa resource tambahan untuk meningkatkan performa secara keseluruhan. Namun, penggunaan resource yang berlebihan dapat memperlambat Bazel itu sendiri atau mesin yang menjalankannya, atau memberikan tekanan yang tidak terduga pada sistem jarak jauh. Ada beberapa opsi untuk mengubah perilaku eksekusi dinamis:

--dynamic_local_execution_delay menunda awal cabang lokal selama beberapa milidetik setelah cabang jarak jauh dimulai, tetapi hanya jika telah terjadi cache jarak jauh selama build saat ini. Hal ini membuat build yang mendapatkan manfaat dari cache jarak jauh tidak menyia-nyiakan resource lokal jika sebagian besar output dapat ditemukan di cache. Bergantung pada kualitas cache, mengurangi jumlah ini dapat meningkatkan kecepatan build, tetapi akan mengorbankan penggunaan lebih banyak resource lokal.

--experimental_dynamic_local_load_factor adalah opsi pengelolaan resource lanjutan eksperimental. Dibutuhkan nilai dari 0 hingga 1, 0 untuk menonaktifkan fitur ini. Jika ditetapkan ke nilai di atas 0, Bazel akan menyesuaikan jumlah tindakan yang dijadwalkan secara lokal saat banyak tindakan menunggu dijadwalkan. Menyetelnya ke 1 memungkinkan jumlah tindakan dijadwalkan sebanyak CPU yang tersedia (per --local_cpu_resources). Nilai yang lebih rendah akan menetapkan jumlah tindakan yang dijadwalkan menjadi lebih sedikit karena jumlah tindakan yang lebih tinggi tersedia untuk dijalankan. Hal ini mungkin terdengar kontra-intuitif, tetapi dengan sistem jarak jauh yang baik, eksekusi lokal tidak banyak membantu ketika banyak tindakan sedang dijalankan, dan CPU lokal lebih baik digunakan untuk mengelola tindakan jarak jauh.

--experimental_dynamic_slow_remote_time memprioritaskan permulaan cabang lokal saat cabang jarak jauh sudah berjalan setidaknya selama ini. Biasanya, tindakan yang paling baru dijadwalkan akan diprioritaskan karena memiliki peluang terbesar untuk memenangkan perlombaan, tetapi jika sistem jarak jauh terkadang mengalami hang atau membutuhkan waktu sangat lama, hal ini dapat membuat build tetap berjalan. Opsi ini tidak diaktifkan secara default, karena dapat menyembunyikan masalah pada sistem jarak jauh yang sebaiknya diperbaiki. Pastikan untuk memantau performa sistem jarak jauh jika Anda mengaktifkan opsi ini.

--experimental_dynamic_ignore_local_signals dapat digunakan untuk memungkinkan cabang jarak jauh mengambil alih saat spawn lokal keluar karena sinyal tertentu. Hal ini sangat berguna bersama dengan batas resource pekerja (lihat --experimental_worker_memory_limit_mb, --experimental_worker_sandbox_hardening, dan --experimental_sandbox_memory_limit_mb)), ketika proses pekerja dapat dihentikan jika menggunakan terlalu banyak resource.

Profil rekaman aktivitas JSON berisi sejumlah grafik terkait performa yang dapat membantu mengidentifikasi cara meningkatkan kompromi performa dan penggunaan resource.

Pemecahan masalah

Masalah pada eksekusi dinamis bisa jadi sulit di-debug, karena masalah tersebut hanya dapat muncul dalam 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 pekerjaan jarak jauh vs. lokal untuk memudahkan 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. Tindakan ini dapat sedikit memperlambat build (lihat di atas jika Anda menggunakan Mac atau Windows), tetapi akan menghilangkan beberapa kemungkinan penyebab kegagalan.