このページでは、キャッシュ ヒット率を確認する方法とその調査方法について説明します。 キャッシュミスを検出できます。
このページでは、正常に完了したビルドやテストがあることを前提としています。 リモート実行を利用している場合、 リモートキャッシュを利用します
キャッシュ ヒット率の確認
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
。