動的実行は Bazel の機能 バージョン 0.21 以降、 同じアクションのローカル実行とリモート実行を並行して開始できます。 終了した最初の分岐の出力を使用し、もう一方の分岐をキャンセルして、 されます。リモート サーバーの実行能力や大規模な共有キャッシュを ローカル実行の低レイテンシを実現し、両者の長所を活かします。 クリーンビルドと増分ビルドの両方で利用できます
このページでは、動的実行の有効化、調整、デバッグを行う方法について説明します。もし ローカル実行とリモート実行の両方が設定され、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 ニーモニックのみです。リモート バージョンも同じように動作します。どちらのフラグも
複数回指定します。アクションをローカルで実行できない場合は、
リモートで実行することも、その逆も可能です。
リモート システムにキャッシュがある場合、--local_execution_delay
フラグ: リモート システムの終了後、ローカル実行にミリ秒単位の遅延を追加します。
キャッシュヒットを示していますこれにより、キャッシュが増加してもローカル実行が
ヒットする可能性が高くなります。デフォルト値は 1, 000 ミリ秒ですが、
通常のキャッシュ ヒットよりも長い時間がかかります。実際の所要時間は
ラウンドトリップの所要時間を
確認する必要があります通常、この値は
一定のリモート システムのすべてのユーザーに対して同じことが言えますが、
ラウンドトリップレイテンシが増加しますこちらの
Bazel プロファイリング機能
通常のキャッシュヒットにかかる時間を見てみましょう
動的実行は、ローカル サンドボックス戦略だけでなく、
永続ワーカー。永続ワーカーは
動的実行で使用される場合、サンドボックス化で自動的に実行されます。
Multiplex worker を使用します。Darwin システムと Windows システムでは
サンドボックス化戦略は低速になる場合があります。次を
--reuse_sandbox_directories: これらのシステムでサンドボックスを作成するオーバーヘッドを削減します。
動的実行は standalone 戦略でも実行できますが、
standalone 戦略は、実行開始時に出力ロックを受け取る必要があります。
リモート戦略が先に終了することを効果的にブロックします。「
この問題を回避するには、--experimental_local_lockfree_output フラグを使用します。
ローカル実行では出力に直接書き込むことができますが、
先に終了すべきです。
動的実行のブランチのいずれかが先に終了したものの失敗した場合、 失敗します。これは、差異を防ぐために意図的に選択したものです。 気づかれずに行われることを防げます。
動的実行とそのロックの仕組みの詳細については、Julio を参照してください。 メリノの絶品料理 ブログ投稿
動的実行を使用するタイミング
動的実行には、なんらかの形の リモート実行システム。現在は キャッシュ ミスが考慮されるため、キャッシュのみのリモート システムを使用できる 表示されます。
すべてのタイプのアクションがリモート実行に適しているわけではありません。最高の ローカル環境で本質的に高速な 永続ワーカー、つまり リモート実行のオーバーヘッドが実行時間の大半を占めるほど高速です。 ローカルで実行されるアクションごとにある程度の CPU とメモリがロックされるため、 このカテゴリに当てはまらないアクションを実行しても、 実行できます。
リリース時
5.0.0-pre.20210708.4,
パフォーマンス プロファイリング
処理の完了にかかった時間など、ワーカーの実行に関するデータが含まれる
動的実行の競合に負けた後のレスポンスです。動的実行が表示される場合
ワーカー スレッドがリソースの取得に長時間を費やしたり、
async-worker-finish では、遅いローカル アクションによって
指定することもできます
8 つの Javac ワーカーを使用する上記のプロファイルでは、多くの Javac ワーカーが確認できます。
レースに負けて async-worker-finish で仕事を終えたユーザー
説明します。これは、ワーカー以外の記憶装置が十分なリソースを
ワーカーを遅延させます
動的実行で Javac のみを実行した場合、起動したリソースの約半分のみが 就業後すぐにレースで負けてしまいます
以前に推奨されていた --experimental_spawn_scheduler フラグは非推奨になりました。
動的実行が有効になり、dynamic がすべてのデフォルトの戦略として設定されます
この種の問題につながることがよくあります。
トラブルシューティング
動的実行の問題は微妙で、デバッグが困難な場合がある
ローカル実行とリモート実行の特定の組み合わせでのみマニフェストを利用できます。
--debug_spawn_scheduler は、ダイナミック要素からの追加出力を追加します。
さまざまな実行システムを使用できます。また、
--local_execution_delay フラグと、リモートジョブとローカルジョブの数
問題の再現を容易にするためです。
standalone を使用した動的実行の問題が発生している場合
--experimental_local_lockfree_output を使用せずに実行するか、次を実行します。
ローカル アクションをサンドボックス化します。これによりビルドが遅くなる可能性があります（上記の
Mac または Windows を使用している場合など）ですが、考えられるエラーの原因を取り除きます。