現在、NFS(nfs-kernel-server)を介して大規模なJFSファイルシステム(22TB)をエクスポートしているDebianサーバーを実行しています。NFS共有に書き込もうとすると、パフォーマンスが非常に低下します。 22TBディスクは、iSCSIを使用してマウントされたNAS)にあります。
NFSサーバー:
cat /etc/exports
/data2 10.1.20.86(rw,no_subtree_check,async,all_squash)
cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq
cat /etc/default/nfs-kernel-server
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
NFSクライアント:
cat /etc/fstab
10.1.20.100:/data2 /root/incoming nfs rw,noatime,soft,intr,noacl 0 2
cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq
cat /proc/mounts
10.1.20.100:/data2/ /root/incoming nfs4 rw,noatime,vers=4,rsize=262144,wsize=262144,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.1.20.86,minorversion=0,addr=10.1.20.100 0 0
この問題は私をかなり困惑させました。どんな助けでも大歓迎です。ありがとう。
私の推測では、NFSサーバースレッドの数が少なすぎます。 8の代わりに、その数ははるかに大きくなるはずです。
小さなファイルのみを含み、非常に少数のユーザー(ホームネットワークなど)または低速ネットワーク(10メガビット)でアクセスされる共有には、おそらく8スレッドで十分です。
書き込み中にNFSサーバーの再トランス値を決定してみてください。
nsstat -r
送信を再試行する場合は、サーバースレッドの数を増やしてください。
そして、マウントオプションからrsize/wsize/tcp設定を削除するのは節約になると思います。 TCPはとにかくデフォルトのプロトコルであり、TCPでは転送サイズを制限する必要はありません。
JumboFramesに問題があると思われます。を使用して、両方のインターフェイスのオフロード構成を確認します
Sudo ethtool -k your_nic
また、wiresharkを使用してワイヤーを聞いてみてください。いくつかの異常なパケット、重複などが見つかる場合があります...
多分それは書き込みとjfsに使用されるnfsロックとの非互換性です。私はubuntuでいくつかのバグを見つけました: https://bugs.launchpad.net/ubuntu/+source/jfsutils/+bug/754495