Eksekusi Dinamis

Laporkan masalah Lihat sumber Per Malam · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Dynamic execution adalah fitur di Bazel tempat eksekusi lokal dan jarak jauh tindakan yang sama dimulai secara paralel, menggunakan output dari cabang pertama yang selesai, membatalkan cabang lainnya. Menggabungkan kemampuan eksekusi dan/atau cache bersama yang besar dari sistem build jarak jauh dengan eksekusinya, yang memberikan yang terbaik dari keduanya untuk build bersih dan inkremental sama.

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 Ringkasan 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, flag --dynamic_local_execution_delay menambahkan penundaan dalam milidetik ke eksekusi lokal setelah sistem jarak jauh mengindikasikan cache ditemukan. Tindakan ini akan menghindari eksekusi lokal yang berjalan saat lebih banyak cache ditemukan kemungkinan besar. Nilai defaultnya adalah 1.000 md, tetapi harus disesuaikan sedikit lebih lama dari yang biasanya dibutuhkan hit cache. Waktu sebenarnya bergantung pada remote sistem dan berapa lama waktu yang dibutuhkan untuk bolak-balik. Biasanya, nilainya akan sama untuk semua pengguna sistem jarak jauh tertentu, kecuali beberapa dari mereka berada cukup jauh untuk menambahkan latensi bolak-balik. Anda dapat menggunakan pembuatan profil Bazel untuk melihat berapa lama cache yang ditemukan.

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 pekerja. Di sistem Darwin dan Windows, sandbox strategi bisa jadi lambat; Anda dapat meneruskan --reuse_sandbox_directories untuk mengurangi overhead pembuatan {i>sandbox<i} pada 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 Blog yang luar biasa di Merino postingan

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 tidak ditemukan akan dianggap sebagai 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 bekerja cepat sehingga {i>overhead<i} eksekusi jarak jauh mendominasi waktu eksekusi. Sejak setiap tindakan yang dieksekusi secara lokal mengunci sejumlah sumber daya CPU dan memori, menjalankan tindakan yang tidak termasuk dalam kategori tersebut hanya akan menunda eksekusi bagi mereka yang memilikinya.

Per rilis 5.0.0-pre.20210708.4, pembuatan profil performa berisi data tentang eksekusi pekerja, termasuk waktu yang dihabiskan untuk menyelesaikan permintaan pekerjaan setelah kalah dalam proses eksekusi dinamis. Jika Anda melihat thread pekerja eksekusi dinamis menghabiskan banyak waktu untuk mendapatkan sumber daya, atau banyak waktu async-worker-finish, Anda mungkin memiliki beberapa tindakan lokal yang lambat sehingga menunda pekerja .

Membuat profil data dengan performa eksekusi dinamis yang buruk

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.

Membuat profil data dengan performa eksekusi dinamis yang lebih baik

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.

Performa

Pendekatan eksekusi dinamis mengasumsikan bahwa tersedia cukup sumber daya secara lokal dan jarak jauh, ada baiknya untuk menghabiskan beberapa sumber daya tambahan untuk meningkatkan performa keseluruhan. Tetapi penggunaan sumber daya yang berlebihan dapat memperlambat Bazel atau komputer yang menjalankannya, atau memberikan tekanan tak terduga pada sistem jarak jauh. Ada beberapa opsi untuk mengubah perilaku eksekusi dinamis:

--dynamic_local_execution_delay menunda dimulainya cabang lokal dengan angka dalam milidetik setelah cabang jarak jauh dimulai, tetapi hanya jika ada cache jarak jauh ditemukan selama build saat ini. Hal ini membuat build yang memberikan manfaat dari cache jarak jauh, tidak memboroskan sumber daya lokal ketika kemungkinan besar dapat ditemukan di cache. Tergantung pada kualitas cache, menguranginya dapat meningkatkan kecepatan build, tetapi harus menggunakan Google Cloud Platform.

--experimental_dynamic_local_load_factor adalah resource lanjutan eksperimental opsi pengelolaan otomatis. Dibutuhkan nilai dari 0 hingga 1, 0 untuk menonaktifkan fitur ini. Bila diatur ke nilai di atas 0, Bazel akan menyesuaikan jumlah tindakan terjadwal lokal ketika banyak tindakan menunggu dijadwalkan. Jika ditetapkan ke 1, tindakan yang dapat dijadwalkan sebanyak mungkin akan dapat dilakukan. berapa banyak CPU yang tersedia (berdasarkan --local_cpu_resources). Nilai yang lebih rendah menetapkan angka terjadwal agar lebih sedikit karena jumlah tindakan yang lebih tinggi yang tersedia untuk dijalankan. Ini mungkin terdengar kontra-intuitif, tetapi dengan {i>remote<i} yang bagus lokal, eksekusi lokal tidak banyak membantu ketika banyak tindakan yang sedang dijalankan, dan CPU lokal lebih baik digunakan untuk mengelola tindakan jarak jauh.

--experimental_dynamic_slow_remote_time memprioritaskan untuk memulai cabang lokal ketika {i>branch<i} jarak jauh telah berjalan setidaknya selama ini. Biasanya, tindakan yang dijadwalkan baru-baru ini akan diprioritaskan, karena tindakan ini memiliki peluang terbesar untuk memenangkan lomba, tetapi jika sistem jarak jauh terkadang macet atau memakan waktu lebih lama, ini bisa membuat sebuah build untuk bergerak maju. Ini tidak diaktifkan secara {i>default<i}, karena dapat menyembunyikan masalah dengan sistem jarak jauh yang harus diperbaiki. Pastikan untuk memantau performa sistem jarak jauh jika Anda mengaktifkan opsi ini.

--experimental_dynamic_ignore_local_signals dapat digunakan untuk mengizinkan remote mengambil alih ketika spawn lokal keluar karena adanya sinyal yang diberikan. Ini adalah terutama berguna bersama dengan batas resource worker (lihat --experimental_worker_memory_limit_mb, --experimental_worker_sandbox_hardening, dan --experimental_sandbox_memory_limit_mb)), di mana proses pekerja dapat dihentikan ketika mereka menggunakan terlalu banyak resource.

Profil rekaman aktivitas JSON berisi jumlah grafik yang berkaitan dengan kinerja yang dapat membantu mengidentifikasi cara untuk meningkatkan imbal balik performa dan penggunaan resource.

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 eksekusi dinamis yang dapat membantu men-{i>debug<i} masalah ini. Anda juga dapat menyesuaikan Flag --dynamic_local_execution_delay dan jumlah tugas jarak jauh vs. lokal yang membuatnya lebih mudah untuk merekonstruksi 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.