2つのマシンを10ギガビットイーサネットで接続しています。それらの1つをNFSサーバー、もう1つをNFクライアントにします。
TCP with iperf
を使用してネットワーク速度をテストすると、両方向で〜9.8ギガビット/秒のスループットが示されるため、ネットワークは問題ありません。
NFSサーバーのディスクパフォーマンスのテスト:
dd if=/dev/zero of=/mnt/test/rnd2 count=1000000
結果は〜150 MBytes/sなので、ディスクは書き込みに適しています。
サーバーの/etc/exports
は:
/mnt/test 192.168.1.0/24(rw,no_root_squash,insecure,sync,no_subtree_check)
クライアントはこの共有をローカル/mnt/test
にマウントし、次のオプションを使用します。
node02:~ # mount | grep nfs
192.168.1.101:/mnt/test on /mnt/test type nfs4 (rw,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101)
NFS共有からクライアントマシンに大きなファイル(〜5Gb)をダウンロードしようとすると、サーバーのローカルディスクのパフォーマンスに近い130〜140 MBytes/sのパフォーマンスが得られるため、問題ありません。
しかし、大きなファイルをNFS共有にアップロードしようとすると、アップロードは約1.5Mバイト/秒で始まり、ゆっくりと最大18-20Mバイト/秒まで増加し、増加が止まります。アップロードが実際に開始する前に、共有が数分間「ハング」する場合があります。つまり、ホスト間のトラフィックがゼロに近づき、ls /mnt/test
を実行しても、1〜2分間は戻りません。次に、ls
コマンドが返され、初期の1.5Mbit/sの速度でアップロードが開始されます。
アップロード速度が最大(18〜20メガバイト/秒)に達したとき、iptraf-ng
を実行すると、ネットワークインターフェースで190メガビット/秒のトラフィックが表示されるため、ネットワークとサーバーのHDDがボトルネックになることはありません。
私が試したもの:
1。 100MbitイーサネットNICのみで接続された3番目のホストにNFSサーバーをセットアップします。結果は類似しています:DLは良好なパフォーマンスとほぼ100Mビットのネットワーク使用率を示し、アップロードは毎秒数百キロバイトより速く実行されないため、ネットワーク使用率は非常に低くなります(2.5Mビット/秒iptraf-ng
)。
2。いくつかのNFSパラメータを調整しようとしました:
sync
またはasync
noatime
いいえhard
私の例ではrsize
とwsize
が最大なので、いくつかのステップで8192まで減らしました。
。クライアントマシンとサーバーマシンを切り替えようとしました(以前のクライアントにNFSサーバーをセットアップし、その逆も同様)。さらに、同じ構成のサーバーがさらに6つあるため、さまざまなバリエーションで相互にマウントしてみました。同じ結果。
4。 MTU = 9000、MTU = 9000および802.3adリンク集約、MTU = 1500のリンク集約。
5。 sysctlチューニング:
node01:~ # cat /etc/sysctl.conf
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem= 10240 873800 16777216
net.ipv4.tcp_wmem= 10240 873800 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000
同じ結果。
6。ローカルホストからマウント:
node01:~ # cat /etc/exports
/mnt/test *(rw,no_root_squash,insecure,sync,no_subtree_check)
node01:~ # mount -t nfs -o sync localhost:/mnt/test /mnt/testmount/
そして、ここでも同じ結果が得られます:/mnt/testmount/
からのダウンロードは高速で、/mnt/testmount/
へのアップロードは非常に遅く、22 MBytes/s未満であり、転送が実際に開始するまでに少し遅延があります。ネットワークスタックが問題なく動作し、問題はNFSにあるということですか?
これはすべて役に立ちませんでした。結果はデフォルトの構成と大きく異なりませんでした。 echo 3 > /proc/sys/vm/drop_caches
はすべてのテストの前に実行されました。
3つのホストすべてのすべてのNICSのMTUは1500であり、非標準のネットワークチューニングは実行されていません。イーサネットスイッチはDell MXL 10/40Gbeです。
OSはCentOS 7です。
node01:/mnt/test # uname -a
Linux node01 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
どの設定が欠けていますか? NFSを素早くハングなしで書き込む方法は?
エクスポートステートメントでsync-optionを使用します。これは、サーバーが実際にディスクに書き込まれた後にのみ書き込み操作を確認することを意味します。ディスクが回転している(つまりSSDがない)場合、スローダウンの原因である書き込み操作ごとに、平均でディスクの少なくとも1/2回転が必要です。
非同期設定を使用すると、サーバーは、処理されたがまだディスクに書き込まれていないときに、クライアントへの書き込み操作をただちに確認します。これは、クライアントが発生しなかった操作の確認応答を受け取ったときに電源障害が発生した場合など、少し信頼性が低くなります。ただし、書き込みパフォーマンスは大幅に向上します。
(編集)非同期と同期のオプションをすでにテストしているのを見ました。ただし、これがパフォーマンスの低下の問題の原因であることはほぼ間違いありません。かつて、まったく同じ設定でまったく同じ兆候がありました。もう一度テストしてみてください。サーバーのエクスポートステートメントとクライアントのマウント操作で同時に非同期オプションを指定しましたか?
これは、パケットサイズと遅延に関連する問題である可能性があります。以下を試してください:
結果を報告するレポート。
http://veerapen.blogspot.com/2011/09/tuning-redhat-enterprise-linux-rhel-54.html
ハードウェアRAIDを備えたシステムでLinuxスケジューラを構成し、デフォルトを[cfq]から[noop]に変更すると、I/Oが改善されます。
Nfsstatコマンドを使用して、読み取り/書き込みの割合を計算します。一致するようにRAIDコントローラーのキャッシュ比率を設定します。
ワークロードが重い場合は、NFSサーバースレッドの数を増やす必要があります。
No_delayオプションを使用して、ディスクに遅延なく書き込むようにnfsスレッドを構成します。
Linuxカーネルにできるだけ早くフラッシュして、書き込みができるだけ少なくなるようにします。 Linuxカーネルでは、ダーティページの書き戻しの頻度を2つのパラメーターで制御できます。
ディスクへの書き込みを高速化するには、filesystem data = journalオプションを使用して、ファイルアクセス時間の更新を防止します。これにより、追加のデータがディスクに書き込まれます。このモードは、データの読み取りと書き込みを同時に行う必要がある場合に最速で、他のすべてのモードよりもパフォーマンスが優れています。