分类：
2006-06-20 23:01:50
在 NFS 网络中，服务器是调优的主要目标，当然也有一些是可以在客户机上调优的。
因为 biod 和 nfsd 守护进程一次处理一个请求，并且 NFS 响应时间占了总响应时间的最大一部分，所以如果线程由于缺少 biod 或 nfsd 守护进程而阻塞是让人无法接受的。
配置 NFS 守护进程一般需要注意的事项如下：
决定最佳的 nfsd 和 biod 守护进程数是反复的过程。指导方针能提供给您的仅仅是一个合理的出发点。
缺省值对于小型系统来说是一个很好的起点，但对于拥有两个以上客户的客户机系统或者拥有两个以上客户机的服务器来说就多半需要增加了。以下是一些指导方针：
在您获得初始的 biod 和 nfsd 守护进程数量后，或已经修改了其中的某一个，请照以下说的做：
要修改 nfsd 守护进程的数量，您可以使用 chnfs 命令，或者如前所述设置 nfso nfs_max_threads 参数。
要把在服务器上的 nfsd 守护程序的数量修改为 10，既要立刻生效又要在以后的系统启动时也生效，使用如下命令：
# chnfs -n 10
要把一个系统上的 nfsd 守护进程的数量改为 9，需要直到下一次系统启动才生效，使用如下命令：
# chnfs -I -n 9
要修改每次挂载（mount）的 biod 守护进程数，可使用 biod mount 选项。
增加客户机上的 biod 守护进程数使服务器性能变坏，因为这将允许客户机一次发送更多的请求，而进一步增加网络和服务器的负载。极端情况下，客户机的运行速度远远超过服务器，这时可能需要将客户机的 biod 守护进程数减少到一个，如下：
# stopsrc -s biod
这使得客户机仅仅留下一个 biod 内核进程仍然继续运行。
当您在配置 NFS 挂载目录时有一个可选项就是：挂载或是硬的（-o hard）或是软的（-o soft）。在成功的挂载后，当一个对软挂载（soft-mounted）目录的访问出错时（典型的是一个超时），这个错误被立即报告给原先请求远程访问的那个程序。当一个对硬挂载（hard-mounted）目录的访问出错时，NFS 重试原来的操作。
一个持久性错误引起的不断访问硬挂载目录可能会升级成为一种能察觉得到的性能问题，因为缺省的重试次数是 1000 次，缺省的超时值是 0.7 秒，再加上有一个算法使连续的重试间的超时值增加，这一切意味着 NFS 将试图去完成这个操作。
减少重试次数、增加超时值，或者前两者都做到，这在技术上是可能的，只要使用 mount 命令的选项。不幸的是，修改这些值虽然足以去除先前对性能的可察觉的影响，但是有可能会导致不必要的硬件错误报告。作为一种替代，可以使用 intr 选项来 mount 硬挂载目录，这时当有某个进程进入了重试循环则允许用户使用键盘将其中断。
虽然软挂载目录引起的错误可以被更快地探测到，但是它要冒严重的数据毁坏的风险。因此一般来说，读／写目录应该用硬装载。
:NONE.mount 命令提供了一些 NFS 调优的选项，但由于缺乏对它们的了解而经常被忽视或错误地使用。
在您开始调节 mount 选项前，请确认您应该达到对服务器或网络上的包传送（packet delivery）和包转向（packet turnaround）有一定的认识。如果您的目标是降低 NFS 服务器的负载或者是要解决与网络相关的问题，那么您将会使用绝大部分 NFS 所特有的 mount 选项。
用 mount 命令的 -o 选项可以列出与 NFS 性能相关的所有特定的 mount 选项。:NONE.-o 选项在命令行中只需用一个逗号与命令分隔，而不是用一个逗号加一个空格分隔。
最有用的是改变读和写操作大小值的选项。这些选项定义了每个 RPC 读和写的最大尺寸。:NONE.mount 命令的 rsize 和 wsize 选项常常被减小以减小发向服务器的读／写包。您为什么要减小这两个选项值呢？有两个原因：
减小 rsize 和 wsize 可以在一个比较拥塞的网络上通过向每个 NFS 请求发送较短的包列，从而提高 NFS 性能。但是带来一个副作用，就是需要更多的包在网络上发送数据，增加了网络的通信量，同时在服务器和客户机上都增加了 CPU 的开销。
如果您的 NFS 文件系统是通过一个高速网络挂载的，如 SP Switch，则较大的读／写包能提高 NFS 文件系统的性能。在 NFS V3中，rsize 和 wsize 可以设置最大至 65536，缺省值是 32768。在 NFS V2 中，rsize 和 rsize 最大可以达到 8192，同时这也是缺省值。
在 AIX 5.1 及更新的系统中，您可以通过一种叫延迟释放（release-behind）的机制来提高对位于 NFS 导出文件系统上的大文件的连续 I/O 操作的性能。
更多有关延迟释放的信息，请参见。
在 NFS V3 上的特例中，您试图对一个比客户机内存还要大的文件进行连续写操作，这时您可以使用延迟提交（commit-behind）来提高性能。在通常情况下，写一个大文件会在客户机上引起频繁的页面交换动作。这就使得提交（commit）操作在同一时刻只能执行一个页面。延迟提交给出了一个更具挑战性的逻辑，即将客户机页面提交和返回那些页面到没有任何开销的表（free list）。
您可以在挂载文件系统时指定 combehind 标志 来打开延迟提交功能，该标志在 mount 命令中使用。您还需要为 numclust 变量设置一个适当的值。这个变量指定了虚拟内存管理（VMM）的连续延迟写算法所处理的 16KB 群集的数量。当 I/O 模式是连续的时，使用一个较大的 numclust 值以便能在为它们做 I/O 调度前在内存中保留更多的页面。如果条带化的逻辑卷或磁盘阵列正被使用则需要增大 numclust 值。在 AIX 5.1 上，这个参数可以作为 mount 的一个选项被指定。在 AIX 的早先版本中，使用 vmtune 命令来指定 numclust 的值。
如果您不使用在导出文件系统中支持的 NFS 访问控制列表（ACL），那么您可以通过指定 noacl 选项从一定程度上减轻客户机和服务器上的工作负载。如下操作：
options=noacl
将这个选项设置成客户机上的 /etc/filesystems 中的有关文件系统那一段中的一部分。
硬挂载和软挂载两者哪个更好，这个问题关键在于要在一个给定的网络配置上寻求合适的超时持续时间。如果服务器超负荷运行，与客户机之间隔着一个或多个网桥、网关，又或者通过一个广域网（WAN）与客户机相连，则此时缺省的超时标准就显得不切实际了。如果是这样的话，服务器和客户机都将负荷不必要的重发。例如，命令如下：
# nfsstat -c
报告 timeouts 和 badxids 都是一个很大的数字（大于总数的 5%），您可以增加 timeo 参数，利用以下 SMIT 快捷路径：
# smitty chnfsmnt
定位到您想要改变的那个目录，并在 NFS TIMEOUT 行上输入新的值，以十分之一秒为单位。
缺省值是 0.7 秒（timeo=7），但是该值是由 NFS 内核扩展（NFS kernel extension）根据调用的类型来调整的。例如，对于读调用，该值被加倍成 1.4 秒。
为了对 V4（第四版）的客户机操作系统上的 timeo 值进行控制，您必须把 nfso 命令中的 nfs_dynamic_retrans 选项设置为 0。您有两种方法可以修改 timeo 值，但是在任何给定的情形下，仅有一种正确修改的方法。将超时值延长还是缩短，哪种是正确的方案这取决于包没有在已分配的时间内到达的原因。
如果包仅仅是晚到了一些但最终还是到达了，那么您或许应该将 timeo 变量改得更长一些，这样能在请求重发之前使应答有机会能返回。
然而，如果包被丢弃了则永远不会到达客户机，那么用再长的时间等待响应也只能是浪费时间，这时您应该想到将 timeo 变量改短。
可以评估到底使用哪个选项的一种方法是在客户机上查看 nfsstat -cr 的输出结果，看一看客户机是否报告存在很大的 badxid 数目。:NONE.badxid 值表示某个 RPC 客户机接收到一个其他不同调用的 RPC 调用响应，而非原本应该收到的响应。一般情况下，这意味着客户机收到的是一个先前重发过的调用的重复应答。因而包就到达得晚了，应该让 timeo 值变长。
另外，如果您手头有网络分析仪，就可以用它来测定到底发生了两种情况中的哪一种。即使没有该仪器，您也可以通过试探性地把 timeo 选项调高调低来哪一种提供了更好的总体性能。在一些情形下，运行状态并不是始终如一的。您的最优选择就是找出包延迟／包丢弃的真正原因并解决实际的问题，而问题一般就在服务器设备或网络设备上。
对于由网桥连接起来的两个局域网（LAN-to-LAN）上的流量来说，可以试着将值设成 50（单位：十分之一秒）对于广域网（WAN）连接，尝试 200。至少等上一天后再来检查 NFS 的统计信息。如果信息指示仍然有过多的重发，则将 timeo 增加 50% 后重试。您还要注意检查服务器工作负载以及所涉及到的网桥和网关上的负载，察看它们中的任何一个是否被其他的流量占用而趋于饱和。
假设 NFS 客户机已经检测到有包被丢弃，此时具有挑战性的工作是去发现这些包是在哪里丢失的。包可以被客户机丢弃，可以被服务器丢弃，也同样可以在网络上的某个地方被丢弃。
包很少被客户机丢弃。因为每一个 RPC 调用都是自步长的（self-pacing），也就是说每个调用在继续下一步前必须获得应答，过度使用系统系统资源的几率是微乎其微的。压力最大的操作大概就是读操作了，读的时候可能会达到 1MB/sec 以上进入机器的数据流量。虽然数据容量可以很大，但实际可以并发 RPC 调用数相当的少而且每个 biod 守护进程都有为应答分配的自己的地址空间。因此，包被客户机丢弃是很罕见的。
通常情况下，包要么是被服务器丢弃，要么是在网络上被丢弃。
服务器在繁重的负载下将会丢弃包，存在两种情况：
当 NFS 服务器在对很多请求进行响应时，有时会从接口驱动程序输出队列中溢出。您可以使用 netstat -i 命令来观察所列出的统计信息。检查标记为 Oerrs 的那列，可以看到一些值。每一个 Oerrs 就是一个被丢弃的包。这可以方便地来调优，就是把出问题的那个设备的驱动程序传输队列长度增加。在配置可调队列长度时的思路就是：尽量不要使传输队列过长，因为如果队列过长的话在处理队列时就会有一定的延迟。但是因为 NFS 为调用维护了相同的端口号和 XID，第二次的调用可以用第一次调用的响应来满足。另外，队列处理延迟比在丢包的情形下由 NFS 引起的 UDP 重发延迟要小得多。
服务器丢包的第二个常见的地方是 UDP 套接字缓冲区。被丢弃的包在这里由 UDP 层来计数，使用 netstat -p udp 命令可以显示相关的统计信息。其中标记为 UDP: 的就是套接字缓冲区溢出 信息。
通常情况下，仅当服务器有很多 NFS 写流量时 NFS 包才在套接字缓冲区中被丢弃。NFS 服务器使用一个与 NFS 2049 端口捆绑的 UDP 套接字，所有的输入数据都在这个 UDP 端口被缓冲。这个缓冲区的缺省大小是 60,000 字节。您可以做一个简单的除法：缓冲区大小除以单个写包（write packet）的大小，每个 NFS 写包的缺省大小是 8192 字节，很显然对于缺省大小的缓冲区只要有八个同时到达的写包就已经溢出了。仅仅是两个 NFS 客户机（缺省配置下）就会出现溢出。
这种情况中，套接字上要么是有大容量的流量，要么就是有高突发性的流量。
这两种情况的解决方法是不同的。
您可能还会遇到以下情况：当服务器已被调优且既没有在套接字缓冲区上丢包也没有在适配器驱动程序上的 Oerrs 错误信息，但是客户机仍然在经历超时和重发。这里再次分为了两种情形。如果服务器负载繁重，可能服务器刚刚在超负载运行而现在 nfsd 守护进程在执行日志回写（backlog）工作，导致响应时间超过了客户机上设置的缺省超时值。请参见 获取提示以便确认问题是否在此。另一种可能性，如果服务器是空闲的，那么包就是在网络上被丢弃的。
如果服务器上既没有套接字溢出，也没有 Oerrs 错误信息，而客户机又有很多超时和重发且服务器已知是空闲的，则包很可能是在网络上被丢弃的。牵涉到网络的问题意味着什么呢？意味着很多传播媒介和网络设备，诸如路由器、网桥、集线器和所有那些为使包能在客户机和服务器间实现传输的设备。
当服务器没有超负载且没有丢包，但 NFS 性能差的时候，都可以认为包是在网络上被丢弃的。再努力一下就可以进一步证明这一点并且发现网络究竟是怎样把包给丢弃了。最简便的方法很大程度上取决于物理上的邻近性和可用的资源。
有时服务器和客户机物理上十分接近，使得直接连接非常的容易，而如果要穿越较大的网段就可能引发问题。很显然，如果把两台机器直接相连可以解决原先的问题的话，那么就可以排除问题是由于机器本身原因造成的了。可是在常见的情况下，直接连接又不太可能，因此问题还是必须在适当的位置才能被捕获。
NFS 在每个客户机系统上为最近被访问过的目录和文件维护一个高速缓存。在 /etc/filesystems 文件中有五个参数可设置，用来控制某个指定条目在高速缓存中要保留多久。这些参数如下：
每次文件或目录被更新后，从高速缓存中移除至少要等 acregmin 或 acdirmin 秒。如果是第二次或后续的更新，条目最多被保留的时间至少等于最近两次更新之间的间隔时间，但是不会超过 acregmax 或 acdirmax 秒。
NFS 没有数据缓冲（data-caching）功能，可是虚拟内存管理（VMM）就像缓存磁盘数据的页面那样缓存 NFS 数据的页面。如果一个系统基本上是被当作一个专用的 NFS 服务器的话，最好为 VMM 分配更多的内存，需要多少数据缓冲就分配多少内存。对于导出 JFS 文件系统的服务器，这项分配内存的工作由设置 maxperm 参数来完成，可以控制 JFS 文件系统对内存最大的占用百分比，最高可以设置成 100%。
例如：
# vmtune -P 100
在导出增强的 JFS 文件系统的服务器上，这项分配内存的工作由设置 maxclient 参数来完成。:NONE.maxclient 参数控制客户段页面（client-segment page）对内存最大的占用百分比，而增强的 JFS 文件数据就是在客户段页面中被高速缓存的。
例如：
# vmtune -t 100
同样的技术可以用于 NFS 客户机，但是只有在下面的情况中使用才是恰当的：客户机所运行的工作负载很少需要用到工作段页面（working-segment page）。
高速文件缓存系统可以被用来改善远程文件系统的性能，或提高慢速设备如 CD-ROM 的性能。当一个文件系统被高速缓存以后，从远程文件系统或 CD-ROM 中读取的数据被存储到本地系统的高速缓存中，因此当需要再次读取已访问过的数据时就避免了对网络和 NFS 服务器的使用。CacheFS 被设计为一个分层的文件系统，这说明 CacheFS 提供了将一个文件系统（NFS 文件系统，又称为后台文件系统）缓存到另一文件系统（您的本地文件系统，又称为前台文件系统）上的功能，如下图所示：
请注意在 AIX 4.3 中，只有 NFS V2 和 NFS V3 支持被作为后台文件系统，且只有 JFS 支持被作为前台文件系统。
CacheFS 工作流程如下：
适合用 CacheFS 的一个例子是在 CAD 环境中，其中制图组件的主复本（master-copy）可以保留在服务器上，缓存复本（cached-copy）当使用时存到客户机工作站上。
CacheFS 不允许读写大于或等于 2 GB 的文件。
因为 NFS 数据一旦从服务器读入就被缓存在本地磁盘上，所以与以前还要通过网络再次获取数据相比，NFS 文件系统的读请求可以被更快的满足。根据内存大小以及客户机的使用状况，仅有一小部分的数据可以在内存上存取，所以在磁盘上高速缓存数据的一个益处就是能应用于更多的数据（包括那些不能被保存在内里的数据）。另一个益处是在系统关机后磁盘高速缓存中的数据也能被保留，而缓存于内存中的数据在重新启动后只能再次从服务器上取回了。
其他的潜在 NFS 瓶颈包括：慢速或繁忙的网络和服务于多个 NFS 客户机的弱性能服务器。因此，从客户机系统对服务器的访问就可能很慢。CacheFS 并不能避免您通过网络从服务器上第一次读取数据，但是可以为您避免以后再次通过网络读取相同的数据。
如果更多的读请求可以在客户机上的本地磁盘中就被满足，则对服务器的 NFS 访问数量将势必会减少。这就意味着服务器将有能力为更多的客户机提供服务，如此一来，客户机／服务器比率（client per server ratio）就会上升。
网络上更少的读请求将减轻网络的负载，因此可以使很繁忙的网络释放一些资源出来或腾出空间用以传输其他的数据。
并不是所有的应用程序都能从 CacheFS 获益的。因为 CacheFS 仅能提高读速度性能，因此主要是那些对同一批数据有反复读请求的应用程序才能从 CacheFS 获益。庞大的 CAD 应用程序无疑能从 CacheFS 中获益，因为经常有很大的模型需要被载入用来运算。
性能测试显示从 CacheFS 文件系统上执行连续的读操作要比从 NFS 服务器的内存或磁盘上读快了 2.4 到 3.4 倍。
CacheFS 不会提高 NFS 文件系统的写操作性能。但是当挂载 CacheFS 时，在 mount 命令的 -o 选项中为您提供了两个写操作选项。它们会影响后续对数据读操作的性能。写操作选项如下：
有一些小的读操作可能总是保留在内存中（根据您对内存的使用状况），此时即使将数据缓存在磁盘上也不会带来什么益处了。缓存随机读操作所读的不同数据块是没有意义的，除非您要对同一数据反复地访问。
初始的读请求还是必须发到服务器上去，因为只有当某个用户对后台文件系统上的部分文件进行过访问后，那些文件才会出现在高速缓存中。对于初始的读请求，您将感受到的是普遍的 NFS 速度。只有对同一数据的后续访问您才会感受到本地 JFS 访问的性能。
对于缓存数据的一致性仅仅是隔一段时间才检查一次。因此缓存经常被修改的数据是危险的。CacheFS 应该仅仅 被用于只读（read-only）数据和可改写只读（read-mostly）数据。
NFS V2 和 NFS V3 在高速缓存文件系统上的写操作性能是不同的。性能测试显示：
CacheFS 并不是缺省被实现的，也不是在创建 NFS 文件系统后就启动的。
为了在 AIX 4.3.1 上获得增强的 CacheFS 写性能请确认安装：文件集级别（fileset level）4.3.1.1。
系统管理员必须显式地指定哪个文件系统将被挂载到高速缓存中，如下：
# cfsadmin -c -o 参数 高速缓存目录
上面的参数 特指资源参数，高速缓存目录 是指将高速缓存创建到那个目录的目录名。
# mount -V cachefs -o backfstype=nfs,cachedir=/ 高速缓存目录 remhost:/远程目录 本地挂载点
上面的远程目录 指数据所在的远程主机和文件系统名，本地挂载点 指远程文件系统应该在客户机上的哪个挂载点挂载。
一些参数可以在 CacheFS 创建时被设置，如下：
:NONE.rpc.lockd 守护进程是多线程的，缺省时最多可以创建 33 个线程。在 RPC 文件锁定性为频繁发生的情况下，当 rpc.lockd 守护进程一旦达到它的最大线程数时，它就可能成为一个瓶颈。当达到最大线程数时，任何后续的请求都将等待，这会导致其他的超时。如果存在多于一个的客户机，则 NFS 服务器应该比客户机有更多的 lockd 线程。:NONE.lockd 线程数可以调整为最大不超过 511 的值，如下：
# chsys -s rpc.lockd -a <# of threads> # stopsrc -s rpc.lockd; startsrc -s rpc.lockd
NFS 使用 UDP 或 TCP 来执行网络 I/O。请确保您已经应用了在 和这两部分中所介绍的调优技术。特别地，您应该：
在调优 UDP 的过程中，您可能会发现命令 netstat -s 显示有大量的 UDP 套接字缓冲区溢出。作为一般的 UDP 调优，增大 sb_max 值。您还需要增大 nfs_socketsize 值，这是用来指定 NFS 套接字缓冲区大小的。例如：
# no -o sb_max=131072 # nfso -o nfs_socketsize=130972
上例顺次增加 sb_max 的值，每次比 nfs_socketsize 所期望的值大至少 100 字节，并且将 nfs_socketsize 设置为 130972。
承受高密度写操作的 NFS 服务器能从下面的方法中受益：将日志逻辑卷与数据卷分开而放在一个单独的物理卷上。更详细的信息请参见。
通常情况下，数据访问需要有很高的并行性。多个客户机或者一个客户机的多个进程对服务器上的单个文件系统的并发访问会导致某个特定设备上的磁盘 I/O 成为瓶颈影响吞吐量。您可以使用 iostat 命令来估计磁盘负载。
对于大型的 NFS 服务器，常规策略是将磁盘 I/O 需求平均且最大限度地分配给多个磁盘和磁盘适配器。这样就能获得更大的并发性以及有能力运行更多的 nfsd 守护进程。在一个磁盘 I/O 有良好分布的系统上，可能会调整到一个状态，在这一状态上 CPU 负载成为服务器性能的限制因素。
很多对 NFS 的滥用发生于下面的情形中：由于人们没有意识到他们要访问的文件是在网络的另一端，要访问这些文件需要消耗昂贵的通信代价。有一些这样的例子，如下：
可能有人会说这些是对 NFS 所提供的透明性的正确使用。也许的确如此，但是这些使用方法通用同样消耗了处理器时间、局域网带宽并延长了响应时间。当一个系统配置将 NFS 访问作为标准操作模式的一部分时，设计者应该在迎来技术或商务上的优势的同时，做好准备来抵御由此带来的资源过度消耗。
另一种不应该在 NFS 文件系统上运行的应用程序类型是那些每秒钟调用上百次 lockf() 或 flock() 的应用程序。在 NFS 文件系统上，所有的 lockf() 或 flock() 调用（和其他锁定调用）都必须通过 rpc.lockd 守护进程。这会严重降低系统性能，因为 lockd 守护进程可能无法在一秒钟内处理上千个锁定请求。
无论客户机和服务器的性能容量再怎么大，所有涉及到 NFS 文件锁定的操作会导致让人无法容忍的慢速。这在技术上可以用很多原因来解释，但所有的原因都基于一个事实，那就是如果一个文件被锁定，势必要花更多的开销用于在读写时对文件的同步进行处理。这意味着客户机上不能缓存有任何的文件数据，包括文件属性。所有的文件操作变为完全同步模式而没有了缓冲。如果在 NFS 上运行的一个正在进行网络文件锁定的应用程序显示出很差的性能，甚至比运行在同样的客户机／服务器对上的其他应用程序性能还差，这是令人难以相信的。
以下是一张核对清单，您可以顺着它一步步对 NFS 进行调优：
常规的方法是减慢客户机速度观察是否会增加服务器的性能。以下方法可以各自单独使用：
在受影响的客户机上尝试仅使用一个 biod 守护进程。如果性能改善了，则可知是在网络或服务器上超载。运行 stopsrc -s biod 命令以停止所有的 SRC biod 守护进程。会留下一个内核进程 biod ，有了它您的系统还能够继续运行。观察在仅有一个 biod 进程的情况下，运行速度是否快些了。如果没有效果，则重新启动 biod 守护进程，请用 startsrc -s biod 命令。如果运行得快些了，请尝试着去判断当所有守护进程运行时包是在哪里被丢弃的。网络、网络设备、慢速服务器、超载服务器或没有很好调优的服务器都可能引发这个问题。
这是影响 NFS 服务器的几乎是最普遍的从属于配置的错误。
如果存在任何的 Oerrs ，为网络设备增大发送队列长度。这个操作可以在机器运行时进行，但是在修改（rmdev -l）。前接口必须被分离。您无法在一个无磁盘机器上关闭接口，而且您也没有特权当别的工作仍在进行时关闭接口。这种情况下，您可以使用 chdev 命令将修改保存在 ODM 中，这样的话在下一次启动后就能生效了。第一次时将当前的队列长度值加倍，重复这个过程（以后每次加 30）直到没有 Oerrs 报告为止。在 SP2 系统上，NFS 被配置为要穿越高速交换机，当发生了一个交换机错误或交换机暂时不可用时由于交换机的原因可能会产生 Oerrs。每一次试图发送到交换机的失败都被累加到 Oerr 上。这些错误数不能被消去。
任何一个很大的值都暗示了问题的存在。
当使用 UDP 时，NFS 服务器上的缓冲区溢出是另一个经常需要为 NFS 服务器来配置的问题。TCP 套接字同样可以在十分繁忙的机器上溢出。对两者的调优基本一致，所以本节仅讨论 UDP。
运行 netstat -s 命令并检查 UDP 统计信息中的套接字缓冲区溢出 统计。如果是一个不为 0 的数，则您的 NFS UDP 缓冲区很可能是溢出了。但是，考虑到 UDP 套接字缓冲区丢包数是对整个机器的计数，丢掉的包有可能是 NFS 包也有可能不是。如果您要想确认那个计数指的是 NFS 包，则可以将客户机上的丢包数（通过命令 nfsstat -cr 显示）与在执行 NFS 写测试时的服务器套接字缓冲区溢出关联起来。
套接字缓冲区溢出会在有繁重压力的服务器上发生或在相对于客户机来说较慢的服务器上发生。少于 10 个的套接字缓冲区溢出 并不是什么问题。但是上百个溢出就有点问题了。如果在您观察时这个数值还在不断增大，且 NFS 正好存在性能问题，则 NFS 需要调优。
两个因素可以被用来调优 NFS 套接字缓冲区的溢出问题。第一，尝试增加服务器上运行的 nfsd 守护进程的个数。如果那样并不解决问题，则您必须调节两个内核变量：sb_max（最大套接字缓冲区大小）和 nfs_socketsize （NFS 服务器套接字缓冲区大小）。使用 no 命令可以增加 sb_max。使用 nfso 命令增加 nfs_socketsize 变量的值。
:NONE.sb_max 参数的值必须要大于 nfs_socketsize. 在这里很难提供新的建议值。最佳值就是一方面最小，另一方面可以使 netstat 报告 0 或仅产生少量的套接字缓冲区溢出。
请记住，在 AIX V4 中，套接字的大小是动态设置的。使用 no 和 nfso 命令所作的配置在每次机器启动时必须再作一遍。您最好将它们加入到 /etc/rc.nfs 文件中去，恰在 nfsd 守护进程启动前在 biod 守护进程启动后。加入的位置是十分重要的。
观察是否有 mbufs 请求被拒绝或被延迟。如果是的话，增加网络可用 mbuf 的数量。更详细的关于调优以消除 mbuf 问题的信息，请参见。
很少有例子是由此引起的机器问题。如果在服务器和客户机之间有路由器或其他硬件，则您可以查阅它们的文档，看一下网间包延迟是否可以配置。如果可以，则尝试加大延迟。
当包在两个速度差异很大的传播媒介中传送时，路由器可能会将由高速网发来的包丢弃，并试图从慢速网上抓取包。特别地，一个路由器试图从 FDDI 光纤网上的服务器取包并将这些包发送到位于以太网上的客户机。向以太网发送包的速度显然不能跟上 FDDI 的速度。唯一的解决方案是尝试去减少客户机的请求量、使用更小的读／写大小和限制可用于单个文件系统的 biod 守护进程。
运行 netstat -i 命令并检查客户机和服务器上的 MTU。如果它们不同，则试着将它们改成同一个数看问题能否消除。另外要注意机器间的慢速或广域网、路由器或网桥，这些都可能在不同网段中传输时进一步分段。试着确定源与目的之间的最小 MTU，在 NFS mount 命令中修改 rsize/wsize 为某个小于 MTU 最小公分母的数。
使用 traceroute 命令来查看无法预料的路由转发或延迟。
运行 errpt 命令来查看网络设备或网络传输媒介的问题报告。还要寻找任何影响在导出文件系统上的 NFS 服务器性能的磁盘错误。
