奇妙なnfsパフォーマンス：1スレッドが8より優れ、8スレッドが2より優れています！
同じホストで実行されている2台のXen仮想マシン（クライアントとサーバー）間でnfsのパフォーマンスが低下する原因を特定しようとしています。具体的には、クライアントで1GBのファイルを順番に読み取ることができる速度は、2つのVM間のネットワーク接続速度の測定値とサーバーでファイルを直接読み取る速度の測定値に基づいて予想される速度よりもはるかに遅くなります。 VMはUbuntu9.04を実行しており、サーバーはnfs-kernel-serverパッケージを使用しています。
さまざまなNFSチューニングリソースによると、nfsdスレッド（私の場合はカーネルスレッド）の数を変更すると、パフォーマンスに影響を与える可能性があります。通常、このアドバイスは、頻繁に使用されるサーバーでデフォルトの8から数を増やすという観点から組み立てられています。現在の構成で見つけたもの：
RPCNFSDCOUNT=8 :(デフォルト）：クライアントで1GBファイルをキャットするために13.5-30秒なので、35-80MB /秒
RPCNFSDCOUNT=16：ファイルをキャットする18秒60MB /秒
RPCNFSDCOUNT=1：8-9秒ファイルをcatする（!!？！）125MB/s
RPCNFSDCOUNT=2：ファイルを12MB /秒でキャットする87秒
私がエクスポートしているファイルは、XenのPCIパススルーを使用してサーバーにマウントされたRevoDriveSSDにあることを言及する必要があります。サーバー上では、数秒（> 250MB /秒）でファイルをキャットできます。各テストの前に、クライアントにキャッシュをドロップしています。
複数のクライアントがある場合はうまく機能しないと思うので、サーバーを1つのスレッドだけで構成したままにしたくはありませんが、それがどのように機能するかを誤解している可能性があります。テストを数回繰り返し（サーバー構成を変更する）、結果はかなり一貫しています。だから私の質問は：なぜ1スレッドで最高のパフォーマンスなのですか？
私が変更しようとした他のいくつかのことは、ほとんどまたはまったく効果がありません。
/ proc/sys/net/ipv4/ipfrag_low_threshおよび/ proc/sys/net/ipv4/ipfrag_high_threshの値をデフォルトの192K、256Kから512K、1Mに増やします
/ proc/sys/net/core/rmem_defaultおよび/ proc/sys/net/core/rmem_maxの値をデフォルトの128Kから1Mに増やします
クライアントオプションを使用したマウントrsize = 32768、wsize = 32768
Sar -dの出力から、基盤となるデバイスに送られる実際の読み取りサイズはかなり小さい（<100バイト）ことがわかりますが、クライアントでローカルにファイルを読み取る場合、これは問題を引き起こしません。
RevoDriveは実際には2つの「SATA」デバイス/ dev/sdaと/ dev/sdbを公開し、dmraidは/ mnt/ssdにマウントしてから、/ export/ssdにバインドマウントした偽のRAID-0をピックアップします。両方の場所を使用してファイルのローカルテストを実行し、上記の良好なパフォーマンスを確認しました。回答/コメントで詳細が必要な場合は、追加します。
クライアント要求が着信すると、それはスレッドの1つに渡され、残りのスレッドは先読み操作を実行するように求められます。ファイルを読み取る最も速い方法は、1つのスレッドに順番に実行させることです...したがって、1つのファイルの場合、これはやり過ぎであり、スレッドは本質的に、より多くの作業を実行します。ただし、1つのクライアントが1つのファイルを読み取る場合に当てはまるのは、現実の世界にデプロイする場合は必ずしも当てはまらないため、帯域幅/ CPUの仕様に基づいてスレッド数と先読み数を計算する式に固執します。