このページでは、キャッシュヒット率を確認する方法と、リモート実行のコンテキストでキャッシュミスを調査する方法について説明します。
このページでは、リモート実行を正常に利用しているビルドまたはテストがあり、リモート キャッシュを効果的に利用していることを確認することを前提としています。
キャッシュ ヒット率を確認する
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_compact_file=/tmp/exec1.log
b. 次の VM の実行ログを比較します。 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. ログのテキスト バージョンを開き、
command_line_label: "canonical"
を含むstructured_command_line
メッセージを検索します。展開するとすべてのオプションが表示されます。c.
remote_accept_cached
を検索して、false
に設定されているかどうかを確認します。d.
remote_accept_cached
がfalse
の場合は、コマンドラインまたは bazelrc ファイルのどちらでfalse
に設定されているかを確認します。
マシン間でのキャッシュを確実に行う
同じマシンでキャッシュ ヒットが想定どおりに発生したら、別のマシンで同じビルドまたはテストを実行します。マシン間でキャッシュに保存されていないと思われる場合は、次の操作を行います。
既存のキャッシュにヒットしないように、ビルドに小さな変更を加えます。
最初のマシンでビルドを実行します。
bazel clean
bazel ... build ... --execution_log_compact_file=/tmp/exec1.log
2 台目のマシンでビルドを実行し、ステップ 1 での変更を確認します。 含まれます。
bazel clean
bazel ... build ... --execution_log_compact_file=/tmp/exec2.log
2 つの実行ログを比較する 実行されますログが同一でない場合は、ビルド構成を調査します。 ホスト環境からのプロパティやデータのリーク テストします
実行ログの比較
実行ログには、ビルド中に実行されたアクションの記録が含まれます。 各レコードは、アクションの入力(ファイルだけでなく、コマンドライン引数、環境変数など)と出力の両方を記述します。したがって、次のようになります。 ログを調べると、アクションが再実行された理由がわかります。
実行ログは、コンパクト(--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 番目のログ内のアクションが 1 番目のログ内の順序と一致するように並べ替えられるため、比較が容易になります。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
。