動的実行は Bazel の機能で、 最初の分岐の出力を使用して、同じアクションを並行して実行します。 終了し、もう一方のブランチをキャンセルします。実行能力と リモート ビルドシステムの大規模な共有キャッシュであり、ローカル インフラストラクチャの クリーンビルドと増分ビルドの両方の利点を活かしながら あります。
このページでは、動的実行の有効化、調整、デバッグを行う方法について説明します。もし ローカル実行とリモート実行の両方が設定され、Bazel を調整しようとしている このページはパフォーマンスの向上に役立ちます。まだない場合は リモート実行の設定については、Bazel リモート実行 概要をご覧ください。
動的実行を有効にしますか？
動的実行モジュールは Bazel の一部ですが、動的実行モジュールを ローカルとリモートの両方でコンパイルできていなければなりません 同じ Bazel 設定を適用します。
動的実行モジュールを有効にするには、--internal_spawn_scheduler
フラグを Bazel に設定します。これにより、dynamic という新しい実行戦略が追加されます。今すぐ
動的実行が必要な記憶の戦略として、
--strategy=Javac=dynamic。ニーモニックを選択する方法については、次のセクションをご覧ください。
動的実行を有効にする方法を選択できます
動的戦略を使用する任意のニモニックでは、リモート実行戦略は次のようになります。
--dynamic_remote_strategy フラグから取得し、ローカル戦略を
--dynamic_local_strategy フラグ。合格
--dynamic_local_strategy=worker,sandboxed は、ローカル IP アドレスのデフォルトを設定します。
ワーカーで試行する動的実行のブランチまたはサンドボックス化された実行を
できます。--dynamic_local_strategy=Javac=worker を渡すと、デフォルトがオーバーライドされます。
Javac ニーモニックのみです。リモート バージョンも同じように動作します。どちらのフラグも
複数回指定します。アクションをローカルで実行できない場合は、
リモートで実行することも、その逆も可能です。
リモート システムにキャッシュがある場合、--dynamic_local_execution_delay フラグ
は、リモート システムが待機状態になった後、ローカル実行にミリ秒単位で遅延を追加します。
キャッシュヒットを示していますこれにより、キャッシュ ヒットが増えてもローカルでの実行を回避できます
可能性があります。デフォルト値は 1, 000 ミリ秒ですが、短く調整する必要があります。
通常のキャッシュ ヒットよりも長い時間がかかります。実際の時間は、リモコンと
往復の所要時間などです通常、この値は [
一定のリモート システムのすべてのユーザーに対して暗号化できます。ただし、
往復レイテンシが増加しますBazel プロファイリングを使用:
して、Google 検索における
キャッシュヒットが消費されます
動的実行は、ローカル サンドボックス戦略だけでなく、
永続ワーカー。永続ワーカーは
動的実行で使用する場合はサンドボックス化され、
ワーカー。Darwin および Windows システムでは
戦略は時間がかかるものです。--reuse_sandbox_directories を渡して
オーバーヘッドを削減できます。
動的実行は standalone 戦略でも実行できますが、
standalone 戦略は、実行開始時に出力ロックを受け取る必要があります。
リモート戦略が先に終了することを効果的にブロックします。「
この問題を回避するには、--experimental_local_lockfree_output フラグを使用します。
ローカル実行では出力に直接書き込むことができますが、
先に終了すべきです。
動的実行のブランチのいずれかが先に終了したものの失敗した場合、 失敗します。これは、差異を防ぐために意図的に選択したものです。 気づかれずに行われることを防げます。
動的実行とそのロックの仕組みの詳細については、Julio を参照してください。 Merino のブログ 投稿
動的実行を使用するタイミング
動的実行には、なんらかの形式のリモート実行システムが必要です。 現在のところ、キャッシュミスとしてキャッシュのみのリモート システムを使用することはできません。 アクションは失敗とみなされます
すべてのタイプのアクションがリモート実行に適しているわけではありません。最高の ローカル環境で本質的に高速な 永続ワーカー（高速に実行されるワーカー）の使用 リモート実行のオーバーヘッドが実行時間の大半を占めるほどです。以降 ローカルで実行されるアクションごとに、ある程度の CPU リソースとメモリリソースがロックされます。 これらのカテゴリに当てはまらないアクションを実行しても、実行を遅らせるに過ぎない サポートしています
リリース時
5.0.0-pre.20210708.4,
パフォーマンス プロファイリングには、
たとえば、ワーカーの実行時間や、ワーカーの
失敗します動的実行ワーカー スレッドが表示される場合、
リソースの確保に多大な時間を費やしたり
async-worker-finish、低速のローカル アクションが原因でワーカーが遅延している可能性があります
説明します。
8 つの Javac ワーカーを使用する上記のプロファイルでは、多くの Javac ワーカーが確認できます。
レースに負けて async-worker-finish で仕事を終えたユーザー
説明します。これは、ワーカー以外の記憶装置が十分なリソースを
ワーカーを遅延させます
動的実行で Javac のみを実行した場合、起動したリソースの約半分のみが 就業後すぐにレースで負けてしまいます
以前に推奨されていた --experimental_spawn_scheduler フラグは非推奨になりました。
動的実行が有効になり、dynamic がすべてのデフォルトの戦略として設定されます
この種の問題につながることがよくあります。
パフォーマンス
動的実行アプローチでは、利用可能なリソースが十分にあることを前提とする 改善するために追加のリソースを費やす価値があることを 向上させることができますただし、リソースの使用量が過剰になると Bazel 自体の速度が低下したり、 リモートシステムに予期せぬ負荷がかかることもあります。他にも 動的実行の動作を変更するオプションはいくつかあります。
--dynamic_local_execution_delay は、ローカルブランチの開始を数値だけ遅延させます。
ミリ秒単位の経過時間。ただし、リモート ブランチが
リモート キャッシュ ヒットを検出しました。そのため
リモート キャッシュからローカル リソースを浪費することはありません。
キャッシュにあります。キャッシュの品質によっては、
この値を減らすと、ビルド速度が向上する可能性がありますが、
説明します。
--experimental_dynamic_local_load_factor は試験運用版の高度なリソースです
管理オプションを使用できます。0 から 1 までの値を取ります。0 でこの機能が無効になります。
0 より大きい値に設定すると、Bazel はノードの数を調整し、
ローカルにスケジュール設定されたアクションの場合は、
スケジュール設定できます。1 に設定すると、必要な数のアクションのスケジュールを設定できます
使用可能な CPU です（--local_cpu_resources に基づく）。値が小さいほど
アクションのスケジュールは、アクションの数が多くなるにつれて、それに比例して少なくなります。
確認できます。直感に反するかもしれませんが、優れたリモコンを使えば
ローカル実行は、多くのアクションが実行されているときにあまり役に立ちません。
リモート アクションの管理にローカル CPU を使用する方が効率的です。
--experimental_dynamic_slow_remote_time がローカル ブランチの開始を優先する
リモートブランチが少なくともこれほど長く
実行されているとき通常、
最も新しいタイミングでのアクションが優先され、
リモートシステムがハングしたり
かなりの時間がかかったりすると
構築する可能性も高まりますこれはデフォルトでは有効になっていないため、
リモート システムの問題が隠れてしまう可能性があります。確認事項
を使用してリモート システムのパフォーマンスをモニタリングできます。
--experimental_dynamic_ignore_local_signals を使用すると、リモコンで操作できるようになります。
特定のシグナルによってローカルの Spwn が終了したときに、ブランチが引き継ぎます。これは、
ワーカー リソースの上限（
--experimental_worker_memory_limit_mb
--experimental_worker_sandbox_hardening,
および
--experimental_sandbox_memory_limit_mb)),
ワーカー プロセスがリソースを使いすぎると強制終了されるおそれがあります。
JSON トレース プロファイルには、 パフォーマンス関連のグラフが多数用意されています。これらのグラフを元に、 パフォーマンスとリソース使用量のトレードオフが 発生します
トラブルシューティング
動的実行の問題は微妙で、デバッグが困難な場合がある
ローカル実行とリモート実行の特定の組み合わせでのみマニフェストを利用できます。
--debug_spawn_scheduler は、動的実行からの追加出力を追加します。
いくつか見てみましょうまた、
--dynamic_local_execution_delay フラグと、リモートジョブとローカルジョブの数の比較
問題の再現が容易になります
standalone を使用した動的実行の問題が発生している場合
--experimental_local_lockfree_output を使用せずに実行するか、次を実行します。
ローカル アクションをサンドボックス化します。これによりビルドが遅くなる可能性があります（上記の
Mac または Windows を使用している場合など）ですが、考えられるエラーの原因を取り除きます。