web-dev-qa-db-ja.com

「スレッドが多すぎる」ということはありますか

ここか、またはSOがこれを尋ねるのに適切な場所であるかどうかはわかりませんでしたが、とにかくここに行きます。

そこで、現在稼働中のシステムを改善したいと思います。サービスと多くのスタンドアロンアプリがありますが、これらは適切に調整されていません。今、私は、ミニアプリを作成して、システムの改善を証明したいと思います。もしそうなら、これらを新しい「フレームワーク」に組み込む必要があります。

アイデアは、バックグラウンドでサービスを管理およびレポートするダッシュボードアプリケーションを作成することです。サービスは3分ごとに実行され、クラス(FileProcessor)が呼び出されます。このクラスは、各タイプのプロセッサのRunメソッドを呼び出します。このRunメソッドは、Runnableクラスのスレッドを起動する呼び出しになります。次に、この実行可能なクラスを使用して、処理中のファイルのプロパティを保持します。エラーが発生した場合は、原因、メソッドを再実行するためのオプション、現在のステータス(つまり、処理のどの時点か)です。

これらの「実行可能ファイル」は、ディレクトリ内のファイルと直接やり取りする場合や、ファイルの処理を要求するデータベース内のレコードになる場合があります。

いくつか背景がありますので、次の質問をさせていただきます。

ディレクトリ内のファイルとの直接のやり取り(つまり、拡張子の変更)が「バッチモード」ですぐに実行され、C:\Program Files\My App\Files\\*.xyzで5つのファイルが見つかったとしましょう。このプロセス(ディレクトリ検索の直後)これらのすべてのファイルの名前を一度にC:\Program Files\My App\Files\\*.zyxに変更します。次のように言ってみましょう。

foreach (FileInfo fi in di.GetFiles("*.xyz", TopDirectoryOnly))
{
    fi.MoveTo(Path.ChangeDirectory(fi.FullName, ".zyx"));
}

反対に、データベースから取得されたレコードは、それぞれ別のスレッドに渡されて処理されます。たとえば、10個のファイルが処理を要求し、このRunnableタイプの10個のスレッドが起動され、それぞれがこのステータス情報を保持します。これらのスレッドは、この情報をアプリケーションに渡すことができるように、これらのプロセスを追跡するためのリスト。

ファイルの名前の変更はシンプルで迅速なので、1つの「メソッド呼び出し」に入れると思いますが、処理を要求するファイルは、20から700行の間であれば、行から値が取得され、MySQLデータベースに挿入されます。 。このため、すべてのファイルを「同時に開始」できるようにしたいので、1つまたは2つの700行のファイルが、1つの700までにすべて完了していた他の20行の15行のファイルをブロックまたは遅延させないようにします。行ファイルが処理されました。

さて、基本的に私がこれより良い知識や経験を持っている人が、これが良いアイデアであるか、解決策へのアプローチの方法であるかどうかを知りたいです。おそらく何かが足りないか、デザインがずれている可能性があります。

追伸このサービスとアプリケーションは、非常に優れたサーバーで実行されます。

方向性やアドバイスを事前にありがとうございます。

8
JDProwler

スレッドにはかなりのコストがかかります-非常に大雑把です-スレッドあたり100Kバイト(それぞれに1つのスタックが必要です)を想像してください。それらはすべて、それらをすべて管理する必要があるオペレーティングシステムコンポーネント(スケジューラなど)にわずかな負担をかけます。

スレッドは非同期タスクを管理するための非常にシンプルなモデルを提供します。私はそのアプローチの大ファンです。

ただし、多くのスレッドを使用する場合は、基になるスレッドオブジェクトを再利用する方法としてスレッドプールを使用することを検討してください(実行可能ファイルはたくさんありますが、実行されません)。

また、C#を使用しているため、非同期タスク( https://docs.Microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ )の方がより効率的な状態です検討する。

しかし、しばしば-実装のシンプルさは効率よりも重要です(ある程度まで)。 (実際のスレッド数を抑制するために)スレッドプールを使用して記述した内容は、うまく機能する場合があります。

9
Lewis Pringle