Men-debug Hit Cache Jarak Jauh untuk Eksekusi Jarak Jauh

Laporkan masalah Lihat sumber Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Halaman ini menjelaskan cara memeriksa rasio hit cache dan cara menyelidiki cache yang tidak ditemukan dalam konteks eksekusi jarak jauh.

Halaman ini mengasumsikan bahwa Anda memiliki build dan/atau pengujian yang berhasil menggunakan eksekusi jarak jauh, dan Anda ingin memastikan bahwa Anda secara efektif menggunakan cache jarak jauh.

Memeriksa rasio hit cache

Pada output standar dari operasi Bazel, lihat baris INFO yang mencantumkan proses, yang kira-kira sesuai dengan tindakan Bazel. Baris tersebut menjelaskan tempat tindakan dijalankan. Cari label remote, yang menunjukkan tindakan yang dijalankan dari jarak jauh, linux-sandbox untuk tindakan yang dijalankan di sandbox lokal, dan nilai lainnya untuk strategi eksekusi lainnya. Tindakan yang hasilnya berasal dari cache jarak jauh ditampilkan sebagai remote cache hit.

Contoh:

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

Dalam contoh ini, ada 6 hit cache jarak jauh, dan 2 tindakan tidak memiliki hit cache dan dieksekusi dari jarak jauh. 3 bagian internal dapat diabaikan. Biasanya, ini adalah tindakan internal kecil, seperti membuat link simbolis. Hit cache lokal tidak disertakan dalam ringkasan ini. Jika Anda mendapatkan 0 proses (atau angka yang lebih rendah dari yang diharapkan), jalankan bazel clean, diikuti dengan perintah build/pengujian Anda.

Memecahkan masalah hit cache

Jika Anda tidak mendapatkan rasio hit cache yang diharapkan, lakukan hal berikut:

Memastikan menjalankan kembali perintah build/pengujian yang sama menghasilkan hit cache

  1. Jalankan build dan/atau pengujian yang Anda harapkan untuk mengisi cache. Saat pertama kali build baru dijalankan di stack tertentu, Anda tidak akan melihat hit cache jarak jauh. Sebagai bagian dari eksekusi jarak jauh, hasil tindakan disimpan dalam cache dan operasi berikutnya harus mengambilnya.

  2. Jalankan bazel clean. Perintah ini akan membersihkan cache lokal, yang memungkinkan Anda menyelidiki hit cache jarak jauh tanpa hasil yang disamarkan oleh hit cache lokal.

  3. Jalankan build dan pengujian yang Anda selidiki lagi (di mesin yang sama).

  4. Periksa baris INFO untuk mengetahui rasio hit cache. Jika Anda tidak melihat proses kecuali remote cache hit dan internal, berarti cache Anda diisi dan diakses dengan benar. Jika demikian, lanjutkan ke bagian berikutnya.

  5. Sumber perbedaan yang mungkin terjadi adalah sesuatu yang tidak hermetis dalam build yang menyebabkan tindakan menerima kunci tindakan yang berbeda di kedua operasi. Untuk menemukan tindakan tersebut, lakukan hal berikut:

    a. Jalankan kembali build atau pengujian yang dimaksud untuk mendapatkan log eksekusi:

      bazel clean
      bazel --optional-flags build //your:target --execution_log_compact_file=/tmp/exec1.log
    

    b. Bandingkan log eksekusi antara kedua operasi. Pastikan tindakannya sama di kedua file log. Perbedaan memberikan petunjuk tentang perubahan yang terjadi di antara operasi. Perbarui build Anda untuk menghilangkan perbedaan tersebut.

    Jika Anda dapat menyelesaikan masalah penyimpanan dalam cache dan sekarang pengulangan proses menghasilkan semua hit cache, lanjutkan ke bagian berikutnya.

    Jika ID tindakan Anda sama tetapi tidak ada hit cache, berarti ada sesuatu dalam konfigurasi Anda yang mencegah penyimpanan dalam cache. Lanjutkan ke bagian ini untuk memeriksa masalah umum.

  6. Pastikan semua tindakan dalam log eksekusi memiliki cacheable yang ditetapkan ke benar. Jika cacheable tidak muncul dalam log eksekusi untuk tindakan tertentu, itu berarti aturan yang sesuai mungkin memiliki tag no-cache dalam definisinya di file BUILD. Lihat kolom mnemonic dan target_label dalam log eksekusi untuk membantu menentukan asal tindakan tersebut.

  7. Jika tindakannya identik dan cacheable, tetapi tidak ada hit cache, mungkin command line Anda menyertakan --noremote_accept_cached yang akan menonaktifkan pencarian cache untuk build.

    Jika sulit untuk mengetahui command line yang sebenarnya, gunakan command line kanonik dari Build Event Protocol sebagai berikut:

    a. Tambahkan --build_event_text_file=/tmp/bep.txt ke perintah Bazel Anda untuk mendapatkan versi teks log.

    b. Buka versi teks log dan telusuri pesan structured_command_line dengan command_line_label: "canonical". Opsi ini akan mencantumkan semua opsi setelah diperluas.

    c. Telusuri remote_accept_cached dan periksa apakah setelan ini ditetapkan ke false.

    d. Jika remote_accept_cached adalah false, tentukan tempatnya ditetapkan ke false: di command line atau di file bazelrc.

Memastikan penyimpanan dalam cache di seluruh mesin

Setelah hit cache terjadi seperti yang diharapkan di mesin yang sama, jalankan build/pengujian yang sama di mesin lain. Jika Anda mencurigai bahwa penyimpanan dalam cache tidak terjadi di seluruh komputer, lakukan hal berikut:

  1. Lakukan sedikit modifikasi pada build Anda untuk menghindari cache yang ada.

  2. Jalankan build di mesin pertama:

     bazel clean
     bazel ... build ... --execution_log_compact_file=/tmp/exec1.log
    
  3. Jalankan build di mesin kedua, pastikan modifikasi dari langkah 1 disertakan:

     bazel clean
     bazel ... build ... --execution_log_compact_file=/tmp/exec2.log
    
  4. Bandingkan log eksekusi untuk kedua eksekusi. Jika log tidak identik, selidiki konfigurasi build Anda untuk menemukan perbedaan serta properti dari lingkungan host yang bocor ke salah satu build.

Membandingkan log eksekusi

Log eksekusi berisi catatan tindakan yang dieksekusi selama build. Setiap data menjelaskan input (tidak hanya file, tetapi juga argumen command line, variabel lingkungan, dll.) dan output tindakan. Dengan demikian, pemeriksaan log dapat mengungkapkan alasan tindakan dieksekusi ulang.

Log eksekusi dapat dibuat dalam salah satu dari tiga format: ringkas (--execution_log_compact_file), biner (--execution_log_binary_file), atau JSON (--execution_log_json_file). Format ringkas direkomendasikan karena menghasilkan file yang jauh lebih kecil dengan overhead runtime yang sangat sedikit. Petunjuk berikut berfungsi untuk semua format. Anda juga dapat mengonversinya menggunakan alat //src/tools/execlog:converter.

Untuk membandingkan log untuk dua build yang tidak berbagi hit cache seperti yang diharapkan, lakukan tindakan berikut:

  1. Dapatkan log eksekusi dari setiap build dan simpan sebagai /tmp/exec1.log dan /tmp/exec2.log.

  2. Download kode sumber Bazel dan build alat //src/tools/execlog:parser:

    git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser

  3. Gunakan alat //src/tools/execlog:parser untuk mengonversi log menjadi format teks yang dapat dibaca manusia. Dalam format ini, tindakan dalam log kedua diurutkan agar cocok dengan urutan dalam log pertama, sehingga memudahkan perbandingan.

    bazel-bin/src/tools/execlog/parser \
      --log_path=/tmp/exec1.log \
      --log_path=/tmp/exec2.log \
      --output_path=/tmp/exec1.log.txt \
      --output_path=/tmp/exec2.log.txt
    
  4. Gunakan teks favorit Anda yang berbeda dengan diff /tmp/exec1.log.txt dan /tmp/exec2.log.txt.