c# - C# マルチスレッドファイル IO (読み取り)

Question

アプリケーションが一連のファイルを処理する必要がある状況があり、この機能を同期的に実行するのではなく、マルチスレッドを使用してワークロードを異なるスレッドに分割したいと考えています。

作業の各項目は次のとおり
です。 1. ファイルを読み取り専用で開く
2. ファイル内の
データを処理する 3. 処理されたデータをディクショナリに書き込む

各ファイルの作業を新しいスレッドで実行したいですか? これは可能で、ThreadPool を使用するか、「作業」の各項目が 30 ミリ秒しかかからないことを念頭に置いて新しいスレッドを生成することをお勧めしますが、何百ものファイルを処理する必要がある可能性があります。

これをより効率的にするためのアイデアは大歓迎です。

編集: 現時点では、これを処理するために ThreadPool を使用しています。処理するファイルが 500 個ある場合、ファイルを循環し、QueueUserWorkItem を使用して各「処理作業単位」をスレッドプールに割り当てます。

これにスレッドプールを利用するのは適切ですか?

score 8 · Accepted Answer

この場合ThreadPool.QueueUserWorkItem(...)、スレッドはシステムと.netフレームワークによって管理されます。自分のスレッドプールと噛み合う可能性ははるかに高くなります。したがって、.netが提供するスレッドプールを使用することをお勧めします。とても使いやすいです、

ThreadPool.QueueUserWorkItem(new WaitCallback(YourMethod), ParameterToBeUsedByMethod);

YourMethod(object o){ Your Code here... }

詳細については、リンクhttp://msdn.microsoft.com/en-us/library/3dasc8as%28VS.80%29.aspxをたどってください。

お役に立てれば

score 2 · Accepted Answer

スレッドを処理したり、スレッドプールを直接管理したりする代わりに、Parallel Extensions (PEX)のような高レベルのライブラリを使用することをお勧めします。

var filesContent = from file in enumerableOfFilesToProcess
                   select new 
                   {
                       File=file, 
                       Content=File.ReadAllText(file)
                   };

var processedContent = from content in filesContent
                       select new 
                       {
                           content.File, 
                           ProcessedContent = ProcessContent(content.Content)
                       };

var dictionary = processedContent
           .AsParallel()
           .ToDictionary(c => c.File);

PEX は、利用可能なコアと負荷に応じてスレッド管理を処理し、ユーザーは目の前のビジネスロジックに集中できます (うわー、コマーシャルのように聞こえました!)。

PEX は .Net Framework 4.0 の一部ですが、Reactive Framework の一部として 3.5 へのバックポートも利用できます。

score 2 · Accepted Answer

有限数のスレッド (たとえば 4) を使用し、4 つの作業プールを使用することをお勧めします。つまり、処理するファイルが 400 個ある場合、スレッドごとに 100 個のファイルを均等に分割します。次に、スレッドを生成し、それぞれの作業を渡し、特定の作業が完了するまで実行させます。

一定量の I/O 帯域幅しかないため、スレッドが多すぎてもメリットはありません。また、スレッドの作成にも少し時間がかかることに注意してください。

score 1 · Accepted Answer

長い目で見れば、スレッドを自分で管理した方が幸せになれると思います。これにより、実行中の数を制御し、ステータスを簡単に報告できるようになります。

処理を行うワーカークラスを構築し、結果とステータスを返すコールバックルーチンを提供します。
ファイルごとに、ワーカーインスタンスとそれを実行するスレッドを作成します。スレッドをに入れますQueue。
同時に実行したい最大数までスレッドをキューから剥がします。各スレッドが完了すると、別のスレッドを取得します。最大値を調整し、スループットを測定します。Dictionary私は実行中のスレッドを保持するために a を使用することを好みManagedThreadIdます。
早く停止するには、キューをクリアします。
スレッドコレクションをロックして、健全性を維持します。

score 1 · Accepted Answer

低レベルのスレッド処理の詳細を処理するCCR (Concurrency and Coordination Runtime)を使用することをお勧めします。戦略に関しては、ディクショナリへの書き込み方法によっては、作業項目ごとに 1 つのスレッドが最適なアプローチではない場合があります。ディクショナリはスレッドセーフではないため、激しい競合が発生する可能性があるためです。

CCR を使用したサンプルコードを次に示します。ここではインターリーブがうまく機能します。

Arbiter.Activate(dispatcherQueue, Arbiter.Interleave(
    new TeardownReceiverGroup(Arbiter.Receive<bool>(
        false, mainPort, new Handler<bool>(Teardown))),
    new ExclusiveReceiverGroup(Arbiter.Receive<object>(
        true, mainPort, new Handler<object>(WriteData))),
    new ConcurrentReceiverGroup(Arbiter.Receive<string>(
        true, mainPort, new Handler<string>(ReadAndProcessData)))));

public void WriteData(object data)
{
    // write data to the dictionary
    // this code is never executed in parallel so no synchronization code needed
}

public void ReadAndProcessData(string s)
{
    // this code gets scheduled to be executed in parallel
    // CCR take care of the task scheduling for you
}

public void Teardown(bool b)
{
    // clean up when all tasks are done
}

score 0 · Accepted Answer

個々のタスクごとに ThreadPool を使用することは、間違いなく悪い考えです。私の経験からすると、これはパフォーマンスを向上させるどころか、パフォーマンスを低下させる傾向があります。1 つ目の理由は、ThreadPool を実行するためのタスクを割り当てるためだけに、かなりの量のオーバーヘッドが必要になることです。デフォルトでは、各アプリケーションには、最大 100 スレッド容量で初期化された独自の ThreadPool が割り当てられます。400 の操作を並行して実行している場合、キューがリクエストで満たされるのにそれほど時間はかかりません。現在、最大 100 のスレッドがすべて CPU サイクルをめぐって競合しています。はい、.NET フレームワークは、キューのスロットリングと優先順位付けで素晴らしい仕事をしますが、ThreadPool は、おそらくあまり頻繁に発生しない長時間実行される操作 (構成ファイルの読み込み、またはランダムな Web 要求) のために残しておくのが最善であることがわかりました。）。ThreadPool を使用してランダムにいくつかの操作を開始することは、数百の要求を一度に実行するために使用するよりもはるかに効率的です。現在の情報を考えると、最善の行動方針は次のようなものになります。

アプリケーションが要求を投稿できるキューを使用して、System.Threading.Thread を作成します (または SINGLE ThreadPool スレッドを使用します)。
FileStream の BeginRead メソッドと BeginWrite メソッドを使用して、IO 操作を実行します。これにより、.NET フレームワークはネイティブ API を使用して IO (IOCP) をスレッド化および実行します。

これにより、2 つのレバレッジが得られます。1 つは、オペレーティングシステムがファイルシステムアクセスとスレッドを管理できるようにしながら、リクエストが並行して処理されることです。2 つ目は、大多数のシステムのボトルネックが HDD になるため、カスタムの優先度の並べ替えとスロットリングをリクエストスレッドに実装して、リソースの使用をより細かく制御できることです。

現在、私は同様のアプリケーションを作成しており、この方法を使用すると効率的で高速です...スレッド化やスロットリングがなければ、アプリケーションは 10 ～ 15% の CPU しか使用していませんでしたが、関連する処理によっては一部の操作で許容できる場合があります。、アプリケーションが CPU の 80% 以上を使用しているかのように PC が遅くなりました。これはファイルシステムアクセスでした。ThreadPool および IOCP 関数は、PC の動作が遅くなっても気にしないので、混乱しないでください。たとえそのパフォーマンスが HDD の豚のようにきしむことを意味するとしても、これらはパフォーマンスのために最適化されています。

私が経験した唯一の問題は、一度に約 35 のストリームを開いているテスト段階で、メモリ使用量が少し高くなった (50 MB 以上) ことです。私は現在、SocketAsyncEventArgsに対する MSDN の推奨事項と同様のソリューションに取り組んでおり、プールを使用して x 数のリクエストを同時に処理できるようにしているため、最終的にこのフォーラムの投稿にたどり着きました。

これが将来の意思決定に役立つことを願っています:)

score 0 · Accepted Answer

ThreadPool.QueueUserWorkItemそれぞれの独立したタスクを実行するために使用します。何百ものスレッドを作成しないでください。それは大きな頭痛を引き起こす可能性があります。

score 0 · Accepted Answer

ThreadPool を使用する一般的なルールは、スレッドがいつ終了するか (またはミューテックスを使用してスレッドを追跡するか) を心配したくない場合、またはスレッドの停止について心配したくない場合です。

それで、仕事がいつ終わるか心配する必要がありますか？そうでない場合は、ThreadPool が最適なオプションです。全体的な進行状況を追跡したい場合は、スレッドを停止してから、独自のスレッドのコレクションが最適です。

スレッドを再利用している場合は、一般に ThreadPool の方が効率的です。この質問により、より詳細な議論が得られます。

H番目

c# - C# マルチスレッド ファイル IO (読み取り)

8 に答える 8

Related

Reference

c# - C# マルチスレッドファイル IO (読み取り)