このページでは、キャッシュ ヒット率を確認する方法と、リモート実行のコンテキストでキャッシュ ミスを調査する方法について説明します。
このページでは、リモート実行を正常に利用しているビルドまたはテストがあり、リモート キャッシュを効果的に利用していることを確認することを前提としています。
キャッシュ ヒット率を確認する
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 cleanbazel --optional-flags build //your:target --execution_log_compact_file=/tmp/exec1.logb. 2 つの実行の実行ログを比較します。2 つのログファイルでアクションが同じであることを確認します。差異は、実行間で発生した変更に関する手がかりとなります。これらの不一致を解消するようにビルドを更新します。
キャッシュの問題を解決し、繰り返し実行ですべてのキャッシュヒットが発生する場合は、次のセクションに進みます。
アクション ID が同じなのにキャッシュ ヒットがない場合は、構成の何らかの原因でキャッシュが保存されていない可能性があります。このセクションに進んで、一般的な問題を確認します。
実行ログ内のすべてのアクションで
cacheableが true に設定されていることを確認します。特定のアクションの実行ログにcacheableが表示されない場合は、対応するルールのBUILDファイルの定義にno-cacheタグが含まれている可能性があります。実行ログのmnemonicフィールドとtarget_labelフィールドを確認して、アクションの発生元を特定します。アクションが同じで
cacheableなのにキャッシュヒットがない場合は、ビルドのキャッシュ検索を無効にする--noremote_accept_cachedがコマンドラインに含まれている可能性があります。実際のコマンドラインを把握するのが難しい場合は、Build Event Protocol の正規のコマンドラインを使用します。
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の場合は、コマンドラインまたは bazelrc ファイルのどちらでfalseに設定されているかを確認します。
マシン間でのキャッシュを確実に行う
同じマシンでキャッシュ ヒットが期待どおりに発生したら、別のマシンで同じビルドまたはテストを実行します。マシン間でキャッシュに保存されていないと思われる場合は、次の操作を行います。
既存のキャッシュにヒットしないように、ビルドに小さな変更を加えます。
最初のマシンでビルドを実行します。
bazel cleanbazel ... build ... --execution_log_compact_file=/tmp/exec1.log2 番目のマシンでビルドを実行し、ステップ 1 の変更が含まれていることを確認します。
bazel cleanbazel ... build ... --execution_log_compact_file=/tmp/exec2.log2 つの実行の実行ログを比較します。ログが同じでない場合は、ビルド構成に不一致がないか、ホスト環境のプロパティがどちらかのビルドに漏れていないかを確認します。
実行ログの比較
実行ログには、ビルド中に実行されたアクションの記録が含まれます。各レコードは、アクションの入力（ファイルだけでなく、コマンドライン引数、環境変数など）と出力の両方を記述します。したがって、ログを調べることで、アクションが再実行された理由を特定できます。
実行ログは、コンパクト（--execution_log_compact_file）、バイナリ（--execution_log_binary_file）、JSON（--execution_log_json_file）の 3 つの形式のいずれかで生成できます。コンパクト形式は、実行時のオーバーヘッドが非常に小さく、ファイルサイズが大幅に小さくなるため、推奨されます。以下の手順はどの形式でも有効です。//src/tools/execlog:converter ツールを使用して変換することもできます。
想定どおりにキャッシュヒットを共有していない 2 つのビルドのログを比較するには、次の操作を行います。
各ビルドから実行ログを取得し、
/tmp/exec1.logと/tmp/exec2.logとして保存します。Bazel ソースコードをダウンロードして、
//src/tools/execlog:parserツールをビルドします。git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser
//src/tools/execlog:parserツールを使用して、ログを人間が読めるテキスト形式に変換します。この形式では、2 番目のログ内のアクションが最初のログの順序と一致するように並べ替えられるため、比較が容易になります。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を比較します。