13

GNU make のドキュメントから: http://www.gnu.org/software/make/manual/make.html#Parallel

システムの負荷が高い場合は、負荷が低い場合よりも少ないジョブを実行する必要があります。「-l」オプションを使用して、負荷平均に基づいて一度に実行するジョブの数を制限するよう make に指示できます。「-l」または「--max-load」オプションの後には浮動小数点数が続きます。例えば、

 -l 2.5

負荷平均が 2.5 を超える場合、make は複数のジョブを開始できません。前の「-l」オプションで負荷制限が指定されていた場合、次の数値を指定しない「-l」オプションは負荷制限を削除します。

より正確には、make がジョブを開始するときに、すでに少なくとも 1 つのジョブが実行されている場合、現在の負荷平均をチェックします。'-l' で指定された制限を下回っていない場合、make は平均負荷がその制限を下回るか、他のすべてのジョブが終了するまで待機します。

稼働時間については、Linux のマニュアル ページから: http://www.unix.com/man-page/Linux/1/uptime/

システム負荷平均は、実行可能または中断不可能な状態にあるプロセスの平均数です。実行可能な状態のプロセスは、CPU を使用しているか、CPU の使用を待機しています。中断不可能な状態のプロセスは、I/O アクセス (ディスクの待機など) を待機しています。平均は、3 つの時間間隔で取得されます。負荷平均はシステム内の CPU の数に対して正規化されていないため、負荷平均 1 は単一の CPU システムが常に負荷をかけられていることを意味し、4 CPU システムでは 75% の時間アイドル状態だったことを意味します。

私は並列のmakefileを持っていて、明らかなことをしたいと思っています.CPUを完全に使用するまでプロセスを追加し続けるようにしますが、スラッシングを誘発していません.

今日の多くの (すべて?) マシンはマルチコアであるため、コアの数に合わせてその数を調整する必要があるため、負荷平均は make がチェックする必要がある数ではないことを意味します。

--max-loadこれは、GNU make の(別名-l) フラグが役に立たなくなったことを意味しますか? マルチコアマシンで並列メイクファイルを実行している人は何をしていますか?

4

4 に答える 4

8

私の短い答え--max-loadは、それを有効に活用するために必要な時間を投資する意思がある場合に役立ちます。現在の実装では、適切な値を選択するための単純な公式や、それらを発見するためのプレハブ ツールはありません。

私が維持しているビルドはかなり大きいです。メンテナンスを始める前は、ビルドに 6 時間かかりました。-j64RAM ディスクでは、5 分 (NFS マウントでは 30 分) で終了するようになりました-j12。ここでの私の目標は、開発者が迅速にビルドできるようにする一方で、サーバー (ビルド サーバーまたは NFS サーバー) を他のすべての人が使用できなくならないようにする合理的な上限を見つけること-jでした。-l

まず始めに：

  • (マシン上で)妥当な 値を選択し、-jN(マシン上で) 負荷平均の妥当な上限を見つけた場合、それらはうまく連携して物事のバランスを保ちます。
  • 非常に大きな-jN値 (または未指定; たとえば-j数値なし) を使用して負荷平均を制限すると、gmake は次のようになります。
    • ジョブの最大数に達するか、負荷平均がしきい値を超えるまで、プロセスの生成を続けます (gmake 3.81 はスロットリング メカニズムを追加しましたが、それは問題を少し軽減するのに役立ちます)。
    • 負荷平均がしきい値を超えている間:
      • すべてのサブプロセスが終了するまで何もしない
      • 一度に 1 つのジョブを生成する
    • やり直す

少なくとも Linux (およびおそらく他の *nix バリアント) では、負荷平均は指数移動平均(UNIX Load Average Reweighed、Neil J. Gunther) であり、CPU 時間を待機しているプロセスの平均数を表します (プロセスが多すぎることが原因である可能性があります)。 、IO、ページフォールトなどを待っています)。これは指数移動平均であるため、新しいサンプルが古いサンプルよりも現在の値に強い影響を与えるように重み付けされています。

適切な最大負荷と並列ジョブ数の適切な「スイート スポット」を (知識に基づく推測と経験に基づくテストの組み合わせにより) 識別できる場合、実行時間の長いビルドがあると仮定すると、1 分間の平均は平衡点 (大きく変動することはありません）。ただし、-jN特定の最大負荷平均に対して数値が高すぎる場合は、かなり変動します。

スイート スポットを見つけることは、微分方程式の最適なパラメーターを見つけることと本質的に同じです。初期条件の影響を受けるため、「ターゲット」負荷平均を考え出すのではなく、システムを平衡状態に保つパラメータを見つけることに重点が置かれます。「平衡状態」とは、平均 1m の負荷があまり変動しないことを意味します。

gmake の制限によってボトルネックが発生していないと仮定すると-jN -lM: 最小限のビルド時間を与える組み合わせを見つけた場合: その組み合わせはマシンを限界まで押し上げます。マシンを他の目的に使用する必要がある場合...

コンパイル

...最適化が完了したら、少し縮小することをお勧めします。

load avg に関係なく、増加に伴うビルド時間の改善は-jN[おおよそ] 対数的であるように見えました。つまり、 と の間よりも-j8との間に大きな違いが見られました。-j12-j12-j16

最初の gmake プロセスがシングルスレッドであるため、物事は と の間のどこか (Solaris マシンでは約 )-j48でピークに達しました-j64。-j56ある時点で、スレッドは新しいジョブを終了するよりも速く開始できません。

私のテストは以下で実行されました：

  • 非再帰ビルド
    • 再帰的なビルドでは、異なる結果が表示される場合があります。彼らは私が周りに行ったボトルネックに遭遇しません-j64
    • レシピの解析は並列ジョブを生成する同じスレッドで行われるため、レシピ内の make-ism (変数展開、マクロなど) の量を最小限に抑えるために最善を尽くしました。レシピが複雑になればなるほど、ジョブのスポーン/リープではなく、パーサーでより多くの時間が費やされます。例えば：
      • $(shell ...)レシピではマクロは使用されません。これらは最初の解析パス中に実行され、キャッシュされます
      • ほとんどの変数は:=、再帰的な展開を避けるために で割り当てられます
  • ソラリス 10/スパーク
    • 256コア
    • 仮想化/論理ドメインなし
    • ビルドは RAM ディスクで実行されました
  • x86_64 Linux
    • 32 コア (4x ハイパースレッド)
    • 仮想化なし
    • ビルドは高速なローカル ドライブで実行されました
于 2015-09-09T19:44:43.357 に答える
0

CPU がボトルネックとなるビルドでも-l理想的ではありません。ここで、N は存在するコアの数、またはビルドに使用-jNしたいコアの数です。私の状況では、より大きな数を選択してもビルドの速度は上がりません。船外に出ない限り（無限を指定するなど-j）、速度が低下することもありません。

Using-lNは とほぼ同等-jNであり、マシンに他の独立した作業がある場合はより適切に機能しますが、2つの癖があります(あなたが言及したものとは別に、考慮されていないコアの数):

  • 最初のスパイク: ビルドの開始時に、makeは N よりもはるかに多くのジョブを起動します。システムの負荷数は、プロセスがフォークされてもすぐには増加しません。それは私の状況では問題ではありません。
  • スターベーション: 一部のビルド ジョブが他のビルド ジョブに比べて時間がかかる場合、最初の M 個のクイック ジョブが終了した時点で、システム負荷は依然として >N です。すぐにシステム負荷が N - M に低下しますが、これらのいくつかの遅いジョブが引きずられている限り、新しいジョブは開始されず、コアは空腹のままになります。Makeは、古いジョブが終了したときと開始時に新しいジョブを起動することだけを考えます。システムの負荷がその間に落ちていることに気づきません。
于 2015-05-10T20:35:05.047 に答える
0

これは、GNU make の --max-load (別名 -l) フラグが役に立たなくなったことを意味しますか? マルチコアマシンで並列メイクファイルを実行している人は何をしていますか?

例の 1 つは、各テストでプログラムをコンパイルおよびリンクする必要があるテスト スイートでジョブを実行することです。リンクすると、結果としてシステムに負荷がかかりすぎる場合があります - 致命的なエラー: ld はシグナル 9 [Killed] で終了しました。私の場合、それはメモリ オーバーヘッドではなく CPU 使用率であったため、通常、提案されたスワップ ファイルは役に立ちませんでした。

オプションの-l 1実行は依然として並列ですが、リンクはほぼ順次です。 システムモニターでリソース消費を可視化

于 2018-09-14T16:47:08.960 に答える
0

今日の多くの (すべて?) マシンはマルチコアであるため、コアの数に合わせてその数を調整する必要があるため、負荷平均は make がチェックする必要がある数ではないことを意味します。

これは、GNU make の --max-load (別名 -l) フラグが役に立たなくなったことを意味しますか?

いいえ。要求の厳しいディスク I/O を伴うジョブを想像してみてください。CPU と同じ数のジョブを開始したとしても、CPU を十分に活用することはできません。

個人的には、これまでのところ十分に機能していたので、単純に -j を使用しています。

于 2013-05-02T10:59:54.170 に答える