10

多数のオーディオ ファイルがあり、処理アルゴリズムを実行して、そこから特定のデータ ビット (つまり、クリップ全体の平均ボリューム) を抽出しようとしています。以前に Samba ネットワーク共有から入力データを取得した多くのビルド スクリプトがあり、ネットワーク ドライブ マッピングを作成しましたnet use(例: M: ==> \\server\share0)。

新しい大容量の 1 TB SSD を手に入れたので、ファイルをローカルに保存して非常に迅速に処理できます。処理スクリプトの大規模な書き直しを避けるために、ネットワーク ドライブ マッピングを削除し、localhostホスト名を使用して再作成しました。すなわち: M: ==> \\localhost\mydata.

このようなマッピングを使用する場合、データが Windows のネットワーク スタックの一部を通過しなければならないなど、大きなオーバーヘッドが発生するリスクがありますか?それとも、OS が何らかのショートカットを使用するので、多かれ少なかれダイレクト ディスクと同等になりますか?アクセス (つまり、マシンは自分のハード ドライブからファイルをプルしているだけだと認識していますか)。レイテンシーの増加は私の懸念事項ではありませんが、最大の持続平均スループットは重要です。

これは、すべての処理スクリプトをネットワーク パスの異なるスタイルで動作するように変更する必要があるかどうかを判断しているためです。

追加の質問: 同じことが Linux ホストにも当てはまりますか? それらは、ローカル ディスクからプルしていることを認識できるほどスマートですか?

4

2 に答える 2

5

このようなマッピングを使用すると、かなりのオーバーヘッドが発生するリスクがありますか?

はい。\\hostname\sharename\filenameローカル パス ( ) ではなくUNC パス ( ) を使用すると[\\?\]driveletter:\directoryname\filename、すべてのトラフィックがサーバー メッセージ ブロック プロトコル (SMB / Samba) 経由で発生します。これにより、ディスク アクセスと一般的なアクセス時間の点で、かなりのオーバーヘッドが追加されます。

ネットワーク上のフローは次のようになります。

Application -> SMB Client -> Network -> SMB Server -> Target file system

ここで、ファイルをローカル マシンに移動しますが、引き続き UNC を使用してファイルにアクセスすると、フローは次のようになります。

Application -> SMB Client -> localhost -> SMB Server -> Target file system

最小化した唯一のもの (排除されたわけではありません。localhost への SMB トラフィックには、ネットワーク層と関連するすべての計算とトラフィックが含まれます) は、ネットワーク トラフィックです。

また、SMB はネットワーク トラフィック用に特別に調整されているため、その読み取りでディスクや OS のキャッシュが最適に使用されない場合があります。たとえば、特定のサイズのブロックで読み取りを実行し、別のサイズのブロックを読み取るとディスクのパフォーマンスが向上する場合があります。

最適なスループットと最小限のアクセス時間が必要な場合は、ファイルシステムに直接アクセスすることにより、可能な限り少ないレイヤーを使用します。

Application -> Target file system
于 2015-12-03T12:08:26.923 に答える
4

確かに、「ループバック」を使用しても直接ファイル アクセスで TCP を使用すると、ルーティング、メモリ割り当てなどのオーバーヘッドが Linux と Windows の両方で発生します。はい、ループバック デバイスは非物理カーネル デバイスであり、他のネットワーク デバイスよりも高速ですが、他のネットワーク デバイスよりも高速ではありません。ファイルへの直接アクセス。私が Windows で知っている限り、NetDNA や "Fast TCP Loopback" などの追加のループバック最適化があります。

ループバック デバイスのボトルネックは、メモリ (コピー) プロセスになると思います。そのため、Linux と Windows の両方で、ループバック デバイスではなく直接ファイルにアクセスする方が常に高速 (かつリソースの消費量が少ない) になります。

さらに、どちらのオペレーティング システムも、Windows では「名前付きパイプ」を、Linux では「UNIX ドメイン ソケット」を介して IPC のプロトコル オーバーヘッドを解決します。

于 2015-12-03T11:42:21.787 に答える