スレッド数による性能低下

[戻る]
NEO 2011/01/14(金) 22:40:11
プロセス内のスレッド数が多すぎると、起動しているスレッドの動作が遅くなったりする
ことはあるでしょうか?

επιστημη [E-Mail] [HomePage] 2011/01/14(金) 23:36:18
ありますとも。

NEO 2011/01/16(日) 16:55:55
やっぱりそうですよね。

スレッドの数が760くらいのプロセスで、1つスレッドを増やしただけで他のスレッドがそ
れまでよりも極端に遅くなっているようなのですが、
増やしたスレッドで行っている処理の内容が原因になり得るでしょうか?
増やしたスレッドとその他のスレッドでは、相互の排他制御を行っていないものとします。

ryo 2011/01/16(日) 17:58:03
ありますとも。

PATIO 2011/01/17(月) 13:22:42
処理内容だけに話は止まらないと思います。

スレッド間のCPU割り当てのスケジューリングの関係で
あるスレッド数を超えると割り当ての効率が悪くなるような
ケースも有るでしょう。この辺の最適値はHWのスペックも
絡んでくると思うので一概には言えないと思います。
スレッドを一つ増やしただけだから、影響は少ないと考える事は
少々乱暴に感じます。

個人的にはスレッド数が760と言うのは多すぎるような気がします。
本当に並列で処理すべき物が760も同時に存在しうるのか?
とか、それだけのスレッドを並列に処理するのが最善の策なのか
と検討する必要がないでしょうか?
実際にはもっと少ないスレッド数で処理自体は並列に処理する
ような方式の方が結果的に処理が早くなったりする事はないでしょうか?

マルチコアのCPUが当たり前になってマルチスレッドによる恩恵が
出易い状況になっているとは思いますが、実際にそこまでの並列処理が
必要なのか、現在想定しているHWで可能なのかに関しては
一意にこれなら大丈夫と言う値を出す事は難しいと思うので
各々のシステム構成を踏まえて最適な値の範囲を割り出していく
必要があると思います。

NEO 2011/01/17(月) 18:34:43
スレッド数に関しては、私がプログラム開発に参画する前にすでに決まっていて、開発ス
ケジュールの関係でそれを変えるにはリスクが高すぎるので、今のままになっています。
参画してプログラムの構造を知ったときは、多すぎるなと思ってはいました。
今は何とか動いていますが、やはり一般的な構造ではないと思います。

原因がスレッド数が多いこととは決まったわけではありませんが、仮にそうだとしても開
発の取りまとめの人にしてみれば、できればスレッド数は今のままで別の解決策を探って
ほしいということになると思います。

今のところ、スレッド数が多いことが原因であると言えるような材料は見つかっていません。

ITO 2011/01/17(月) 19:09:56
 OSのパフォーマンスモニターは参考になると思います。
後、HWとの通信の使用をもう一度確かめる必要があると思います。
またいつも忘れてしまうのですが、デバイスドライバーとアプリケーション(DLLを含
む)
とのデータのやり取りには100mS以上の時間が掛かります。

NEO 2011/01/17(月) 19:31:48
増やしたスレッドでは、ファイルを読みながら、TCPで通信しています。

(1)TCPセッション確立。
(2)256バイトずつ読んで100ms Sleep。
(3)1024バイト読んだらTCPで送信。
(4)TCPセッション切断。

(2)〜(3)をファイルを全部送るまで繰り返し。(3)->(2)に戻る前に500ms Sleep。
こんな感じです。

Ban 2011/01/18(火) 09:23:03
スレッドひとつにつきメモリ1MB(デフォルト)が予約される/ある程度使用される
⇒数百スレッドでは結構な量になる
スレッドからスレッドへスイッチするたびにオーバヘッドがかかる
⇒仮に一回分はわずかでも数百スレッドで頻繁にスイッチしながら動作すれば
馬鹿にできない時間になる
(通常そんなスレッドを回すことは少ないと思われるため、
スレッド数が少ない場合に最適化していて?)どこかに検索時間等のオーダが
数に応じて悪化する処理があるのかも?

などなど。

ryo 2011/01/18(火) 12:35:17
最初はスレッドという技術についての質問のようにみえたけど
だんだんと、NEOさんが直面してる固有の問題に話がシフトしはじめてますね

ここをそのまま使うにしても、
いったん質問内容を仕切りなおした方がいいのではないでしょうか?

具体的に困ってる内容、それでどういう風にしたいのか
開発・動作環境、これまでに試した調査結果とか・・・

NEO 2011/01/18(火) 19:39:15
[[解決]]
いったん締めます

仲澤@失業者 2011/01/18(火) 20:16:53
>今のところ、スレッド数が多いことが原因であると言えるような材料は見つかっていま
せん。

とのことですが、回答者の皆さんが遠回しに言っているように、
明らかにスレッドが多すぎますね。Banさんの発言にあるように
760MByteものメモリが予約スタックで消費されているます。
システムが使用しているメモリ(約500MByte)も加算し、32bitOSの
メモリ空間がたかだか2000MByteであることを勘案すれば、
とてもほめられたデザインとは言えませんね(笑)。
もちろんスイッチ時のオーバーヘッドも大変な量になるでしょう。
確かに1プロセスあたり2048(-α)スレッドが上限ですが、これはあくまで
計算上の話。スレッドのコストを度外視してデザインするとえらいめにあいます。

hirocco 2011/01/18(火) 21:23:39
700個以上のスレッドが全て別々の1キロバイトのファイルを開いていて、
700個以上のスレッドがそれぞれのタイミングでネットワークに通信してるんですか?
それってメモリもだけど、ネットワークも混みそうですね

古いスレッドには追加発言できません。