http://cloud.csdn.net/a/20110211/291647.html
简介
在考虑 Network File Systems (NFS) 时,通常性能调优是您会想到的最后一件事。您太过专注于合理配置文件系统和确保系统的安全性,因而可能经常忘记 NFS 中的 N 代表网络。遗憾的是,如果您重视 NFS 调优,您可能有一个性能很差的 NFS。所幸,IBM 集成了若干工具来帮助监控和调优 AIX 上的 NFS,包括 nfsstat 和 nfsmo。本文将描述这种监控和调优。
与之前版本的 AIX 一样,AIX 7 支持 NFS v2、v3 和 v4(默认为 NFS v4)。一般而言,NFS v4 应当优先于之前的版本得到使用,因为它更高效且通常处理大负荷和繁忙网络环境的性能。大多数现代客户端操作系统支持 NFS v4,因此无需支持旧的版本。
您必须同时调优客户端和服务器。本文解释如何使用 netpmon 为 NFS 客户端和 NFS 服务器监控读写子例程。您还可以使用 nmon 简要了解 NFS 活动,了解如何使用 nmon 来分析历史数据。您可以使用 netstat 验证网络的健康状况,因为较低的网络使用率(或设计不当的配置)会导致较差的 NFS 性能。本文还探讨 nfs4cl 等可用于特定 NFS 版本的实用工具。您还将了解一些最佳实践,包括跨尽量多的轴数传播 I/O。在这种情况下,CPU 负载是瓶颈,而非 I/O 系统。
与本系列的其他调优示例不同,对于 NFS,您必须监控(而且可能需要调优)所有子系统,包括 CPU、内存、I/O 和网络。从客户端角度来看,NFS 文件系统使用远程连接的磁盘。影响该挂载磁盘性能的所有因素会影响 NFS 客户端的性能。本文还讨论重要的守护进程,比如 nfsd 和 biod,以及它们如何进行自我调优。您可以通过客户端与服务器之间的基本交互来理解幕后情况。最后,本文强调,不管您在调优哪个子系统,系统优化都是一个持续的过程。当然,监控系统的最佳时间是从一开始还未遇到问题和用户呼救之前。因为有太多的因素会影响 NFS 性能,一次仅进行一项更改,以便可以准确地评估更改的影响。
NFS 回顾
本节概述 NFS,因为它与 AIX 7 相关。您可以了解客户端与服务器如何相互关联,以及影响 NFS 性能的各种因素。
您可以在挂载文件系统期间选择版本类型,而且您可以在服务器上运行不同版本的 NFS。NFS 目前同时支持 TCP 和 UDP。因为 UDP 较快(做的较少),对最佳性能的需求胜于可靠性的一些环境(LAN 上)使用 UDP 可能会更好。TCP 更可靠(通过建立连接),它还在 WAN 上提供更好的性能,因为它的流程控制有助于最小化网络延迟。
NFS 的优势在于,它独立于机器类型和操作系统。它通过使用 Remote Procedure Calls (RPCs) 实现这一点,如图 1 所示。
图 1. 客户端与服务器之间的交互
图 1 展示 NFS 客户端 A 和 B 如何访问 NFS Server Z 上的数据。客户端计算机首先通过挂载文件系统请求访问导出的数据。然后当客户端线程试图处理 NFS 挂载文件系统内的数据,数据被重定向到 biod,biod 通过 LAN 将数据带到 NFS 服务器及其 nfsd 守护进程。服务器使用 nfds 导出可用于其客户端的目录。
可以看出,您需要调优网络和 I/O 参数。如果 Server Z 性能很差,这显然会影响它的所有 NFS 客户端。如果可能,专门调优服务器,使其具有 NFS 服务器的功能(稍后详细说明)。
那么 biod 守护进程呢?执行预读和后写请求都需要用到该守护进程。biod 守护进程改进总体 NFS 性能,因为它要么清空、要么填满缓冲区高速缓存,充当客户端应用程序的一个联系。如 图 1 所示,biod 守护进程向服务器发送请求。另一方面,nfsd 是向客户端提供 NFS 服务的联系。当服务器接收来自客户端的 biod 通信时,服务器使用 nfsd 守护进程,直至请求完成。
为何在版本 4 之前 NFS 是无状态的,即使它早在版本 2 就可以使用 TCP?图 2 展示 NFS 与 TCP/IP 栈和 OSI 模型的关联。
图 2. OSI - TCP/IP - NFS
NFS 不位于传输堆栈上,因为 NFS 使用 Remote Procedure Calls (RPCs)。RPCs 是一个程序库,允许客户端和服务器进程执行系统调用,如同这些调用是在其自己的地址空间执行的。在一个典型的 UDP NFS 版本 2 或 3 实现中,在授权客户端共享卷之后,NFS 服务器向其客户端发送一种 cookie。问题在于,如果服务器发生故障,客户端会继续通过请求泛滥网络。这就是偏好于使用 TCP 的原因。只有版本 4 可以使用有状态的连接,且只有版本 4 将 TCP 用作其传输协议。
NFS 版本 4 与端口映射程序或其他守护进程,比如 lockd 和 statd,之间无交互,因为它们大批进入内核。在除版本 4 之外的其他版本中,端口映射程序用于注册 RPC 服务,并为客户端与服务器之间的通信提供端口号。External Data Representation (XDR) 提供机制来供 RPC 和 NFS 用来确保客户端与服务器之间的可靠数据交换。对于二进制数据的交换,它以一种独立于平台的方式进行。这解决了系统以不同方式表示数据的可能性。使用 XDR 可以正确解译数据,即使在不一样的平台上。
监控
本节概述可用于监控 NFS 系统的工具。这些工具能使您快速对性能问题进行故障排除,并获取相关的数据以便进行历史趋势研究和分析。其中一些工具通常用于服务器,而其它工具则通常用于客户端。本节介绍 nmon、topas、 nfsstat、nfs、nfs4cl 和 netpmon。
nmon 和 topas
对于 NFS 调优,您最初可以使用 topas 或 nmon 这样的工具,因为它们提供一个漂亮的仪表板视图,显示系统中正在进行的工作。请记住,NFS 性能问题可能与您的 NFS 子系统根本没有任何关系。您的瓶颈可能出现在网络中,或者从服务器的角度来看,在您的 CPU 或者磁盘 I/O 中。运行诸如 topas 或 nmon 之类的工具可以使您迅速地了解真正的问题所在。本文中的示例系统有两个 CPU,且它正在运行 AIX 5.3 TL6。
图 3 从 NFS 角度显示了 nmon 的输出。
图 3. nmon 输出
使用 nmon,可以从 NFS(客户端和服务器)的角度查看到所有可用的信息。在这个系统中,当前不存在任何瓶颈。尽管最近 topas 已经提高了捕获数据的能力,但是 nmon 仍然可能是更好的选择。nmon 提供了类似于 topas 的前端,但是 nmon 更适合于长期趋势研究和分析。而且,nmon 为系统管理员提供了将数据输出到 Microsoft® Excel 电子表格的能力,该表格产生美观的图表(专为高级管理和功能团队定制),清楚地展示您的瓶颈。这些工作通过一个名为 nmon 分析器 的工具完成,该工具提供了到 nmon 的接口。可以免费下载 nmon 分析器(参见 参考资料)。
如何使用 nmon 捕获数据并将其导入到分析器?使用 sudo,首先运行 nmon 3 个小时,每隔 60 秒拍一次快照:# sudo nmon -f -t -r test1 -s 60 -c 180。然后为创建的输出文件排序:# sort -A systemnfs_yymmdd.nmon > systemnfs_yymmdd.csv。
接下来,通过 ftp 将 .csv 文件传输到您的计算机,启动 nmon 分析器(启用宏),并单击 analyze nmon data。
nfsstat
可以说,nfsstat 工具是您将使用的最重要的工具。该命令显示有关 NFS 和 RPC 调用的所有类型的信息。可以将 nfsstat 作为一种监控工具来诊断问题和进行性能调优。根据您使用的标志,您可以使用 nfsstat 显示 NFS 客户端或服务器信息。它还可以显示文件系统操作的实际使用次数。这有助于您准确理解利用每个文件系统的方式,从而最好地调优系统。
首先看一下客户端标志(c)。r 标志提供 RPC 信息(参见 清单 1)。
清单 1. 使用 c 标志运行 nfsstat
root@lpar24ml162f_pub[/] > nfsstat -cr l488pp065_pub[/tmp] > nfsstat -cr Client rpc: Connection oriented calls badcalls badxids timeouts newcreds badverfs timers 279 0 0 0 0 0 0 nomem cantconn interrupts 0 0 0 Connectionless calls badcalls retrans badxids timeouts newcreds badverfs 24 0 0 0 0 0 0 timers nomem cantsend 0 0 0 |
这意味着什么呢?下面是一些面向连接的参数:
如果您发现 timeouts 或者 badxids 的值很大,那么可以通过使用 mount 命令增大 timeo 参数来进行解决(稍后将详细描述)。
nfs
现在来看一下 清单 2 中的 nfs 信息(n 标志)。
清单 2. nfs n 标志信息
l488pp065_pub[/tmp] > nfsstat -cn Client nfs: calls badcalls clgets cltoomany 279 0 0 0 Version 2: (0 calls) null getattr setattr root lookup readlink read 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% wrcache write create remove rename link symlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 0 0% Version 3: (279 calls) null getattr setattr lookup access readlink read 0 0% 126 45% 14 5% 9 3% 17 6% 0 0% 1 0% write create mkdir symlink mknod remove rmdir 51 18% 6 2% 0 0% 0 0% 0 0% 0 0% 0 0% rename link readdir readdir+ fsstat fsinfo pathconf 0 0% 0 0% 1 0% 1 0% 1 0% 1 0% 0 0% commit 51 18% |
您应当检查 badcalls 数目,确保它不是太高(您可以根据调用统计数据计算一个简单的百分比)。遗憾的是,cltoomany 统计数据显示有问题存在,但是没有方法解决这个问题。
对于其余统计数据,您对单个操作进行计数。这仅适用于确定您是否正在处理大量读写操作,在这种情况下,您可能希望重组您的磁盘和 NFS 共享分配。
nfs4cl
如果您正在运行 NFS 版本 4,那么您可能会更多地使用 nfs4cl。这个命令可以显示 NFS 版本 4 的统计信息和属性(参见 清单 3)。
清单 3. 使用 nfs4cl
l488pp065_pub[/tmp] > nfs4cl showfs Server Remote Path fsid Local Path -------- --------------- --------------- --------------- |
清单 4. 运行 mount 命令
l488pp065_pub[/tmp] > mount node mounted mounted over vfs date options -------- --------------- --------------- ------ ------------ --------------- /dev/hd4 / jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/hd2 /usr jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/hd9var /var jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/hd3 /tmp jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/hd1 /home jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/hd11admin /admin jfs2 Jul 30 03:16 rw,log=/dev/hd8 /proc /proc procfs Jul 30 03:16 rw /dev/hd10opt /opt jfs2 Jul 30 03:16 rw,log=/dev/hd8 /dev/livedump /var/adm/ras/livedump jfs2 Jul 30 03:16 rw,log=/dev/hd8 192.168.1.11 /userdata/20009539 /home/u0009539 nfs3 Jul 30 03:22 bg,hard,intr,rw /dev/fslv00 /wpars/webserver1 jfs2 Aug 13 09:42 rw,log=INLINE /dev/fslv01 /wpars/webserver1/home jfs2 Aug 13 09:42 rw,log=INLINE /opt /wpars/webserver1/opt namefs Aug 13 09:42 ro /proc /wpars/webserver1/proc namefs Aug 13 09:42 rw /dev/fslv02 /wpars/webserver1/tmp jfs2 Aug 13 09:42 rw,log=INLINE /usr /wpars/webserver1/usr namefs Aug 13 09:42 ro /dev/fslv03 /wpars/webserver1/var jfs2 Aug 13 09:42 rw,log=INLINE |
您可以配置的一些关键参数包括:
下面的 清单 5 向您展示如何做到这一点。
清单 5. 使用 nfs4cl 调优 timeo
root@lpar24ml162f_pub[/] > nfs4cl setfsoptions mnt rbr=7 |
netpmon
可以使用 netpmon 命令帮助对 NFS 瓶颈进行故障排除。除了监视许多其他类型的网络统计信息之外,netpmon 还可以监视客户端:包括读取和写入子例程、以及 NFS RPC 请求。对于服务器,netpmon 可以监视读取和写入请求。netpmon 将启动跟踪并在后台运行,直到您停止它为止(参见 清单 6)。
清单 6. 使用 netpmon
l488pp065_pub[/tmp] > netpmon -T 2000000 -o /tmp/net.out Run trcstop command to signal end of trace. Sun Aug 15 04:58:06 2010 System: AIX 7.1 Node: l488pp065_pub Machine: 00F604884C00 |
清单 7. 停止跟踪
l488pp065_pub[/tmp] > trcstop[netpmon: Reporting started] 23675650 Missed Entries found [netpmon: Reporting completed] [ 4 traced cpus ] [ 0.091 secs total preempt time ] |
现在来看一下这个输出文件中所提供的 NFS 特定的信息(参见 清单 8)。
清单 8. 输出文件中的 NFS 特定的信息
NFSv3 Client RPC Statistics (by Server): ---------------------------------------- Server Calls/s ---------------------------------- p650 126.68 ------------------------------------------------------------------------ Total (all servers) 126.68 Detailed NFSv3 Client RPC Statistics (by Server): ------------------------------------------------- SERVER: p650 calls: 5602 call times (msec): avg 1.408 min 0.274 max 979.611 sdev 21.310 COMBINED (All Servers) calls: 5602 call times (msec): avg 1.408 min 0.274 max 979.611 sdev 21.310 |
使用 nfsmo 和 mount 进行调优
本节描述特定的 nfs 调优命令。使用 nfsmo 以设置并显示您的 nfsstat 调优参数。使用 mount 优化基于 NFS 服务器的资源,而这只有在挂载了 NFS 文件系统之后才能生效。
客户端
The biod 守护进程在连接性方面起到了很重要的作用。当 biod 自我调优线程数量(该守护进程根据需要创建和删除线程)时,可以根据整体负载,对 biod 线程的最大数目进行优化。这里有一个非常重要的概念需要理解,仅增加线程的数目并不能减轻由 CPU、I/O 或者内存瓶颈所引起的性能问题。例如,如果您的 CPU 使用率接近 100%,那么增加线程数量对您并没有任何帮助。当多个应用程序线程访问相同的文件、并且不存在任何其他类型瓶颈的时候,增加线程数目可以起到帮助作用。使用 lsof 可以进一步帮助您确定哪些线程正在访问哪些文件。
在前面的调优系列文章中,您可能还记得虚拟内存管理器(VMM)的参数 minperm 和 maxperm。与调优数据库服务器有所不同,对于 NFS 来说,您希望允许 VMM 使用尽可能多的 RAM 来进行 NFS 数据缓存。大多数 NFS 客户端对于工作段页面的需求很少。为了确保所有的内存都用于文件缓存,可以将 maxperm 和 maxclient 设置为 100%。在 AIX 7(和 AIX 6)中,两个参数都是受限的可调参数,也就是说它们的限度是经严格搁置和限制的(参见 清单 9)。
清单 9. 将 maxperm 和 maxclient 设置为 100%
l488pp065_pub[/tmp] > vmo -o maxperm%=100Setting maxperm% to 100 Warning: a restricted tunable has been modified l488pp065_pub[/tmp] > vmo -o maxclient%=100Setting maxclient% to 100 Warning: a restricted tunable has been modified |
Mount 参数 rsize 和 wsize 分别定义读取和写入目录的 RPC 包的最大值。默认值是 32768 个字节。对于 NFS 版本 3 和 4,如果在高速网络中挂载您的 NFS 卷,那么您应该将这个值增大到 65536。另一方面,如果您的网络速度非常缓慢,那么您可能会为了通过发送较短的包来减少包碎片的数量,而考虑减少这个默认值。然而,如果您减少这个默认值,那么将需要发送更多的包,这可能会增加整体网络的使用率。了解您的网络,并对其进行相应的优化!
服务器
在分析特定的 NFS 参数之前,尝试减少网络中的负载,同时分析 CPU 和 I/O 子系统。瓶颈通常会导致一些看似 NFS 特定的问题。例如,NFS 既可以使用 TCP,也可以使用 UDP,这取决于您所使用的版本和您的偏好。请确保将您的 tcp_sendspace 和 tcp_recvspace 值设置得高于默认值,因为这可能会通过增加网络性能而对您的服务器产生影响。不能使用 nfso 对这些内容进行优化,而是使用 no(参见 清单 10)。
清单 10. 将 tcp_sendspace 和 tcp_recvspace 的值设置得高于默认值
l488pp065_pub[/tmp] > no -a|grep send ipsendredirects = 1 ipsrcroutesend = 1 send_file_duration = 300 tcp_sendspace = 16384 udp_sendspace = 9216 l488pp065_pub[/tmp] > no -o tcp_sendspace=524288Setting tcp_sendspace to 524288 Change to tunable tcp_sendspace, will only be effective for future connections |
清单 11. 启用 nfs_rfc1323
l488pp065_pub[/tmp] > no -o rfc1323=1Setting rfc1323 to 1 Change to tunable rfc1323, will only be effective for future connections |
与客户端类似,如果服务器是专门的 NFS 服务器,那么请确保您对 VMM 参数进行了相应的优化。将 maxperm 和 maxclient 参数更改为 100%,以确保 VMM 在进程中使用尽可能多的内存来控制页面文件的缓存。在服务器中,调优多线程的 nfsd,就像调优 biod(您可以调优其他守护进程,包括 rpc.mountd 和 rpc.lockd)。与 biod、nfsd 的自我调优一样,这取决于具体的负载情况。使用 nfso 命令增加线程的数目。一个这样的参数是 nfs_max_read_size,该参数将设置读取应答 RPC 的最大大小。
看一下 清单 12 中将 nfs_max_read_size 设置为什么。
清单 12. 设置 nfs_max_read_size 参数
l488pp065_pub[/tmp] > nfso -L nfs_max_read_size NAME CUR DEF BOOT MIN MAX UNIT TYPE DEPENDENCIES -------------------------------------------------------------------------------- nfs_max_read_size 64K 64K 64K 512 64K Bytes D ------------------------------------------------------------------------------- |
清单 13. 使用带 -L 标志的 nfso 命令
l488pp065_pub[/tmp] > nfso -L NAME CUR DEF BOOT MIN MAX UNIT TYPE DEPENDENCIES -------------------------------------------------------------------------------- client_delegation 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- nfs_max_read_size 64K 64K 64K 512 64K Bytes D -------------------------------------------------------------------------------- nfs_max_write_size 64K 64K 64K 512 64K Bytes D -------------------------------------------------------------------------------- nfs_rfc1323 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- nfs_securenfs_authtimeout 0 0 0 0 60 Seconds D -------------------------------------------------------------------------------- nfs_server_base_priority 0 0 0 31 125 Pri D -------------------------------------------------------------------------------- nfs_server_clread 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- nfs_use_reserved_ports 0 0 0 0 1 On/Off D -------------------------------------------------------------------------------- nfs_v3_server_readdirplus 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- nfs_v4_fail_over_timeout 0 0 0 0 3600 Seconds D -------------------------------------------------------------------------------- portcheck 0 0 0 0 1 On/Off D -------------------------------------------------------------------------------- server_delegation 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- utf8_validation 1 1 1 0 1 On/Off D -------------------------------------------------------------------------------- |
结束语
本文讨论了网络文件系统(NFS),包括其历史和不同版本。本文定义并介绍了 NFS I/O 堆栈、以及该堆栈与 OSI 模型和 TCP/IP 堆栈模型之间的关系。本文还介绍了在 NFS 环境中进行磁盘配置和 VMM 优化的最佳实践。
您研究了对客户端和服务器进行调优的区别。您对整体网络进行了监视,并且在监视的过程中深入地分析了 NFS 层。而且,您使用 nfso 和 mount 调优了您的系统。
在本系列文章的下一个部分中,您将深入地研究实际的网络包。其中将包括对 netstat 的更加详细的介绍。您还将了解如何使用 no 实用工具来优化您的网络子系统。