我正在运行一个debian服务器,通过NFS(nfs-kernel-server)导出一个大的JFS文件系统(22TB)。当试图写入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服务器线程的数量太less。 这个数字应该高得多,而不是8。
对于仅包含小文件并且被less数用户(例如家庭networking)或慢速networking(10Mbit)访问的共享,8个线程可能就足够了。
在写入时尝试确定NFS服务器上的重传值:
nsstat -r
如果您获得传输重试,请增加服务器线程的数量。
我认为这将是从您的挂载选项删除rsize / wsize / tcp设置保存。 无论如何,TCP是默认的协议,使用TCP不需要限制传输大小。
我怀疑JumboFrames有一些问题。 检查使用两个接口卸载configuration
sudo ethtool -k your_nic
并尝试使用wireshark听电线。 你可能会发现一些乱七八糟的包裹
也许这与用于写入和jfs的nfslocking不兼容。 我发现在Ubuntu的一些错误: https : //bugs.launchpad.net/ubuntu/+source/jfsutils/+bug/754495