5

Windows 2003 サーバーに展開するソフトウェアを構築しました。このソフトウェアは継続的にサービスとして実行され、Windows ボックスで私にとって重要な唯一のアプリケーションです。インターネットからデータを取得している時間もあれば、そのデータに対して何らかの計算を行っている時間もあります。マルチスレッドです。私は、およそ 4 ～ 20 個のスレッドのスレッド プールを使用しています。

これらすべての詳細について説明するのは退屈ではありませんが、プール内でより多くのスレッドを有効にすると、より多くの同時作業が発生し、CPU 使用率が上昇するということだけを言っておけば十分です。（帯域幅などの他のリソースの需要も同様ですが、私には関係ありませんが、十分あります）

私の質問は次のとおりです。費用対効果を最大限に高めるには、単に CPU を最大限に活用する必要がありますか? 直感的には、100% の CPU で実行するのは意味がないと思います。95% の CPU でさえ高いように見えます。OS が必要なことを実行するための十分なスペースを OS に与えていないようです。最適なバランスを特定する正しい方法がわかりません。私は測定して測定することができ、おそらくCPUの平均使用率が90％または91％などで最高のスループットが達成されることがわかると思いますが...

これについて良い経験則があるかどうか疑問に思っていますか??? 私のテストでは、あらゆる種類のワークロードのバリエーションが考慮されるとは限りません。少し安全にプレイしたいのですが、安全すぎないようにします (または、ハードウェアを十分に活用していません)。

おすすめは何ですか？Windows 上のマルチスレッドの混合負荷 (一部の I/O、一部の CPU) アプリケーションの使用に関するスマートでパフォーマンス重視のルールは何ですか?

4

5 に答える 5

6

ええ、100% スラッシングしているので、プロセスが常にそのように実行されているのを見たくないでしょう。使用率とスパイク/アドホック プロセスの余地とのバランスを取るために、私は常に 80% を目指してきました。

私が過去に使用したアプローチは、プール サイズをゆっくりと上げて、(CPU と IO などの他の制約の両方で) 影響を測定することでした。突然 IO がボトルネックになることに気付くかもしれません。

于 2010-02-24T18:46:02.310 に答える
4

この I/O 集中型ワークロードでは CPU 使用率は問題にならないはずです。スループットを気にする必要があるため、ヒル クライミング アプローチを使用して、基本的にプログラムでワーカー スレッドを挿入/削除し、完了の進行状況を追跡してみてください...

スレッドを追加して役立つ場合は、別のスレッドを追加してください。スレッドを試してみて痛む場合は、削除してください。

最終的にはこれで安定します。

これが .NET ベースのアプリの場合、ヒル クライミングが .NET 4 スレッドプールに追加されました。

アップデート：

ヒル クライミングは、スループットを最大化するための制御理論に基づくアプローチです。必要に応じて試行錯誤と呼ぶこともできますが、これは健全なアプローチです。一般に、オーバーヘッドとレイテンシーは大きく異なり、一般化することは実際には不可能であるため、ここで従うべき適切な「経験則」はありません。CPU 使用率ではなく、スループットとタスク/スレッドの完了に焦点を当てる必要があります。たとえば、コアを粗粒度同期または細粒度同期で非常に簡単にペグするのは非常に簡単ですが、実際にはスループットに違いはありません。

また、.NET 4 に関しては、問題を Parallel.For または Parallel.ForEach として再構成できる場合、スレッドプールはスレッド数を調整してスループットを最大化するため、これについて心配する必要はありません。

-リック

于 2010-02-20T17:21:30.077 に答える
3

他に重要なことは何もないと仮定すると、OSはマシン上で実行されます。

そしてあなたの負荷は一定です、あなたは100％のCPU使用率を目指すべきです、他のすべてはCPUの無駄です。OSがスレッドを処理するので、実際に実行できることを忘れないでください。動作の良いプログラムでOSを飢えさせるのは困難です。

ただし、負荷が変動し、考慮すべきピークが予想される場合は、負荷がどのように変化し、必要なCPUの量が正確にわからない限り、80％のCPUを使用するのが適切なしきい値だと思います。正確な数を目指すことができます。

于 2010-02-20T11:54:18.700 に答える
1

単にスレッドに低い優先度を与えると、OSが残りの作業を行い、作業に必要なサイクルを取ります。Server 2003（およびほとんどのサーバーOS）はこれに非常に優れており、自分で管理する必要はありません。

于 2010-02-20T11:53:11.410 に答える
0

また、ターゲット CPU 使用率の一般的な経験則として 80% を使用しました。他の人が言及しているように、これにより、アクティビティの散発的なスパイクに対応できる余地が残され、CPU でのスラッシングを回避するのに役立ちます。

この問題に関する Weblogic クルーからのちょっとした (古いが関連のある) アドバイスがあります: http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942

負荷が非常に均一で予測可能であると感じている場合は、その目標をもう少し高くすることができますが、ユーザーベースが定期的な遅い応答に対して非常に寛容であり、プロジェクトの予算が非常に厳しい場合を除き、システムにリソースを追加することをお勧めします ( CPU を追加する、より多くのコアを備えた CPU を使用するなど)、既存のプラットフォームからさらに 10% の CPU 使用率を絞り出そうとする危険な動きよりも優先されます。

于 2015-09-23T16:11:34.517 に答える