NFS 性能调优

 

在 NFS 网络中，服务器是调优的主要目标，当然也有一些是可以在客户机上调优的。

 

需要多少 biod 和 nfsd 守护进程？

因为 biod 和 nfsd 守护进程一次处理一个请求，并且 NFS 响应时间占了总响应时间的最大一部分，所以如果线程由于缺少 biod 或 nfsd 守护进程而阻塞是让人无法接受的。

 

配置 NFS 守护进程一般需要注意的事项如下：

• 增加守护进程的数量并不能用来弥补客户机或服务器的处理器能力低下、内存不足以及服务器磁盘传输宽带的不足。在改变守护进程数量之前，您应该先用 iostat 和 vmstat 命令来检查一下服务器和客户机的资源利用级别。
• 如果 CPU 或 磁盘子系统已经接近于饱和级别，那么增加守护进程的数量并不会带来更好的性能。
• NFS 守护进程相对来说开销不大。:NONE.biod 或 nfsd 守护进程只需要很少的几个内存页（其中有些是固定〔pinned〕的）。当然，没有被固定的（unpinned）页面仅当 nfsd 或 biod 守护进程最近被激活过时才真正存在于内存中。此外，空闲的 nfsd 或 biod 守护进程不耗费 CPU 时间。
• 所有的 NFS 请求都通过 nfsd 守护进程；但是只有读写操作才通过 biod 守护进程。

选择初始的 nfsd 和 biod 守护进程的数目

决定最佳的 nfsd 和 biod 守护进程数是反复的过程。指导方针能提供给您的仅仅是一个合理的出发点。

缺省值对于小型系统来说是一个很好的起点，但对于拥有两个以上客户的客户机系统或者拥有两个以上客户机的服务器来说就多半需要增加了。以下是一些指导方针：

• 在每个客户机上，估计将会发生并发写操作的最大文件数。为每个文件配置至少两个 biod 守护进程。如果文件比较大（大于 32KB），为了支持预读（read-ahead）或后写（write-behind）行为，您可能需要为每个文件启动四个 biod 守护进程。为一个很大的频繁进行写操作的文件配置五个 biod 守护进程也是很普遍的。
• 在每个服务器上，开始时把 nfsd 守护进程数配置成同已经为客户机从服务器处理文件的 biod 守护进程一样多的数量。考虑到非读写的 NFS 请求，在原先的基础上再加 20% 的数量。
• 如果您在一台慢速服务器上连有快速的客户机工作站，那么您必须限制客户机产生 NFS 请求的速率。最佳的解决方案是减少客户机上 biod 守护进程的数量，并对每个客户机负载和响应时间的相对重要性给予适当的关注。

nfsd 和 biod 守护进程数的调优

在您获得初始的 biod 和 nfsd 守护进程数量后，或已经修改了其中的某一个，请照以下说的做：

• 首先，用 vmstat 和 iostat 命令重新检查受影响系统的 CPU 或 I/O 饱和度。如果服务器现在就饱和了，您必须减少负载或增加处理器能力，也可以两者都满足。
• 使用命令 netstat -s 来判断是否有系统正在经历 UDP 套接字缓冲区溢出。如果确是那样的话，用命令 no -a 去证实一下调优其他层来提高 NFS 的性能 一小节中已经实现了的推荐方法。如果可行，系统没有饱和，就可以增加 biod 或 nfsd 守护进程的数量。
• 检查 nullrecv 列，给列位于命令 nfsstat -s 的输出结果中。如果这个数字开始增长，那便说明 nfsd 守护进程的个数太多了。然而，这种情况在我们的操作系统的 NFS 服务器上出现的概率比在其他平台上出现的概率要小得多。原因在于当有一个 NFS 请求进入服务器时，并不是所有的 nfsd 守护进程被同时唤醒。而是这样的，第一个 nfsd 守护进程被唤醒，如果还有更多的工作要做的话，由它再去唤醒第二个 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 挂载（hard NFS mounts）或软 NFS 挂载（soft NFS mounts）的性能推断

当您在配置 NFS 挂载目录时有一个可选项就是：挂载或是硬的（-o hard）或是软的（-o soft）。在成功的挂载后，当一个对软挂载（soft-mounted）目录的访问出错时（典型的是一个超时），这个错误被立即报告给原先请求远程访问的那个程序。当一个对硬挂载（hard-mounted）目录的访问出错时，NFS 重试原来的操作。

一个持久性错误引起的不断访问硬挂载目录可能会升级成为一种能察觉得到的性能问题，因为缺省的重试次数是 1000 次，缺省的超时值是 0.7 秒，再加上有一个算法使连续的重试间的超时值增加，这一切意味着 NFS 将试图去完成这个操作。

减少重试次数、增加超时值，或者前两者都做到，这在技术上是可能的，只要使用 mount 命令的选项。不幸的是，修改这些值虽然足以去除先前对性能的可察觉的影响，但是有可能会导致不必要的硬件错误报告。作为一种替代，可以使用 intr 选项来 mount 硬挂载目录，这时当有某个进程进入了重试循环则允许用户使用键盘将其中断。

虽然软挂载目录引起的错误可以被更快地探测到，但是它要冒严重的数据毁坏的风险。因此一般来说，读／写目录应该用硬装载。

其他影响性能的 mount 选项

:NONE.mount 命令提供了一些 NFS 调优的选项，但由于缺乏对它们的了解而经常被忽视或错误地使用。

在您开始调节 mount 选项前，请确认您应该达到对服务器或网络上的包传送（packet delivery）和包转向（packet turnaround）有一定的认识。如果您的目标是降低 NFS 服务器的负载或者是要解决与网络相关的问题，那么您将会使用绝大部分 NFS 所特有的 mount 选项。

用 mount 命令的 -o 选项可以列出与 NFS 性能相关的所有特定的 mount 选项。:NONE.-o 选项在命令行中只需用一个逗号与命令分隔，而不是用一个逗号加一个空格分隔。

rsize 和 wsize 选项

最有用的是改变读和写操作大小值的选项。这些选项定义了每个 RPC 读和写的最大尺寸。:NONE.mount 命令的 rsize 和 wsize 选项常常被减小以减小发向服务器的读／写包。您为什么要减小这两个选项值呢？有两个原因：

1. 服务器可能会没有能力处理传输读／写包（NFS V2 是 8KB，NFS V3 是 32KB）所带来的数据容量和速度。一个例子就是如果 NFS 客户机使用一台 PC 作为 NFS 服务器。这台 PC 将很可能只有有限的内存可用于缓冲大的包。
2. 如果读／写尺寸被减小了，随之带来的就是由调用产生的 IP 片断（IP fragment）数量的减少。如果您正在使用的是一个有损网络，要完成一次同样的调用／应答对，只用两个包交互比必须分用七个包交互成功的概率更大。同 样的，如果你在复合网络上发送 NFS 包，而这些网络本身又有不同的性能特征，此时还要求所有的包片断在小于 IP 片断超时值的时间内到达是不太现实的。

减小 rsize 和 wsize 可以在一个比较拥塞的网络上通过向每个 NFS 请求发送较短的包列，从而提高 NFS 性能。但是带来一个副作用，就是需要更多的包在网络上发送数据，增加了网络的通信量，同时在服务器和客户机上都增加了 CPU 的开销。

如果您的 NFS 文件系统是通过一个高速网络挂载的，如 SP Switch，则较大的读／写包能提高 NFS 文件系统的性能。在 NFS V3中，rsize 和 wsize 可以设置最大至 65536，缺省值是 32768。 在 NFS V2 中，rsize 和 rsize 最大可以达到 8192，同时这也是缺省值。

提高连续 I/O 吞吐量

在 AIX 5.1 及更新的系统中，您可以通过一种叫延迟释放（release-behind）的机制来提高对位于 NFS 导出文件系统上的大文件的连续 I/O 操作的性能。

更多有关延迟释放的信息，请参见文件系统的监视和调优。

提高客户机大文件 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 支持

如果您不使用在导出文件系统中支持的 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 守护进程都有为应答分配的自己的地址空间。因此，包被客户机丢弃是很罕见的。

通常情况下，包要么是被服务器丢弃，要么是在网络上被丢弃。

包被服务器丢弃

服务器在繁重的负载下将会丢弃包，存在两种情况：

1. 适配器驱动程序（Adapter Driver）

   当 NFS 服务器在对很多请求进行响应时，有时会从接口驱动程序输出队列中溢出。您可以使用 netstat -i 命令来观察所列出的统计信息。检查标记为 Oerrs 的那列，可以看到一些值。每一个 Oerrs 就是一个被丢弃的包。这可以方便地来调优，就是把出问题的那个设备的驱动程序传输队列长度增加。在配置可调队列长度时的思路就是：尽量不要使传输队列过 长，因为如果队列过长的话在处理队列时就会有一定的延迟。但是因为 NFS 为调用维护了相同的端口号和 XID，第二次的调用可以用第一次调用的响应来满足。另外，队列处理延迟比在丢包的情形下由 NFS 引起的 UDP 重发延迟要小得多。

2. 套接字缓冲区

   服务器丢包的第二个常见的地方是 UDP 套接字缓冲区。被丢弃的包在这里由 UDP 层来计数，使用 netstat -p udp 命令可以显示相关的统计信息。其中标记为 UDP: 的就是套接字缓冲区溢出 信息。

   通常情况下，仅当服务器有很多 NFS 写流量时 NFS 包才在套接字缓冲区中被丢弃。NFS 服务器使用一个与 NFS 2049 端口捆绑的 UDP 套接字，所有的输入数据都在这个 UDP 端口被缓冲。这个缓冲区的缺省大小是 60,000 字节。您可以做一个简单的除法：缓冲区大小除以单个写包（write packet）的大小，每个 NFS 写包的缺省大小是 8192 字节，很显然对于缺省大小的缓冲区只要有八个同时到达的写包就已经溢出了。仅仅是两个 NFS 客户机（缺省配置下）就会出现溢出。

   这种情况中，套接字上要么是有大容量的流量，要么就是有高突发性的流量。

   • 如果是高容量的流量，混合有写流量和其他非写的 NFS 流量，这时 nfsd 守护进程可能会跟不上那个容量而来不及将数据从套接字上取走。需要重新唤醒专门的 nfsd 守护进程来为各类的 NFS 调用服务。
   • 在遇到高突发性的流量时，已经存在的 nfsd 守护进程数应该是足够了，但由于流量是突发性的，因此在很短的瞬间内有很多包到达，以至于套接字还没有被唤醒包就已经溢出了。

   这两种情况的解决方法是不同的。

   • 在高容量情况下，只增加系统上运行的 nfsd 守护进程数就足够了。因为增加 nfsd 守护进程数并不会为机器带来显著的负面影响，因此可以先试着用一下这个解决方案。另外，请参见需要多少 biod 和 nfsd 守护进程？
   • 在高突发性流量的情况下，唯一的解决方案就是加大套接字，希望能以合理的大小为 nfsd 守护进程提供更多的时间来处理突发的流量。为这种套接字分配的专用内存不会被用于其他用途，所以需要注意的是：利用增大套接字的方法消除套接字缓冲区溢出 以达到调优的目标，这将使已分配的内存在大部分时间内被占用。一个谨慎的管理员会观察套接字缓冲区溢出的统计信息，将其与性能问题联系起来，并决定采用多 大的套接字缓冲区。有关怎样操控 NFS 套接字缓冲区的详细情况请参见增加 NFS 套接字缓冲区的大小。

您可能还会遇到以下情况：当服务器已被调优且既没有在套接字缓冲区上丢包也没有在适配器驱动程序上的 Oerrs 错误信息，但是客户机仍然在经历超时和重发。这里再次分为了两种情形。如果服务器负载繁重，可能服务器刚刚在超负载运行而现在 nfsd 守护进程在执行日志回写（backlog）工作，导致响应时间超过了客户机上设置的缺省超时值。请参见 NFS 调优核对清单 获取提示以便确认问题是否在此。另一种可能性，如果服务器是空闲的，那么包就是在网络上被丢弃的。

包在网络上被丢弃

如果服务器上既没有套接字溢出，也没有 Oerrs 错误信息，而客户机又有很多超时和重发且服务器已知是空闲的，则包很可能是在网络上被丢弃的。牵涉到网络的问题意味着什么呢？意味着很多传播媒介和网络设备，诸如路由器、网桥、集线器和所有那些为使包能在客户机和服务器间实现传输的设备。

当服务器没有超负载且没有丢包，但 NFS 性能差的时候，都可以认为包是在网络上被丢弃的。再努力一下就可以进一步证明这一点并且发现网络究竟是怎样把包给丢弃了。最简便的方法很大程度上取决于物理上的邻近性和可用的资源。

有时服务器和客户机物理上十分接近，使得直接连接非常的容易，而如果要穿越较大的网段就可能引发问题。很显然，如果把两台机器直接相连可以解决原先 的问题的话，那么就可以排除问题是由于机器本身原因造成的了。可是在常见的情况下，直接连接又不太可能，因此问题还是必须在适当的位置才能被捕获。

调优 NFS 文件属性高速缓存

NFS 在每个客户机系统上为最近被访问过的目录和文件维护一个高速缓存。在 /etc/filesystems 文件中有五个参数可设置，用来控制某个指定条目在高速缓存中要保留多久。这些参数如下：

actimeo

在文件和目录条目被更新后，要在文件属性高速缓存中保留的绝对时间。如果被指定，则该值会覆盖 * min 和 * max 的值，事实上把它们都设成了 actimeo 的值。

acregmin

在文件条目被更新后，保留的最短时间。缺省值是 3 秒。

acregmax

在文件条目被更新后，保留的最长时间。缺省值是 60 秒。

acdirmin

在目录条目被更新后，保留的最短时间。缺省值是 30 秒。

acdirmax

在目录条目被更新后，保留的最长时间。缺省值是 60 秒。

每次文件或目录被更新后，从高速缓存中移除至少要等 acregmin 或 acdirmin 秒。如果是第二次或后续的更新，条目最多被保留的时间至少等于最近两次更新之间的间隔时间，但是不会超过 acregmax 或 acdirmax 秒。

调优使 NFS 数据缓冲最大化

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）。

高速缓存文件系统（CacheFS）

高速文件缓存系统可以被用来改善远程文件系统的性能，或提高慢速设备如 CD-ROM 的性能。当一个文件系统被高速缓存以后，从远程文件系统或 CD-ROM 中读取的数据被存储到本地系统的高速缓存中，因此当需要再次读取已访问过的数据时就避免了对网络和 NFS 服务器的使用。CacheFS 被设计为一个分层的文件系统，这说明 CacheFS 提供了将一个文件系统（NFS 文件系统，又称为后台文件系统）缓存到另一文件系统（您的本地文件系统，又称为前台文件系统）上的功能，如下图所示：

请注意在 AIX 4.3 中，只有 NFS V2 和 NFS V3 支持被作为后台文件系统，且只有 JFS 支持被作为前台文件系统。

CacheFS 工作流程如下：

1. 在客户机系统上创建一个 CacheFS 文件系统后，系统管理员指定需要挂载入高速缓存中的那个文件系统。
2. 当某个客户机上的用户试图访问后台文件系统中的部分文件时，那些文件会被放入高速缓存。高速缓存并不需要被填充直到有用户请求要对一个或多个文件 进行访问。因此，访问文件的初始请求的速度将是普遍的 NFS 速度（通过网络），但是后续的对同一文件的访问速度将是本地的 JFS 速度。
3. 为了确保高速缓存内的目录和文件始终保持最新，CacheFS 周期性地检查高速缓存中文件的一致性。这是通过比较当前的修改时间和先前的修改时间来实现的。
4. 如果两个修改时间不同，相关目录或文件的所有数据和属性被清除出高速缓存，新的数据和属性从后台文件系统中取回。

适合用 CacheFS 的一个例子是在 CAD 环境中，其中制图组件的主复本（master-copy）可以保留在服务器上，缓存复本（cached-copy）当使用时存到客户机工作站上。

CacheFS 不允许读写大于或等于 2 GB 的文件。

CacheFS 的益处

因为 NFS 数据一旦从服务器读入就被缓存在本地磁盘上，所以与以前还要通过网络再次获取数据相比，NFS 文件系统的读请求可以被更快的满足。根据内存大小以及客户机的使用状况，仅有一小部分的数据可以在内存上存取，所以在磁盘上高速缓存数据的一个益处就是能 应用于更多的数据（包括那些不能被保存在内里的数据）。另一个益处是在系统关机后磁盘高速缓存中的数据也能被保留，而缓存于内存中的数据在重新启动后只能 再次从服务器上取回了。

其他的潜在 NFS 瓶颈包括：慢速或繁忙的网络和服务于多个 NFS 客户机的弱性能服务器。因此，从客户机系统对服务器的访问就可能很慢。CacheFS 并不能避免您通过网络从服务器上第一次读取数据，但是可以为您避免以后再次通过网络读取相同的数据。

如果更多的读请求可以在客户机上的本地磁盘中就被满足，则对服务器的 NFS 访问数量将势必会减少。这就意味着服务器将有能力为更多的客户机提供服务，如此一来，客户机／服务器比率（client per server ratio）就会上升。

网络上更少的读请求将减轻网络的负载，因此可以使很繁忙的网络释放一些资源出来或腾出空间用以传输其他的数据。

并不是所有的应用程序都能从 CacheFS 获益的。因为 CacheFS 仅能提高读速度性能，因此主要是那些对同一批数据有反复读请求的应用程序才能从 CacheFS 获益。庞大的 CAD 应用程序无疑能从 CacheFS 中获益，因为经常有很大的模型需要被载入用来运算。

性能测试显示从 CacheFS 文件系统上执行连续的读操作要比从 NFS 服务器的内存或磁盘上读快了 2.4 到 3.4 倍。

CacheFS 不执行什么

CacheFS 不会提高 NFS 文件系统的写操作性能。但是当挂载 CacheFS 时，在 mount 命令的 -o 选项中为您提供了两个写操作选项。它们会影响后续对数据读操作的性能。写操作选项如下：

write-around

write-around 模式（缺省）与 NFS 处理写操作的方式是一样的：写操作写入后台文件系统，被写的文件从高速缓存中被清除出去。这意味着 write-around 使高速缓存无效，写操作执行后新数据必须从服务器取回。

non-shared

当您确信不会有人往高速缓存文件系统内写数据时，可以采用 non-shared 模式。在此模式下，所有的写操作既写入前台文件系统又写入后台文件系统，并且文件仍然留在高速缓存。这就意味着以后的读访问可以到高速缓存中来执行，而不需要去访问服务器。

有一些小的读操作可能总是保留在内存中（根据您对内存的使用状况），此时即使将数据缓存在磁盘上也不会带来什么益处了。缓存随机读操作所读的不同数据块是没有意义的，除非您要对同一数据反复地访问。

初始的读请求还是必须发到服务器上去，因为只有当某个用户对后台文件系统上的部分文件进行过访问后，那些文件才会出现在高速缓存中。对于初始的读请求，您将感受到的是普遍的 NFS 速度。只有对同一数据的后续访问您才会感受到本地 JFS 访问的性能。

对于缓存数据的一致性仅仅是隔一段时间才检查一次。因此缓存经常被修改的数据是危险的。CacheFS 应该仅仅 被用于只读（read-only）数据和可改写只读（read-mostly）数据。

NFS V2 和 NFS V3 在高速缓存文件系统上的写操作性能是不同的。性能测试显示：

• 对于在 NFS V2 上的一个新文件进行连续的写操作，写入 CacheFS 挂载点（mount point）比直接写入挂载点要慢百分之二十五。
• 同样的情形，对于在 NFS V3 上的一个新文件进行连续的写操作，写入 CacheFS 挂载点比直接写入挂载点要慢六倍。

配置 CacheFS

CacheFS 并不是缺省被实现的，也不是在创建 NFS 文件系统后就启动的。

为了在 AIX 4.3.1 上获得增强的 CacheFS 写性能请确认安装：文件集级别（fileset level）4.3.1.1。

系统管理员必须显式地指定哪个文件系统将被挂载到高速缓存中，如下：

1. 使用 cfsadmin 命令创建本地高速缓存文件系统：

   # cfsadmin -c -o 参数 高速缓存目录

   上面的参数 特指资源参数，高速缓存目录 是指将高速缓存创建到那个目录的目录名。

2. 将后台文件系统挂载到高速缓存中：

   # mount -V cachefs -o backfstype=nfs,cachedir=/ 高速缓存目录 remhost:/远程目录 本地挂载点

   上面的远程目录 指数据所在的远程主机和文件系统名，本地挂载点 指远程文件系统应该在客户机上的哪个挂载点挂载。

3. 另外，您还可以使用 SMIT 命令（用 smitty cachefs 快捷路径）来管理 CacheFS。

一些参数可以在 CacheFS 创建时被设置，如下：

maxblocks

设置在前台文件系统内 CacheFS 被允许申请的最大块数。缺省值 =90%。

minblocks

设置在前台文件系统内 CacheFS 被允许申请的最小块数。缺省值 =0%。

threshblocks

设置一个块数，它指定了在 CacheFS 申请多于 minblocks 数目的块之前必须分配给客户机一端的 JFS 文件系统的块数。缺省值 =85%。

maxfiles

CacheFS 所能使用的最大文件数，以前台文件系统中的 i-node 总数的百分比形式表达。缺省值 =90%。

minfiles

CacheFS 始终被允许使用的最小文件数，以前台文件系统中的 i-node 总数的百分比形式表达。缺省值 =0%。

maxfilesize

CacheFS 允许缓存的最大的文件大小，单位：兆字节（MB）。缺省值 =3。

NFS 的 RPC 调优

: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 的性能

NFS 使用 UDP 或 TCP 来执行网络 I/O。请确保您已经应用了在调优 TCP 和 UDP 性能 和调优 mbuf 池的性能这两部分中所介绍的调优技术。 特别地，您应该：

• 确保 LAN 适配器发送接收队列长度都被设置为最大（请参见适配器发送与接收队列调优）。
• 增大套接字缓冲区大小的最大值（sb_max）为至少 131072 字节。如果 MTU 大小不到 4096，至少设置 sb_max 值为 262144。另外再设置 UDP 套接字缓冲大小（udp_sendspace 和 udp_recvspace）为 131072 字节。如果您使用的是 TCP，设置 tcp_sendspace 和 tcp_recvspace 为 131072 字节。
• 如果可能的话，增大局域网上的 MTU 大小。在一个 16 Mb 的令牌环网（Token-Ring）上，例如将 MTU 大小从缺省的 1492 字节改为 8500 字节就允许一整个 8KB 的 NFS 读或写请求一次性传输而不需要分段。它还更为有效地利用了 mbuf 地址空间，减小了超载的可能性。
• 一个可调的参数：nfs_tcp_socketsize 给出了在 NFS 连接下 TCP 端口的缺省窗口大小。无论有多少个挂载，在每个客户机和服务器之间仅有一个连接。不要将 nfs_tcp_socketsize 的值设置为小于 60,000 的值。大型的或繁忙的服务器应该有较大的值，直到命令 netstat -s -p tcp 的输出结果中 TCP NFS 流量显示没有丢包。
• 允许连入服务器的最大 TCP 连接数可以被新的选项 nfs_max_connections。所控制。缺省值是 0，表示没有限制。客户机会关闭空闲时间超过五分钟的 TCP 连接，当用户授权时连接可以被重新建立。服务器会关闭空闲时间超过六分钟的连接。
• 操作系统提供了一个用于关闭 NFS 所独有的 UDP 和校验（checksum）功能的选项。您可以使用 nfso 命令中的选项，称之为 udpchecksum。缺省值为 1（和校验功能有效）。当关闭这个功能后可以有一点点性能的提升，这是以增大数据损坏几率为代价的。

增加 NFS 套接字缓冲区的大小

在调优 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 服务器磁盘配置

承受高密度写操作的 NFS 服务器能从下面的方法中受益：将日志逻辑卷与数据卷分开而放在一个单独的物理卷上。更详细的信息请参见磁盘安装前的指南。

通常情况下，数据访问需要有很高的并行性。多个客户机或者一个客户机的多个进程对服务器上的单个文件系统的并发访问会导致某个特定设备上的磁盘 I/O 成为瓶颈影响吞吐量。您可以使用 iostat 命令来估计磁盘负载。

对于大型的 NFS 服务器，常规策略是将磁盘 I/O 需求平均且最大限度地分配给多个磁盘和磁盘适配器。这样就能获得更大的并发性以及有能力运行更多的 nfsd 守护进程。在一个磁盘 I/O 有良好分布的系统上，可能会调整到一个状态，在这一状态上 CPU 负载成为服务器性能的限制因素。

滥用 NFS 对性能的影响

很多对 NFS 的滥用发生于下面的情形中：由于人们没有意识到他们要访问的文件是在网络的另一端，要访问这些文件需要消耗昂贵的通信代价。有一些这样的例子，如下：

• 在一个系统上的应用程序对 NFS 已挂载的库存文件做随机的更新，以此来支持另一个实时的零售现金登记应用程序。
• 一个开发环境中，每个系统上的源代码目录都被 NFS 挂载到该环境中其余的系统上，以使开发人员可以登录到任意系统上去编辑和编译工作。这在事实上保证了所有的编译既可以从远程系统中获取源代码又可以将输出写回远程系统。
• 在一个系统上运行 ld 命令来传输在 NFS 已挂载目录里的 .o 文件到同一目录里的 a.out 文件。
• 应用程序发出的写操作没有页面对齐（page-aligned）（例如 10KB）。写操作的大小小于 4 KB 总是引起页面调进（pagein）且在 NFS 下这个页面调进会进入网络。

可能有人会说这些是对 NFS 所提供的透明性的正确使用。也许的确如此，但是这些使用方法通用同样消耗了处理器时间、局域网带宽并延长了响应时间。当一个系统配置将 NFS 访问作为标准操作模式的一部分时，设计者应该在迎来技术或商务上的优势的同时，做好准备来抵御由此带来的资源过度消耗。

• 将所有的数据或源代码放到一个服务器上，而不是放到单独的一个工作站上，改善了源代码的控制并简化了集中性的备份。
• 一些不同的系统要访问相同的数据，这时使用一个专用的服务器比一个或多个担任客户机服务器双重角色的系统来得更有效率。

另一种不应该在 NFS 文件系统上运行的应用程序类型是那些每秒钟调用上百次 lockf() 或 flock() 的应用程序。在 NFS 文件系统上，所有的 lockf() 或 flock() 调用（和其他锁定调用）都必须通过 rpc.lockd 守护进程。这会严重降低系统性能，因为 lockd 守护进程可能无法在一秒钟内处理上千个锁定请求。

无论客户机和服务器的性能容量再怎么大，所有涉及到 NFS 文件锁定的操作会导致让人无法容忍的慢速。这在技术上可以用很多原因来解释，但所有的原因都基于一个事实，那就是如果一个文件被锁定，势必要花更多的开销 用于在读写时对文件的同步进行处理。这意味着客户机上不能缓存有任何的文件数据，包括文件属性。所有的文件操作变为完全同步模式而没有了缓冲。如果在 NFS 上运行的一个正在进行网络文件锁定的应用程序显示出很差的性能，甚至比运行在同样的客户机／服务器对上的其他应用程序性能还差，这是令人难以相信的。

NFS 调优核对清单

以下是一张核对清单，您可以顺着它一步步对 NFS 进行调优：

1. 查看您的服务器是否超负载运行。

   常规的方法是减慢客户机速度观察是否会增加服务器的性能。以下方法可以各自单独使用：

   • 在挂载时尝试仅使用一个 biod 守护进程。

     在受影响的客户机上尝试仅使用一个 biod 守护进程。如果性能改善了，则可知是在网络或服务器上超载。运行 stopsrc -s biod 命令以停止所有的 SRC biod 守护进程。会留下一个内核进程 biod ，有了它您的系统还能够继续运行。观察在仅有一个 biod 进程的情况下，运行速度是否快些了。如果没有效果，则重新启动 biod 守护进程，请用 startsrc -s biod 命令。如果运行得快些了，请尝试着去判断当所有守护进程运行时包是在哪里被丢弃的。网络、网络设备、慢速服务器、超载服务器或没有很好调优的服务器都可能引发这个问题。

   • 尝试减小读／写大小，并观察速度是否加快。
   • 如果您使用的是 UDP，尝试用一下 TCP 挂载来替换。
2. 检查 Oerrs。

   这是影响 NFS 服务器的几乎是最普遍的从属于配置的错误。

   如果存在任何的 Oerrs ，为网络设备增大发送队列长度。这个操作可以在机器运行时进行，但是在修改（rmdev -l）。前接口必须被分离。您无法在一个无磁盘机器上关闭接口，而且您也没有特权当别的工作仍在进行时关闭接口。这种情况下，您可以使用 chdev 命令将修改保存在 ODM 中，这样的话在下一次启动后就能生效了。第一次时将当前的队列长度值加倍，重复这个过程（以后每次加 30）直到没有 Oerrs 报告为止。在 SP2 系统上，NFS 被配置为要穿越高速交换机，当发生了一个交换机错误或交换机暂时不可用时由于交换机的原因可能会产生 Oerrs。每一次试图发送到交换机的失败都被累加到 Oerr 上。这些错误数不能被消去。

3. 查找任何错误.

   任何一个很大的值都暗示了问题的存在。

4. 检查 NFS UDP/TCP 缓冲区溢出。

   当使用 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 守护进程启动后。加入的位置是十分重要的。

5. 检查 mbuf 的问题。

   观察是否有 mbufs 请求被拒绝或被延迟。如果是的话，增加网络可用 mbuf 的数量。更详细的关于调优以消除 mbuf 问题的信息，请参见调优 mbuf Pool 池的性能。

6. 检查很小的网间包延迟。

   很少有例子是由此引起的机器问题。如果在服务器和客户机之间有路由器或其他硬件，则您可以查阅它们的文档，看一下网间包延迟是否可以配置。如果可以，则尝试加大延迟。

7. 检查传播媒介是否匹配。

   当包在两个速度差异很大的传播媒介中传送时，路由器可能会将由高速网发来的包丢弃，并试图从慢速网上抓取包。特别地，一个路由器试图从 FDDI 光纤网上的服务器取包并将这些包发送到位于以太网上的客户机。 向以太网发送包的速度显然不能跟上 FDDI 的速度。唯一的解决方案是尝试去减少客户机的请求量、使用更小的读／写大小和限制可用于单个文件系统的 biod 守护进程。

8. 检查 MTU 不匹配。

   运行 netstat -i 命令并检查客户机和服务器上的 MTU。如果它们不同，则试着将它们改成同一个数看问题能否消除。另外要注意机器间的慢速或广域网、路由器或网桥，这些都可能在不同网段中传输时进一步分段。试着确定源与目的之间的最小 MTU，在 NFS mount 命令中修改 rsize/wsize 为某个小于 MTU 最小公分母的数。

9. 检查路由问题。

   使用 traceroute 命令来查看无法预料的路由转发或延迟。

10. 检查错误日志。

    运行 errpt 命令来查看网络设备或网络传输媒介的问题报告。还要寻找任何影响在导出文件系统上的 NFS 服务器性能的磁盘错误。