このページでは、キャッシュ ヒット率を確認する方法と、リモート実行のコンテキストで キャッシュ ミスを調査する方法について説明します。
このページでは、リモート実行を正常に 利用するビルドまたはテストがあり、リモート キャッシュを効果的に 利用していることを確認することを前提としています。
キャッシュ ヒット率を確認する
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が表示されない場合は、対応するルールにno-cacheタグが 定義でBUILDファイルに含まれている可能性があります。実行ログのmnemonicフィールドとtarget_labelフィールドを確認して、アクションの発生元を特定します。アクションが同一で
cacheableでもキャッシュ ヒットがない場合は、コマンドラインに--noremote_accept_cachedが含まれている可能性があります。この場合、ビルドのキャッシュ検索が無効になります。実際のコマンドラインを特定するのが難しい場合は、次のように Build Event Protocol の正規のコマンドラインを使用します。
a. ログのテキスト バージョンを取得するには、
--build_event_text_file=/tmp/bep.txtを Bazel コマンドに追加します。b. ログのテキスト バージョンを開き、
structured_command_lineメッセージを検索します。command_line_label: "canonical". 展開後のすべてのオプションが一覧表示されます。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の差分を確認します。