リモート実行のためのリモートキャッシュヒットのデバッグ

<ph type="x-smartling-placeholder"></ph> 問題を報告するソースを表示夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページでは、キャッシュヒット率を確認する方法とその調査方法について説明します。キャッシュミスを検出できます。

このページでは、正常に完了したビルドやテストがあることを前提としています。リモート実行を利用している場合、リモートキャッシュを利用します

キャッシュヒット率の確認

Bazel 実行の標準出力で、INFO の行を確認します。 Bazel アクションにほぼ対応しています。この行の詳細がアクションを実行した場所ですアクションを示す remote ラベルを探します。リモート実行、linux-sandbox: ローカルサンドボックスで実行されたアクション、その他の実行戦略の値などです。結果が表示されたアクションリモートキャッシュに保存されたデータは remote cache hit と表示されます。

例:

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

この例では、6 件のリモートキャッシュヒットがあり、2 件のアクションが発生しませんでしたリモートから実行されたこともわかりますこの 3 つの内部部分は無視してかまいません。通常は、シンボリックリンクの作成など、小さな内部アクションです。ローカルキャッシュヒットはこの概要には含まれません。プロセスが 0 の場合（または想定よりも小さい数値）、bazel clean を実行してからビルド/テストを実行します。使用できます。

キャッシュヒットのトラブルシューティング

期待するキャッシュヒット率が得られない場合は、次の操作を行います。

同じビルド/テストコマンドを再実行するとキャッシュヒットが発生することを確認する

キャッシュにデータを入力する予定のビルドやテストを実行します。「特定のスタックで新しいビルドを初めて実行する際、リモートビルドはキャッシュヒットを除外できますリモート実行の一環として、アクションの結果はリモート実行の後続の実行で検出されるようにします
bazel clean を実行します。このコマンドはローカルキャッシュを消去し、リモートキャッシュヒットを調査する際に、キャッシュヒットが除外されます
調査対象のビルドとテストを再度（同じスケジュールで）実行するあります。
INFO 行でキャッシュヒット率を確認します。それ以外のプロセスが表示されない場合は、 remote cache hit と internal の場合、キャッシュは正しく入力され、表示されます。その場合は、次のセクションに進みます。
不一致の原因としては、ビルドが密閉型でないことが原因の可能性があります。 2 つの実行で異なるアクションキーを受け取るアクションを指定できます。確認するには次の操作を行います。

a. 問題のビルドまたはテストを再実行して実行ログを取得します。
```
  bazel clean
  bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
```
b. 次の VM の実行ログを比較します。 2 回実行します。2 つのログファイルで操作が同一であることを確認します。不一致は、期間に発生した変化についての手がかりとなります。実行されますビルドを更新して、これらの不一致を解消します。

キャッシュの問題を解決でき、繰り返し実行された場合、すべてのキャッシュヒットが生成されたら、次のセクションに進みます。

アクション ID が同一でもキャッシュヒットがない場合、キャッシュが妨げられていますこのセクションの続きよくある問題がないか確認しましょう

実行ログの差分を確認する必要がない場合は、代わりに、人が読める形式の --execution_log_json_file フラグを使用してください。次は許可されません。実行時間が含まれ、実行時間が含まれないため、安定している差分の取得に使用されます順序を保証します。
実行ログのすべてのアクションで cacheable が true に設定されていることを確認します。条件 cacheable が、特定のアクションの実行ログに表示されない。対応するルールのタグ名に no-cache タグが含まれている可能性があります。 BUILD ファイル内で定義しています。人が読める形式の progress_message を確認します。フィールドで確認できます。
アクションが同一で cacheable であるにもかかわらず、キャッシュヒットがない場合、コマンドラインに --noremote_accept_cached が含まれているか、ビルドのキャッシュルックアップを無効にします。

実際のコマンドラインがわかりにくい場合は、コマンドラインから Build イベントプロトコル次のとおりです。

a. ログのテキストバージョンを取得するには、--build_event_text_file=/tmp/bep.txtを Bazel コマンドに追加します。

b. テキストバージョンのログを開き、 command_line_label: "canonical" さんとの structured_command_line 件のメッセージ。展開するとすべてのオプションが表示されます。

c. remote_accept_cached を検索して、false に設定されているかどうかを確認します。

d. remote_accept_cached が false の場合は、配置先を特定します。 false に設定する: コマンドラインまたは bazelrc ファイルです。

マシン間でのキャッシュ保存を確認する

同じマシンでキャッシュヒットが想定どおりに発生したら、次のコマンドを実行します。同じビルド / テストを別のマシンで実行できます。キャッシュへの保存が疑われる場合は、発生しない場合は、次のようにします。

既存のキャッシュにヒットしないように、ビルドに小さな変更を加えます。

1 台目のマシンでビルドを実行します。

 bazel clean
 bazel ... build ... --execution_log_binary_file=/tmp/exec1.log

2 台目のマシンでビルドを実行し、ステップ 1 での変更を確認します。含まれます。
```
 bazel clean
 bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
```
2 つの実行ログを比較する実行されますログが同一でない場合は、ビルド構成を調査します。ホスト環境からのプロパティやデータのリークテストします

実行ログの比較

実行ログには、ビルド中に実行されたすべてのアクションの記録が含まれます。対象アクションごとに SpawnExec すべての要素が含まれます。したがって、アクションキャッシュキーも同じです。

想定どおりにキャッシュヒットを共有していない 2 つのビルドのログを比較するには、次のように行います。

各ビルドから実行ログを取得し、/tmp/exec1.log として保存します。 /tmp/exec2.log。
次のコマンドを使用して Bazel ソースコードをダウンロードし、Bazel フォルダに移動します。ソースコードを解析するには、別の実行ログとともに execlog パーサー。
```
git clone https://github.com/bazelbuild/bazel.git
cd bazel
```
実行ログパーサーを使用してログをテキストに変換します。次のの呼び出しでは、2 番目のログのアクションもアクション順序に一致するように並べ替えられます。表示されます。
```
bazel build src/tools/execlog:parser
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
```
好きなテキストを使って、/tmp/exec1.log.txt と /tmp/exec2.log.txt。

リモート実行のためのリモート キャッシュ ヒットのデバッグ

キャッシュ ヒット率の確認

キャッシュ ヒットのトラブルシューティング

同じビルド/テストコマンドを再実行するとキャッシュ ヒットが発生することを確認する