1

「dd」を使用して、テスト ファイルを作成し、HDD 間でバックアップを実行しました。問題ない。

現在、NFS 転送速度をテストするために使用しようとしています。最初は、ブロック サイズ ("bs" 引数) を変更していました... しかし、これで、なぜこの引数を変更する必要があるのでしょうか?

シミュレートしたい典型的なユースケースは次のとおりです。

  • ノード X のメモリには大きなデータ構造があります
  • ノード X は、NFS マウントされたディレクトリにあるファイルにそれを書き込もうとしています

この場合、2D 配列の典型的な C/C++ コードは次のようになります。

FILE *ptr = fopen("path_to_nfs_area", "w");
for (int i = 0; i < data.size(); ++i)
   fwrite(data[i], sizeof(float), width, ptr);
...

したがって、この場合、32 ビットのインクリメント (sizeof(float)) でバッファーに書き込みます。これは FILE オブジェクトであるため、おそらくバッファーにも入れられます (これは良いことではありませんが、これには無関係かもしれません)。討論）。

「bs」チャンクのif->ofから書き込む「dd」からのジャンプと、メモリから変数を書き出すアプリケーション（およびこれをddでシミュレートする）からジャンプするのに苦労しています。

"bs" の値をシステムの PAGE_SIZE よりも小さく変更しても意味がないと言うのは理にかなっていますか?

これが私の現在の理解であるため、「dd」ブロックサイズを変更することが重要な理由はわかりません。

アプリと NFS/TCP 間の相互作用

4

1 に答える 1

1

この質問はここでは少し話題から外れているため、superuser.com でより良い回答が得られる可能性があります。

ただし、nfs 共有が async フラグでマウントされていない可能性を考慮してください。その場合、次の書き込みが開始される前に、nfs サーバーによって各書き込みが確認される必要があります。そのため、 とbs=1比較して約 2 倍の時間が必要bs=2になり、それぞれが適切なブロック サイズよりもはるかに遅くなります。

nfs マウントで async フラグが設定されている場合、カーネルはいくつかの小さな書き込みを 1 つの大きな書き込みにマージする可能性があるため、設定の影響はbs無視できるはずです。

とにかく、特定のアプリケーションの環境をセットアップするためにテストしている場合は、そのアプリケーションをテストに使用してください。パフォーマンスは、一般的なツールでは再現できないほど多くのアプリケーション固有の動作に依存する場合があります。

于 2014-02-05T21:49:06.170 に答える