取势 明道 优术

nfs优化 2,841 views

作者为 扶 凯 发表

总结和测试了一下自己的经验:

NFS中的rsize、wsize

rsize、wsize对于NFS的效能有很大的影响.wsize和rsize设定了SERVER和CLIENT之间往来数据块的大小,这两个参数的合理设定与很多方面有关,不仅是软件方面也有硬件方面的因素会影响这两个参数的设定(例如LINUX KERNEL、网卡,交换机等等).
下面这个命令可以简单测试NFS的执行效能,读和写的效能可以分别测试,分别找到合适的参数.对于要测试分散的大量的数据的读写可以通过编写脚本来进行测试.在每次测试的时候最好能重复的执行一次MOUNT和unmount.
time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
用于测试的wsize,rsize最好是1024的倍数,大多的时候,默认是4K(4096),对于NFS V2来说8192是rsize和wsize的最大数值,如果使用的是NFS V3则可以尝试的最大数值是32768.
我测试过,在内网比较合理的每个客户机应该用 rsize=32768,wsize=32768,intr,noatime 挂装远程文件系统,从而确保速度:

    * 使用大的读/写块(数字指定最大块大小,在这个示例中是 32KB).
    * 在挂起时 NFS 操作可以被中断.
    * 不持续更新 atime.

可以将这些设置放在 /etc/fstab 中.

注意,在测试rsize和wsize比mtu值大时,server的包发送到client要进行重组,会要浪费二者的cpu.另外重组也会导致nfs不稳定,因为丢包会让rpc重传,重传象tcp一样,会导致超时,可以通过查看/proc/sys/net/ipv4/ipfrag_high_thresh和/proc/sys/net/ipv4/ipfrag_low_thresh了解系统处理包的数量,如果包到了ipfrag_high_thresh就会开始丢包.真到数目达到ipfrag_low_thresh.

NFS客户端的数目
在服务器端,一定要确保有足够的 NFS 内核线程来处理所有客户机.在默认情况Red Hat系统会启动8个线程.对于繁忙的 NFS 服务器,应该提高这个数字,比如32或64.可以用 nfsstat -rc 命令评估客户机,了解是否有阻塞的现象,这个命令显示客户机远程过程调用(RPC)统计数据.
例:
# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
95374234   3432       0

第二列retrans是3432,这表示从上一次系统启动以来出现了3432次重新传输的情况.这个数字比较大,就应该考虑增加NFS线程.
设置方法是将所需的线程数量设置到nfs,比如设置128 会启动 128 个线程.任何时候都可以进行这种设置.线程会根据需要启动或销毁.同样,这个设置应该放在启动脚本中,尤其是在系统上启用 NFS 的脚本.

如RedHat和Centos
vim /etc/init.d/nfs

找到下面这行修改
[ -z "$RPCNFSDCOUNT" ] && RPCNFSDCOUNT=32 

如上,我修改的是启动32个.随着nfsd数目的增加,平均负载会上升(可用uptime查看),就应减少nfsd数目.平时测试和客户端的数量一样多就行.

NFS的版本
关于 NFS,需要注意一点:避免使用 NFSv2,因为 NFSv2 的性能比 v3 和 v4 差得多.当前的Linux 发行版中这应该不是问题,我们可以在nfs的服务器上检查nfsstat 的输出,了解是否有任何 NFSv2 调用.

Client nfs v3:
null         getattr      setattr      lookup       access       readlink    
0         0% 13536     0% 1         0% 14150     0% 26160     0% 0         0%
read         write        create       mkdir        symlink      mknod       
95313570 99% 70        0% 1         0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus 
0         0% 0         0% 0         0% 0         0% 56        0% 6650      0%
fsstat       fsinfo       pathconf     commit      
15        0% 8         0% 0         0% 15        0%

Client nfs v4:
null         read         write        commit       open         open_conf   
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
open_noat    open_dgrd    close        setattr      fsinfo       renew       
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
setclntid    confirm      lock         lockt        locku        access      
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
getattr      lookup       lookup_root  remove       rename       link        
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
symlink      create       pathconf     statfs       readlink     readdir     
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
server_caps  delegreturn 
0         0% 0         0%

如上,都是v3和v4的.

启动了NFS之后又修改了/etc/exports,是不用重新启动nfs呢?这个时候我们就可以用exportfs命令来使改动立刻生效,该命令格式如下:
exportfs [-aruv]
-a :全部mount或者unmount /etc/exports中的内容
-r :重新mount /etc/exports中分享出来的目录
-u :umount 目录
-v :将详细的信息输出到屏幕上.

mountd 与 nfsd 共享一个访问控制数据库,除了内核内部的表之外,这个数据库的运行副本通常还保存在一个称为 /var/lib/nfs/xtab 的文件中.
因为xtab并不是供人阅读的,所以要使用另外的命令来添加和修改其中的项,就是用exportfs

# nfsstat -s //显示NFS服务器进程的统计信息
# nfsstat -c //显示与客户端操作相关的信息

NFS传送的方式UDP and TCP
可以手动进行设置,也可以自动进行选择.
mount -t nfs -o sync,tcp,noatime,rsize=1024,wsize=1024,tcp EXPORT_MACHINE:/EXPORTED_DIR /DIR
UDP 有着传输速度快,非连接传输的便捷特性,但是UDP在传输上没有TCP来的稳定,当网络不稳定或者黑客入侵的时候很容易使NFS的 Performance 大幅降低甚至使网络瘫痪.所以对于不同情况的网络要有针对的选择传输协议.nfs over tcp比较稳定,nfs over udp速度较快.在机器较少网络状况较好的情况下使用UDP协议能带来较好的性能,当机器较多,网络情况复杂时推荐使用TCP协议(V2只支持UDP协议).在局域网中使用UDP协议较好,因为局域网有比较稳定的网络保证,使用UDP可以带来更好的性能,在广域网中推荐使用TCP协议,TCP协议能让 NFS在复杂的网络环境中保持最好的传输稳定性.可以参考这篇文章:http: //www.hp.com.tw/ssn/unix/0212/unix021204.asp.
根据原理,有时TCP在内网不会丢失包的情况下,也可能会性能好很多,所以,最好也测试一下.
补充:
UDP套接口溢出:在带有许多UDP客户机的一台NFS服务器上,当所有nfsd线程都在使用,而此时又有请求到达的时候,就会发生UDP套接口溢出.可使用netstat -s命令监测溢出数目,增加更多的nfsd直到UDP套接口溢出数目降为0.溢出表明服务器提供的守护进程数量不足,所以增加的nfsd要比通过这种方法测量出来的数目多几个.

NFS的队列大小
在linux 2.2和2.4内核里,默认的8个nfsd的输入队列大小是64K,2.6内核是108K.下面将设置为较合理的值256K
# echo 262144 > /proc/sys/net/core/rmem_default
# echo 262144 > /proc/sys/net/core/rmem_max
# echo 262144 > /proc/sys/net/core/wmmen_default
# echo 262144 > /proc/sys/net/core/wmmen_max

 

网络传输包的大小

在不同的网络当中,因为tcp/ip需要给文件分成一个个的数据包,过大和过小都会影响很大,所以需要对网络包大小进行不同的package测试.常用的方法ping -s 2048 -f hostname进行ping.来测试不同的网络传送包的大小.这样可以了解不同的包大小的包丢失情况.同时,还可以使用nfsstat -o net 测试nfs使用udp传送时的丢包率.

 

来了就留个评论吧! 5个评论



    timo 2009年06月2日 的 17:13

    我在实际测试过程中居然tcp比udp更快无论读写。而我使用mount -t nfs 不加其它参数的时候是最快的。不知道问题出现在哪里

    稀饭 2009年06月21日 的 11:52

    {NFS} RPC: error 512 求助
    我的文件都是存放在nfs中的..
    平时访问就算是访问量大的时候都不会有问题..
    但是最近出现一个奇怪的问题.网络结果一直都没有更变过.
    client 段这边系统message 有如下这样的提示.
    client 是做web的…通过nfsmount数据然后提供服务.
    RPC: error 512 connecting to server all-web-nfs-2
    RPC: error 512 connecting to server all-web-nfs-2

    在all-web-nfs-2
    这台机器上面没有发现其他的异常.
    但是如果一旦client出现了
    RPC: error 512 connecting to server all-web-nfs-2
    RPC: error 512 connecting to server all-web-nfs-2
    势必导致用户在访问client web的时候访问不了..
    google中找了一些资料但是还是没有很好的理解.这个问题产生的原因.
    个人怀疑一个可能是
    1.交换机丢包. (在出现问题的时候,没有去抓包.所以也不知道是不是怀疑的正确)
    2.网卡掉了.(client 查看的没有任何问题, nfs server 在出现RPC错误的时候也没有出现问题)

    google找到的资料..
    http://www.linux.ie/lists/pipermail/ilug/2007-January/091593.html
    有人说升级内核可以解决问题.
    Wow, that’s old. And googling for that ‘RPC: error 512’ string leads
    one to:

    https://lists.dulug.duke.edu/pip … ovember/016625.html

    So upgrading the kernel on the server might be an idea alright.

    regards,
    我使用的nfs server版本是
    Server nfs v3:
    希望可以知道产生 RPC: error 512 的错误的原因和这错误是什么情况产生的.
    nfs lockd 会导致RPC:error 512 么…求教…..

    Aceslup 2015年01月6日 的 10:23

    比较担心的就是客户端正在使用时,服务端出现问题。一不小心连机器都关不掉呢。