5

私は独自のマルチスレッド C プログラムを持っており、CPU コアの数に合わせてスムーズに速度を調整できます..1、2、3 などのスレッドで実行でき、線形スピードアップを得ることができます..6 コアで最大約 5.5 倍の速度Ubuntu Linux ボックスの CPU。

Red Hat Enterprise Linux を実行する 4 つのクアッドコア Xeon プロセッサを搭載した非常にハイエンドな Sunfire x4450 でプログラムを実行する機会がありました。16 スレッドで私のプログラムを 16 コアでどれだけ速く実行できるか楽しみにしていましたが、2 つのスレッドと同じ速度で実行されます。

後で非常に頭を悩ませてデバッグすると、私のプログラムが実際にすべてのスレッドを作成していて、実際には同時に実行されていることがわかりますが、スレッド自体は本来よりも遅いです。2 スレッドは 1 よりも約 1.7 倍速く実行されますが、3、4、8、10、16 スレッドはすべて正味 1.9 倍で実行されます! すべてのスレッドが実行されている (ストールまたはスリープ状態ではない) ことがわかりますが、単に遅いだけです。

ハードウェアに問題がないことを確認するために、プログラムの 16 個のコピーを個別に同時に実行しました。彼らは皆、全速力で走った。実際には 16 個のコアがあり、それらは実際にフル スピードで実行され、十分な RAM があります (実際、このマシンには 64 GB があり、プロセスごとに 1 GB しか使用しません)。

したがって、私の質問は、オペレーティングシステムの説明があるかどうかです。おそらく、スレッドスケジューリングを自動的に縮小して、1つのプロセスがマシンを占有しないようにするプロセスごとのリソース制限です。

手がかりは次のとおりです。

  1. プログラムがディスクまたはネットワークにアクセスしません。それはCPUの制限です。その速度は、1 ～ 6 スレッド用のヘキサコア i7 を備えた Ubuntu Linux の単一の CPU ボックスで直線的にスケーリングします。6 スレッドは実質的に 6 倍のスピードアップです。
  2. 私のプログラムは、この 16 コアの Sunfire Xeon ボックスで、2 から 16 の任意の数のスレッドで 2 倍のスピードアップよりも速く実行されることはありません。
  3. 私のプログラムの 16 個のコピーをシングル スレッドで実行すると、完全に実行され、16 個すべてが一度に全速力で実行されます。
  4. top は、割り当てられた CPU の 1600% を示しています。/proc/cpuinfo は、16 個のコアすべてが 2.9GHz の最大速度で実行されていることを示しています (1.6GHz の低周波数アイドル速度ではありません)。
  5. 48 GB の RAM が空き、スワッピングではありません。

何が起こっていますか？プロセスの CPU 制限ポリシーはありますか? もしそうなら、どうすればそれを測定できますか？この動作を他に説明できるものは何ですか?

これを解決するためのアイデアをありがとう、2010 年の大 Xeon スローダウン ミステリー!

4

3 に答える 3

2

rlimit について調査してください。実行しているシェル/ユーザー アカウントに、RH のデフォルトまたは管理者が設定したリソース制限が設定されている可能性は十分にあります。

于 2010-08-20T21:42:16.837 に答える
1

私の最初の推測は、共有メモリのボトルネックでしょう。あなたの言うことから、2 つの CPU の後、パフォーマンスはほぼ横ばいになります。最初は Redhat のせいだとおっしゃいましたが、同じハードウェアに Ubuntu をインストールするとどうなるか知りたいです。もちろん、両方のテストで 64 ビット SMP カーネルを実行していると仮定します。

マザーボードが 2 つの CPU を使用してピークに達することは、おそらくあり得ません。より優れたパフォーマンスを提供する複数のコアを備えた別のマシンがあります。新しいマシンでハイパースレッディングを有効にしていますか? （そして、その答えは古いマシンと比べてどうですか？）。偶然にも、仮想化環境で実行していませんか?

全体として、あなたの証拠は、ばかばかしいほど遅いボトルネックをどこかに示しています。あなたが言ったように、あなたは I/O バウンドではないので、CPU とメモリはそのままです。ハードウェアに問題があるか、ハードウェアに問題があります。一方を変更してもう一方をテストすると、可能性をすばやく絞り込むことができます。

于 2010-06-05T04:02:53.123 に答える
0

この種の奇妙なスケーリング動作が見られる場合、特に問題が複数のスレッドでは見られるが、複数のプロセスでは見られない場合、最初に調べるべきことの 1 つは、ロックの競合やその他の同期プリミティブの影響です。相互に待機する必要があり、複数のコアがキャッシュをメイン メモリにフラッシュすることを余儀なくされる可能性があります。

これは、メモリ アーキテクチャが機能し始めることを意味し、1 つのシリコンに 6 つのコアがある場合は、4 つの個別のプロセッサ間で調整する場合よりも大幅に高速になります。具体的には、単一の CPU の場合、ロック操作のためにメイン メモリにアクセスする必要がまったくない可能性があります。すべてが L3 キャッシュ レベルで処理される可能性が高く、データがバックグラウンドでメイン メモリにフラッシュされている間、CPU は処理を続けることができます。 .

OPはずっと質問に興味を失っていると思いますが（または、ハードウェアにアクセスできなくなった可能性もあります）、これを確認する1つの方法は、プロセスアフィニティが単一の物理 CPU にロックするように設定されています。アプリケーション自体のプロファイルを作成して、アプリケーションがどこで時間を費やしているかを確認することをお勧めします。アーキテクチャを変更してコア数を増やすと、ボトルネックがどこにあるかを推測するのがますます難しくなるため、実際に測定を開始する必要があります。この例のように直接: http://postgresql.1045698.n5.nabble.com/Sun-Donated-a-Sun-Fire-T2000-to-the-PostgreSQL-community-td2057445.html

于 2012-11-27T13:50:59.613 に答える