2011-11-16 12 views
5

私は現在、ネットワークから最大8つのオーディオストリームをフェッチし、ディスクにデータを保存する(簡略化された)オーディオレコーディングアプリケーションに取り組んでいます。 今、各ストリームは1つのスレッドによって処理されます - >同じスレッドがディスク上の保存作業を行います。LinuxファイルIO - マルチスレッディングのパフォーマンス - 異なるファイルへの書き込み

つまり、同じディスクにそれぞれ異なるファイルに書き込みを実行する8つのスレッドがあります。

すべての書き込み作業が1つの共通スレッド(特定のファイルにデータを順次書き込む)によって行われる場合、ディスクのI/Oパフォーマンスが向上すると思いますか?それは埋め込ま、Linuxの場合は

OSは、組込みLinux、「ディスク」であるが、CFカードで、アプリケーションはC.

にあなたのアイデアを

おかげ ニック

+0

CFカードは実際のフラッシュメモリベースですか、それともmicroHDD(Microdrive)ですか? – osgx

+0

実際のフラッシュですが、使用されているコントローラのために、OSによってATAデバイスとして認識されています。 – Nick

答えて

3

短い答え:あなたがフラッシュディスクに書き込んでいることを考えると、スレッドの数が何らかの大きな違いをもたらすとは思わないでしょう。しかし、それが違いを生み出すならば、私は、複数のスレッドが単一のスレッドより速く、遅くなることはないと期待します。

長い答え:

私は約6年前、あなたが記述1と同様のプログラムを書いた - それは、組み込みのPowerPC Linuxのカードの上に走り、読み/に/ SCSIハードディスクからの複数の同時オーディオファイルを書きましたドライブ。最初はI/Oを実行するスレッドを1つ作成していましたが、これは最高のスループットが得られると思ったからですが、そうではないことが判明しました。

特に、複数のスレッドが同時に読み取り/書き込みを行っていた場合、SCSIレイヤーはすべての異なるスレッドからのすべての保留中の要求を認識し、I/O要求を並べ替えることができました最小化されました。一方、シングルスレッド-IOシナリオでは、SCSI層は単一の「次の」未処理I/O要求のみを知っていたため、最適化を行うことができませんでした。これは多くの場合、ドライブヘッドの余分な移動を意味し、したがってスループットが低下しました。

もちろん、シークが必要なヘッドを搭載したSCSIや回転ドライブは使用していないため、問題はないかもしれませんが、ファイルシステム/ハードウェアレイヤで実行できるその他の最適化があるかもしれません複数の同時I/O要求を認識しています。調べる唯一の本当の方法は、さまざまなモデルを試して結果を測定することです。

私は、ディスクI/Oをスレッドプールに移動することで、ディスクI/OとネットワークI/Oを切り離すことを提案します。次に、I/Oスレッドプールの最大サイズを1からNに変更することができます。また、サイズごとにシステムのパフォーマンスを測定することもできます。そうすれば、コードを複数回書き直す必要なく、特定のハードウェアに最適なものを明確に知ることができます。

+0

ネットワークI/Oは既にディスクから切り離されています。ネットワークIOを処理する1つのスレッドがあります - オーディオメッセージはキューに入れられ、余分なスレッドでディスクに書き込まれます。 (そして、すべての録音チャンネルの合計= 16スレッド)スレッドプールであなたの提案を試してみましょう。何か結果が出たらすぐにお知らせします。 – Nick

0

を書かれて、私はあなたを推測しますマシンにはプロセッサ/コアが1つしかありません。この場合、スレッドはI/Oパフォーマンスをまったく向上させません。もちろん、Linuxのブロックサブシステムは並行環境ではうまくいきますが、あなたのケースでは(コアの数についての私の推測が正しいとすれば)、いくつかのスレッドが同時に何かをする状況はありません。

私の推測が間違っていて、コアが2つ以上ある場合は、ディスクI/Oをベンチマークすることをお勧めします。異なるスレッドからの多くのデータと同じスレッドを実行する別のプログラムを書き込むプログラムを作成します。結果はあなたが知りたいすべてのものを表示します。

+0

あなたは正しいです、ただ一つのコアがあります。今のマルチスレッドの理由は、各記録チャンネルをカプセル化されたユニットとして持つことだけです。 1つのチャンネルで問題が発生した場合、他の人たちも希望どおりに作業することができます。私はあなたが正しいと思う、答えを得る唯一の方法はいくつかのベンチマークをすることです。ありがとう – Nick

0

あなたのケースでは、マルチスレッドとシングルスレッドのソリューションに大きな違いはないと思いますが、マルチスレッドの場合は、受信スレッド間で同期することができ、一部のシステムコールでブロックすると他のスレッドに影響を及ぼすことはありません。
埋め込みシステムでは同じことをやっていましたが、問題は、カーネルが多くのキャッシュされたダーティページをCFにドロップしたときのCPU使用率が高くなっていて、pdflushカーネルプロセスがその時点ですべてのCPU時間をとり、 udpストリームが来たときにCPUがビジーだったのでスキップされるので、私はfdatasync()でその問題を解決しました。

関連する問題