このページでは、キャッシュ ヒット率を確認する方法と、リモート実行におけるキャッシュミスを調査する方法について説明します。
このページでは、リモート実行を正常に利用するビルドやテストがあり、リモート キャッシュを効果的に利用していることを前提としています。
キャッシュ ヒット率を確認する
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. 2 つの実行間で実行ログを比較します。2 つのログファイルで操作が同一であることを確認します。不一致は、実行間で発生した変更についての手がかりとなります。ビルドを更新して、これらの不一致を解消します。
キャッシュの問題を解決でき、繰り返し実行するとすべてのキャッシュ ヒットが生成された場合は、次のセクションに進みます。
アクション ID が同一であるのにキャッシュ ヒットがない場合は、構成内のなんらかの原因によりキャッシュが妨げられています。このセクションに進んで、一般的な問題を確認します。
実行ログの差分を比較する必要がない場合は、人が読める形式の
--execution_log_json_file
フラグを使用できます。実行時間が含まれ、順序を保証しないため、安定した差分の取得には使用できません。実行ログのすべてのアクションで
cacheable
が true に設定されていることを確認します。特定のアクションの実行ログにcacheable
が表示されない場合は、対応するルールのBUILD
ファイルの定義にno-cache
タグが含まれている可能性があります。アクションの実行元を特定するには、実行ログの人が読める形式のprogress_message
フィールドを調べます。アクションが同一で
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
に設定されているかを確認します。
マシン間でのキャッシュ保存を確認する
同じマシンでキャッシュ ヒットが想定どおりに発生したら、別のマシンで同じビルド / テストを実行します。マシン間でキャッシュに保存されていないと思われる場合は、次の操作を行います。
既存のキャッシュにヒットしないように、ビルドに小さな変更を加えます。
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 番目のログ内のアクションを 1 番目のログ内のアクション順序と一致するように並べ替えます。
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
を比較します。