如何修复 NFS Server Not Responding 或服务器的 NFS 失败问题（转）

问题描述

NFS Server Not Responding ...
vmunix: NFS write failed for server ... 您是否曾经看见过这样的错误消息，是否想知道这是什么意思，或者如何修复这个问题?

解决方法

上面是同一个基本消息的两个版本，但是它们都具有相同的根本原因。

第一个示例是用于 hard mount (默认) 的，第二个是用于 soft mount 的。

在 soft 和 hard mount 之间存在一些差别。这些差别可在很多 NFS 参考资料中找到。

我要在下面显示每个这样的示例，然后解释可能的原因已经排除问题的方法。

要记住的很重要的一点内容是，这些消息的根本原因通常不是 NFS 本身。

根本原因通常是由于系统资源问题或者 I/O 瓶颈，以及 NFS 所依赖的很多子系统中的 任何一个。

下面的示例是通过按照 mount 命令中显示的形式 mount 文件系统、 开始文件复制，然后立即从服务器端口网络线缆创建的。有几种方法都可能生成这些 错误消息，因为有很多原因，但是这是一个演示此行为的非常简单的方法。

我对于每个方法都包括了屏幕输出、syslog.log 条目和 dmesg 输出。

此文档将随着新信息和示例的加入而有所更改。如果您对此有什么已经或者建议， 请使用此页下面的链接发送给我。

，，，，，，

# mount charger:/tmp /nfs_mount

# cp /stand/vmunix /nfs_mount
NFS server charger not responding still trying
NFS server charger not responding still trying
NFS server charger not responding still trying
NFS server charger not responding still trying
NFS server charger not responding still trying
NFS server charger ok

Mar 20 09:15:05 hpnec04 vmunix: NFS server charger
not responding still trying
Mar 20 09:21:47 hpnec04 vmunix: NFS server charger ok

# dmesg | grep NFS
NFS server charger not responding still trying
NFS server charger ok

，，，，，，

# mount -o soft charger:/tmp /nfs_mount
# cp /stand/vmunix /nfs_mount
cp: cannot close /nfs_mount/vmunix: Connection timed out

Mar 20 09:32:58 hpnec04 vmunix: NFS write failed for
server charger: RPC: Timed out
Mar 20 09:33:18 hpabc04 vmunix: NFS commit failed for 
server charger: RPC: Timed out
Mar 20 09:32:58 hpabc04 vmunix: NFS write failed for server 
charger: RPC:Timed out
Mar 20 09:34:15 hpabc04  above message repeats 3 times

# dmesg | grep NFS
NFS write failed for server charger: RPC: Timed out
NFS write failed for server charger: RPC: Timed out
NFS write failed for server charger: RPC: Timed out
NFS write failed for server charger: RPC: Timed out
NFS commit failed for server charger: RPC: Timed out

，，，，，，

那么它们到底是什么意思呢?
它们的意思从字面可以看出来。
简单来说，客户机对服务器进行了一个 NFS 调用，但是没有收到及时的响应。
虽然超时会根据 mount 选项而有所变化，但是原因仍然是相同的，故障排除方法 也是相同的。有几个原因可能会导致客户机记录这些消息。
下面只是其中一部分: NFS 服务器已经关闭

• 脱离网络
• 服务器正在重新引导

NFS 服务器超载或者调整不正确

• CPU 利用率太高
• 内存使用率太高
• 磁盘 I/O 瓶颈
• 运行的 nfsd 不足
• 内存或 CPU 不足
• 其他系统资源瓶颈

拥塞的或者故障网络

• 过多冲突
• 故障交换机、路由器、集线器、线缆等...
• 进出服务器的数据包已被丢弃
• 部分数据包被丢弃
• 拓扑 "跨接" 问题 (FDDI-to-Ethernet)
• NIC 设置不正确 - 速度或者双工不匹配
• 客户机或者服务器上 IP 地址重复
• 客户机或者服务器上 MAC 地址重复

客户机或者服务器配置

• 路由表配置不正确
• LAN 设置 (双工/速度)
• LAN 拓扑差别
• Mount 选项

您可能可以看出，上面的很多内容都在某种程度上存在较差并且可能涉及到其他 领域。对，是这样。真正重要的是要理解大致的情形，以及如何快速缩小关注的 内容。

，，，，，，

我建议在开始排除这些消息之前，首先询问一些问题。

我们是否需要进行故障排除?

如果我们知道这些消息是什么意思，导致这些消息的原因是什么， 那么是否真的需要进一步研究呢? 如果客户只是看到其中一些消息， 那么可能不值得进行故障排除，因为进行故障排除通常意味着 要再现这些消息，或者至少要等待它们再次发生。

此时还发生了什么别的情况?

如果我们知道此时正在进行网络备份，或者此时网络的某个设备 正在出现问题，则就可能能够解释原因。请记住，对于已经发生问题的 客户机和服务器不必进行备份。备份可能会消耗很多的网络带宽， 而这些带宽正式其中一个或两个系统在使用的带宽。

这些消息是否会在每天的相同时间发生?

再强调一次，我们应该查看明显的内容。每天的这个时间发生了什么 事情? 是否是备份? 是否都是在每天中午午饭后每个人都坐下开始 工作并开始着手它们的项目时发生? 这些软件构建是否都在相同时间 发生? 是否能够在此时运行的 cron 中找到一些内容，它是不是一个 影响因素?

有很多这样的消息还是只是一点?

如果这些错误消息只是发生了一两次，那么可能不必进行 故障排除，只是解释一下原因以便客户了解在将来发生 这些错误消息时应该查看哪些内容就可以啦。如果他们 一直看到这些错误消息，找到了他们无法解释的原因， 那么就应该进行进一步研究了。

是不是很多客户机对于同一个服务器会收到相同的错误消息?

通过查看相同的现象可能有助于缩小搜索的范围。如果只是 一些客户机有问题，那么它们有哪些共同点呢? 路由器?
交换机还是其他什么设备?

服务器是不是只是对于一个文件系统没有响应?

如果服务器对除了一个文件系统之外的所有文件系统均能及时 响应，则需要查看什么原因导致这个文件系统的特殊性。
是不是磁盘 I/O 问题? 可能是 SCSI 问题? 可能是该磁盘上 运行的一些较大作业的问题?

，，，，，，

现在，如果您已经到了这个程度，但是仍然无法解释这些消息，则需要 进行进一步的研究。
首先最好检查网络的整体运行性能，以及服务器的性能。
下面列出的几个命令提供了大量的信息。在本文中我不能详细解释 每个命令或者字段输出的意思了。目前可在 K-Mine 或者某些 其他 NFS 参考资料中获取该信息。某些命令还是标准的联网命令。
有关所有命令的详细信息，请参阅该命令的 Man Page。此故障排除 文档旨在真正帮助您缩小搜索原因的范围。

此部分非常冗长， 但是如果您已经收集了这些信息，则会发现很多问题。

ping

ping 这个服务器 - 它是否会在网络上发出响应?

# ping charger
PING charger.rose.hp.com: 64 byte packets
64 bytes from 10.43.32.34: icmp_seq=0. time=1. ms
64 bytes from 10.43.32.34: icmp_seq=1. time=1. ms
64 bytes from 10.43.32.34: icmp_seq=3. time=1. ms
64 bytes from 10.43.32.34: icmp_seq=4. time=1. ms
64 bytes from 10.43.32.34: icmp_seq=9. time=1. ms
64 bytes from 10.43.32.34: icmp_seq=10. time=1. ms

----charger.rose.hp.com PING Statistics----
11 packets transmitted, 6 packets received, 45% packet loss
round-trip (ms) min/avg/max = 1/1/1

在上面的示例中，您可以看到某些 ping 数据包未被确认。
这就表示出现了网络问题。这当然是出现 NFS 问题的原因。

traceroute

traceroute 到该服务器

# /usr/contrib./bin/traceroute
mrzoggs.mayfield.hp.com
traceroute to mrzoggs.mayfield.hp.com (10.37.42.7), 
30 hops max, 20 byte packets
1 r10fwd.rose.hp.com (10.43.35.36) 1 ms 1 ms 1 ms
2 r3anx0.rose.hp.com (10.96.72.20) 2 ms 1 ms 1 ms
3 halhgw3.cns.hp.com (10.93.248.1) 5 ms 5 ms 5 ms
4 phlhgw10.cns.hp.com (10.1.200.110) 4 ms 4 ms 4 ms
5 10.111.8.2 (10.111.8.2) 5 ms 5 ms 5 ms
6 mrzoggs.mayfield.hp.com (10.37.42.7) 5 ms 6 ms 5 ms

这个命令是作为一个正常性检查的很好工具。它可能会显示 某些数据包正在采用进出服务器的非预期路径，此时可能需要 考虑。

nfsstat -m (on the client)

# nfsstat -m
/nfs_mount from charger:/tmp (Addr 10.43.32.34)
Flags:
vers=3,proto=udp,auth=unix,soft,intr,link,symlink,devs,
rsize=8192,wsize=8192,ret
rans=5
Lookups: srtt= 10 ( 25ms), dev= 6 ( 30ms), cur= 4 ( 80ms)
Reads: srtt= 5 ( 12ms), dev= 5 ( 25ms), cur= 3 ( 60ms)
Writes: srtt= 51 (127ms), dev= 10 ( 50ms), cur= 11 (220ms)
All: srtt= 47 (117ms), dev= 12 ( 60ms), cur= 11 (220ms)

nfsstat -m" 显示了每个 mount 的 mount 选项以及一般的统计数据。 如果时间很长，如 1,000ms，则可能表示出现了网络问题或者其他系统资源瓶颈 - SCSI、CPU、内存。
要进一步排除这个问题，最好使用一个性能监视工具，如 Glance 或 MeasureWare。 您应该在收到 "NFS server nor responding" 消息时使用这些工具监视客户机和 服务器。

nfsstat -c (在客户机上)

此命令将显示所有 NFS mount 的客户机信息。您在客户机一端会看到一些超时。
此命令可能不会显示太多用于排除这些消息的有用信息，但是最好还是查看一些这些信息。
此命令会告知您这个客户机执行 NFS 的整体性能如何。

nfsstat -s (on server)

此命令会显示服务器一端的统计信息。请记住，nfsstat 会显示所有】
NFS 业务的 NFS 统计信息，而不只是您正在研究的客户机或者 mount。
另外，此命令可能不会显示太多用于排除这些消息的有用信息，但是最好还是查看一些这些信息。 此命令会告知您这个客户机执行 NFS 的整体性能如何。

netstat -s (on server)

# netstat -s | grep overflow
0 socket overflows

在此示例中，0 溢出表示有足够的 nfsd 来处理外来的 NFS 调用。
如果我们运行的 nfsd 太少的话，则此数字就会很大。此数字本身 有一些令人摸不到头脑。它是系统引导以来的累积计数。
没有办法来使得此值归零。例如，如果我们某一次执行次命令时 看到了 5,000 个 socket 溢出，那么就应该注意了。但是完全有可能 这 5000 个 Socket 溢出是在几天前的几分钟内发生的，从那以后根本 没有什么问题。如果您怀疑运行的 nfsd 的太少，则可以运行一个 脚本，以一个特定的间隔将 Socket 溢出的数量记录到一个文件。 下面是这样的一个脚本示例:

# cat so_script
#!/usr/bin/ksh
while true
do
date >> /tmp/socket_overflows.txt
netstat -s | grep overflow >> /tmp/socket_overflows.txt
sleep 5
done

此命令将创建类似下面的输出结果:

# tail -f /tmp/socket_overflows.txt
Tue Mar 20 12:18:51 PST 2001
        0 socket overflows
Tue Mar 20 12:18:57 PST 2001
        0 socket overflows
Tue Mar 20 12:19:02 PST 2001
        0 socket overflows
Tue Mar 20 12:19:07 PST 2001
        0 socket overflows
Tue Mar 20 12:19:13 PST 2001
        0 socket overflows
Tue Mar 20 12:19:18 PST 2001
        0 socket overflows

很重要的一点是要在发生问题时在服务器执行此操作。
另外，并非总是有必要因为一些 Socket 溢出而增加 nfsd 的数量。
您应该仔细考虑 NFS 服务器的整体调整，然后再进行任何更改。

您也可以使用 ndd (在 HP-UX 11.00 或更高版本上) 命令以获取 更加详细的信息，更加精确地了解 Socket 溢出来自何处。
有关使用 ndd 命令执行此操作的详细解释，请参阅 K-Mine 文章 KBRC00007731。

在服务器上进行性能测量

我想使用如 Glance、PerfView、MeasureWare 或 sar 这样的工具 来在出现问题期间监视服务器的性能。我在本页就不详细说明 这些工具了，因为在别的地方可以找到这些信息。您需要在出现 问题期间监视服务器上的下列内容:

• 磁盘 I/O
• 内存利用率
• CPU 利用率
• Swapping
• 网络性能

上面出现的任何问题都可能时导致因素，应该首先进行 修改然后再继续。

如果到目前为止任何内容均表现正常，则应该继续下一步 来记录问题的网络跟踪信息。网络跟踪可能非常消耗时间， 因此请确保您涉及到上面的所有基本内容以帮助节省时间。

在服务器和服务器上执行

如果我们仍然无法解释上面出现的超时问题，则必须进行网络跟踪。 您要在发生问题时同时在客户机和服务器上进行跟踪。
有一些情况下 nettl 不会只是跟踪客户机和服务器。如果您出现了 这种情况，我们则建议客户使用其他进行跟踪的方法， 如使用网络 sniffer。

有几种方法可用于进行跟踪。您可以针对 nettl 和 netfmt 执行 man 命令以获取详细信息，或者参阅 一些 nettl 网页。

我通常会在两个系统上使用下列命令来开始跟踪:

# nettl -tn pduin pduout -e all -tm
99999 -f /tmp/nfstrc

一旦运行了跟踪，您就需要监视 dmesg 或 syslog.log，看是否会出现其中一个错误消息。当您看到一个 (或者几个) 这样的错误消息， 则要按照如下所示停止跟踪:

# nettl -tf -e all

我认识到，有一些更好的方法来进行 nettl 跟踪，但是 本指南的意图不在于详细解释 nettl。请随便使用最适合您的方法。

一旦停止了跟踪之后，您就会拥有一个原始的跟踪文件，名称为 /tmp/nfstrc.TRC0，可能还有 /tmp/nfstrc.TRC1。nfstrc.TRC0 是最近的跟踪。

您现在需要对这些跟踪进行格式设置。为了筛选出 NFS 数据， 我使用了下面的筛选文件:

# cat /tmp/filter.nfs
formatter filter subsystem NS_LS_IP
filter rpcdirection call
filter rpcdirection reply

按照如下所示对原始跟踪文件进行格式设置:

# netfmt -c /tmp/filter -
Nnlf /tmp/nfstrc.TRC0 > /tmp/trace0.txt

现在您拥有了一个文件，其名称为 /tmp/trace0.txt。
如果您有一个 /tmp/nfstrc.TRC1 文件，则也可以对其进行格式设置， 更改输出文件的名称即可。

因为您已经对客户机和服务器进行了跟踪，所以您需要对 它们都进行格式设置。您还可以对每个系统的筛选文件进行细化， 以便只是显示这些客户机和服务器之间的 NFS 数据。为此， 您需要在每个系统上对筛选文件添加两行内容，在服务器上， 您需要向筛选文件添加客户机的 IP 地址，在客户机上， 您需要向筛选文件添加服务器的 IP 地址。

客户机上的示例筛选文件如下所示:

# cat /tmp/filter.nfs
filter ip_saddr 10.43.32.34
filter ip_daddr 10.43.32.34
formatter filter subsystem NS_LS_IP
filter rpcdirection call
filter rpcdirection reply

服务器的 IP 地址为 10.43.32.34。如果包括了客户机本身的 IP 地址，则所有内容都符合条件，最后结果为输出文件。
与之相似，在服务器上，要添加客户机的 IP 地址。

一旦您拥有了跟踪文本文件之后，可能就开始了最困难的任务 - 寻找超时。

我建议首先查看一下 syslog.log 中的时间戳，然后找出 nettl 跟踪中的时间戳。因为粒度不是相同的，所以您可能必须 在 nettl 跟踪中查找一些数据包以找出正确的时间戳。 它依情况而定。如果是 soft mount，则需要至少了解要 寻找的请求类型 - read、write、commit 等。

下面是我将范围不断缩小的步骤 :

1. 首先以客户机跟踪开始

2. 在 syslog.log 中找出时间戳

3. 在 nettl 跟踪中找出匹配的 NFS 调用

4. 记下调用的 Transaction ID (例如 - trans id: 0x3a5749c7)

5. 记下调用的确切时间

6. 在服务器经过格式设置的 nettl 跟踪中找出匹配的 Transaction ID

7. 找出服务器针对调用的响应 (同一个 transaction id)

8. 在客户机的 nettl 跟踪中找出响应 (同一个 transaction id)

客户机和服务器的时钟可能不是同步的，因此 时间可能有所不同，但是您可以相对比较这些时间。

1. 客户机发出调用是什么时间?

2. 服务器接收调用的时间是什么?

3. 服务器进行响应需要多长时间?

4. 客户机是什么时候收到的响应?

查看上面从步骤 B 到步骤 C 所需的时间。如果这个时间差是固定的， 则很可能是网络出现了问题，如冲突、拥塞、过载或者网络设备配置 不正确。这表示服务器收到了调用并立即进行了响应，但是到达 客户机的时间较长，或者在返回客户机的路径上被丢弃了。
这些既不能真正由客户机也不能真正由服务器来控制。
需要对网络进行进一步的研究。这个示例很好的说明了一个不受 NFS 控制的示例。

通常会出现这样的情况，客户机从来没有收到响应，或者调用 从来无法到达服务器。如果是这种情况，则说明出现了更严重的 网络问题，NFS 不是原因。客户可能需要对每个系统连接一个 网络 sniffer 来尝试进一步排除故障。我们是否存在一个故障 网络设备? 我们是否具有重复的 IP 地址或 MAC 地址?
上面的 nettl 示例实际上只是一些基本的信息，但是我想您现在 应该会认识到很多不同的因素都可能导致此问题。
我们只是刚刚触及皮毛。

还有一些情况，nettl 不能在这种情况下 运行。如果出现这种情况，则唯一的选择是让这个客户对客户机和 服务器连接一个网络 sniffer 然后继续跟踪问题。

我们希望这篇文章能够解释这些消息，如果需要，还可以帮助您 排除一些根本的原因。真心希望您对本文提出宝贵的意见和建议。

下面是 NFS 参考资料列表:

- Callaghan

ISBN 0-201-32570-5, Addison Wesley

- Stern

ISBN 0-937175-75-7, O'Reilly & Associates