動的実行は 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 プロファイリング機能を使用して、一般的なキャッシュヒットの所要時間を調べることができます。
動的実行は、ローカル サンドボックス戦略だけでなく、
永続ワーカー。永続ワーカーは
動的実行で使用する場合はサンドボックス化され、
ワーカー。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 を使用すると、特定のシグナルによりローカル スポーンが終了したときに、リモート ブランチが引き継ぐようにできます。これは主に、ワーカーのリソースの上限（--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 の場合は上記を参照）。ただし、エラーの原因となる可能性のあるものが除外されます。