RHEL 挂载挂起：nfs: server [...] not responding, still trying

Diagnostic Steps

排除常见问题的初始步骤

• 首先，确定问题的时间范围。事件的开头是 not responding, still trying 消息的时间戳，根据 timeo 和 retrans 值向后调整（请参阅有关 timeo 和 retrans 的 根源 部分）。

事件的末尾是您看到 nfs server: ... OK 消息的时间。

如果没有 OK 消息，则问题仍然存在(NFS 服务器仍没有响应)。

如果有多个 not responding 消息，可能会有多个时间范围，或您可能需要进一步调整。

例如：

# grep server.example.com /proc/mounts 
server.example.com:/export /mnt nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,minorversion=0,local_lock=none,addr=y.y.y.y 0 0
# grep "server.example.com" /var/log/messages
Sep 29 22:54:39 client kernel: nfs: server server.example.com  not responding, still trying
Sep 29 22:54:49 client kernel: nfs: server server.example.com OK

由于使用了默认挂载选项，因此问题在 not responding 消息前 180 秒开始。当看到 'OK' 消息时，问题结束：

Sep 29 22:51:39 - Problem BEGIN:  adjusted start time of the problem based on 'timeo' and 'retrans'
Sep 29 22:54:39 - 'not responding, still trying' seen
Sep 29 22:54:49 - Problem END: 'OK' seen

问题的时间范围现已确定。

• 在 NFS 服务器上，检查任何日志，以了解确定的时间范围内性能问题的迹象。对于非红帽 NFS 服务器，请联系您的 NFS 服务器厂商，并为其提供问题的时间范围，以进行调查。

• 在 NFS 客户端和 NFS 服务器上，检查网络接口和/或网络是否有问题。例如：

  • 在 ip -s link 和/或 ethtool 输出中查找丢弃的数据包。对于这样一种可能性，请参阅：系统由于 rx_fw_discards 而丢弃数据包
  • 也可使用 xsos 工具查找网络接口上的数据包丢失，请参阅：如何在 Red Hat Enterprise Linux 上安装 xsos 命令？
  • 检查 NFS 客户端、NFS 服务器上的 MTU 设置，以及从 NFS 客户端到 NFS 服务器的整个路径。所有系统必须配置相同的 MTU。
  • 通过在 RHEL 上运行 netstat -s 来查找系统外数据包丢失的证据。TcpExt 标题下的计数器，如 retransmits 或 congestion 可能表示外部数据包丢失。但请注意，这些是系统范围内的 TCP 计数器，其自系统引导以来已递增，因此错误可能与其他 TCP 连接有关，而不是 NFS 连接。
  • 如果使用绑定，且 NFS 传输是 TCP，请检查是否有不正确的绑定模式，如 TCP 流量，如 NFS、ISCSI、CIFS 等的最佳绑定模式是什么？

• 识别任何其它访问同一 NFS 服务器的 NFS 客户端，特别是任何相同的 NFS 客户端（挂载相同的导出、相同的挂载选项、相同的红帽版本等）。在同样的时间范围，是否有任何类似的 NFS 客户端遇到 not responding 消息？ 如果有其他 NFS 客户端，则这说明有 NFS 服务器问题，或在 NFS 客户端和 NFS 服务器之间有网络/连接性问题。

• 识别 NFS 客户端和 NFS 服务器之间的任何网络设备，如路由器、交换机或防火墙。如果可能的话，请检查事件发生时间范围内来自这些设备的任何日志或监控统计信息（例如：Cacti, rrdtool）。

使用数据包捕获进行故障排除

这些步骤的目标是将问题分为 3 个类别中的一个：

• NFS 客户端和 NFS 服务器之间的问题
• NFS 服务器上的问题
• NFS 客户端上的问题

当问题被隔离后，需要进行进一步的故障排除来解决这个问题，这超出了此解决方案的范围。

故障排除此问题的最直接的方法至少需要从 NFS 客户端和 NFS 服务器的角度捕获数据包。在某些场景，可以只在一端使用数据包捕获进行诊断，如 NFS 客户端，但强烈建议在两端进行。

备注：任何 tcpdump 捕获应仅包含涉及有问题的 NFS 服务器的数据包。 如果使用 tcpdump，您可以使用 'host' pcap-filter 并从 "not responding" 消息中提供 NFS 服务器名称或 IP 地址来实现这一点。 无法将数据包捕获只过滤到有问题的 NFS 服务器很可能导致根本原因分析的延迟。 例如：

# grep "not responding" /var/log/messages
Sep 29 22:54:39 client kernel: nfs: server server.example.com  not responding, still trying
# tcpdump -i eth0 -s 0 -w /tmp/tcpdump.pcap host server.example.com

使用 tcpdump 收集数据包捕获(红帽 NFS 客户端或服务器)

有关在任何红帽 NFS 服务器或 NFS 客户端上收集数据包捕获的通用步骤，请参阅 如何使用 tcpdump 捕获网络数据包？

对于在 RHEL NFS 客户端上使用 tcpdump 工具收集数据包捕获的简单方法，请使用以下解决方案中的 tcpdump-watch.sh 脚本：https://access.redhat.com/articles/4330981#intermittent。

脚本使用一个参数、NFS 服务器名称或 IP 地址，并监视 /var/log/messages 中是否有 nfs: server ... not responding, still trying 消息。当看到这个消息时，tcpdump 已停止。

请注意：tcpdump-watch.sh 脚本中的默认 tcpdump 参数可能适用于许多环境，但有些环境可能需要稍微更改一下。例如，如果存在大量 NFS READ 和 WRITE，在初始数据包捕获中，且/或者有大量 tcpdump 进程丢弃的数据包，则使用 "snaplen" 参数(-s 512)将捕获的数据包的大小减小到 ~512 字节。另外，如果数据包捕获收集了许多 NFS 客户端和 NFS 服务器之间的 NFS 流量，则您可能需要添加一个或多个 pcap-filters，如 port 2049 ，来只捕获到/来自 NFS 端口的流量。有关 pcap-filters 的详情，请查看手册页 man pcap-filter。

在 NFS 服务器上收集数据包捕获（非红帽 NFS 服务器）

有关从 NFS 服务器收集数据包捕获的官方步骤，请联系您的 NFS 服务器厂商，或使用端口镜像，从 NFS 服务器角度捕获流量。

• 对于 NetApp 过滤器，请联系 NetApp ，以获得有关您的过滤器和环境的官方建议。您可以使用 pktt 命令，如 如何在 NetApp 过滤器上捕获 NFS 操作的数据包跟踪？ 中所述。
• 对于 EMC Isilon 过滤器，请联系 EMC ，以获得有关您的过滤器和环境的官方建议。您可以使用 isi_netlogger 命令或 Web 界面，如 如何在 EMC Isilon filer 上捕获 NFS 操作的数据包跟踪？ 中所述。

数据包捕获的分析

使用初始步骤中计算的问题的时间范围，并使用 wireshark 或 tshark 检查数据包捕获文件。在运行 wireshark 或 TZ 时，请务必使用正确的 tshark shell 变量，以便数据包上的时间戳与问题的时间范围一致。有关 TZ 变量的更多信息，请参阅 NFS 数据包跟踪分析提示和技巧 中标题为 "数据包跟踪中的时间戳和匹配其它事件时间戳"部分。检查数据包捕获，以查看是否有网络问题的迹象，如重新传输/重复数据、TCP/IP 握手问题、NFS RPC 回复的延迟等。

有关在 NFS 客户端收集的 tcpdump 中可能看到的一些常见场景的示例，请参阅 NFS 客户端 tcpdump 分析：3 个常见的失败场景

使用 vmcore 进行故障排除

vmcore （通过导致内核 panic 而创建的内核内存副本）包括了在 vmcore 创建时的系统状态，通常并没有包含导致无响应事件的足够详细信息。因此，使用这个方法进行调查可能并不是必须的，但是如果 vmcore 是进行调查的唯一信息源，红帽工程师会分析 vmcore，并尝试为客户提供最佳信息。

如果认为在 RHEL 中有特定的 bug，则红帽可能会在以后请求来自 NFS 客户端或 NFS 服务器的 vmcore，但对于此类问题，vmcore 不是的初始的或常见的故障排除步骤。