同じホストで実行されている 2 つの Xen 仮想マシン (クライアントとサーバー) 間の NFS パフォーマンスが低い原因を特定しようとしています。具体的には、クライアントで 1 GB のファイルを連続的に読み取る速度が、2 つの VM 間の測定されたネットワーク接続速度とサーバーで直接ファイルを読み取る測定速度に基づいて予想される速度よりもはるかに遅いです。VM は Ubuntu 9.04 を実行しており、サーバーは nfs-kernel-server パッケージを使用しています。
さまざまな NFS チューニング リソースによると、nfsd スレッド (私の場合はカーネル スレッド) の数を変更するとパフォーマンスに影響する可能性があります。通常、このアドバイスは、頻繁に使用されるサーバーでデフォルトの 8 から数を増やすという観点から構成されています。現在の構成で私が見つけたものは次のとおりです。
RPCNFSDCOUNT=8: (デフォルト): クライアント上で1GBのファイルをcatするのに13.5～30秒かかるので、35～80MB/秒
RPCNFSDCOUNT=16: ファイルのcatに18秒、60MB/秒
RPCNFSDCOUNT=1: 8～9秒ファイルをcatする（！！？）125MB/秒
RPCNFSDCOUNT=2: ファイルのcatに87秒、12MB/秒
私がエクスポートしているファイルは、Xen の PCI パススルーを使用してサーバーにマウントされた RevoDrive SSD 上にあることを述べておきます。サーバー上では、数秒以内にファイルを cat できます (> 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 はそれらにまたがってストライプ化された fakeRAID-0 を取得し、これを /mnt/ssd にマウントしてから /export/ssd にバインドマウントします。両方の場所を使用してファイルでローカル テストを実行し、上記のように良好なパフォーマンスを確認しました。回答/コメントで詳細を求められた場合は、追加します。
答え1
クライアントからのリクエストが来ると、そのリクエストはスレッドの 1 つに渡され、残りのスレッドは先読み操作を行うように要求されます。ファイルを読み取る最も速い方法は、1 つのスレッドでそれを順番に行うことです... したがって、1 つのファイルの場合、これはやり過ぎであり、スレッドは本質的に自分自身でより多くの作業を行っています。ただし、1 つのクライアントが 1 つのファイルを読み取る場合に当てはまることは、実際の環境で展開する場合に必ずしも当てはまるとは限りません。したがって、帯域幅/CPU 仕様に基づいてスレッド数と先読み数を決定する式に従ってください。