昨天有朋友问了一个问题。他通过NFS挂载了一个分布式文件系统，发现这个文件系统的df经常挂死。他查看了系统，发现内存使用率非常高，大部分物理内存都被缓存占用了。他想分析缓存中有哪些数据，并通过这个分析来确认高缓存使用率和NFS挂起之间是否有关系。当时我的建议是不要直接定位到OS内存上的问题。如果系统没有严重的SWAP，即使物理内存使用率达到98%也无所谓。其实使用NFS文件系统，客户端挂死或者df命令挂死的情况并不少见。这些年遇到过很多次。我遇到的NFS挂死问题的原因也很复杂，但大多与NFS的bug、网络问题、系统资源消耗过大、IO负载过大有关。一般来说，NFS客户端访问NFS文件挂掉有3种可能。一是客户端有问题，二是服务器有问题，三是客户端和服务器都有问题。似乎这个总结有点过于笼统和投机取巧，但是穷举法才是我们分析未知问题最重要的方法。如果我们不能穷举所有的可能性，那么我们在诊断分析的时候就可能无法定位到问题所在。在我多年的经验中，很多当时被认为是灵异现象的问题，都是由于我们缺乏先验知识，无法穷尽地找出真正的故障路径。上面的思维导图是我这些年遇到的一些NFSHANG的情况，遇到最多的都是和网络有关的。从NFSV3/V4版本开始，由于NFS或OS自身BUG导致的问题逐渐减少，而网络遇到的问题逐渐增多。特别是防火墙问题。这五六年来，我遇到的大型系统的NFS问题，大部分都和防火墙有关。随着企业对网络安全的要求越来越高，防火墙也在不断调整策略。有时某个策略会导致NFS网络数据包被防火墙过滤掉，导致NFS失效。五六年前，遇到过一个客户的NFS故障。只要我访问一个文件，NFS就会挂掉，访问其他文件时什么也没有。当时只好用网络抓包来跟踪。最后发现客户最近实行了过滤敏感词的政策。由于文件名包含敏感词，导致网络丢包。实际上，IP存储专网的建设非常重要。关键系统使用NFS时，必须使用IP存储私网。最好不要穿过防火墙。是的，NFS访问至少要经过两道防火墙。一旦网络安全管理员和存储管理员之间没有良好的沟通，防火墙引起的NFS问题将是不可避免的。另外，我们之前遇到的大部分NFS故障场景都没有使用IPSAN私网。NFS使用的网络与业务网络混合在一起。业务网络出现任何问题都会引起NFS文件系统的抖动，从而导致NFS服务的失败。稳定。是否存在Sockethang问题可以通过netstat命令查看是否有大量TCP连接处于CLOSEWAIT状态。如果是这种情况，很可能您遇到了套接字挂起。套接字挂起主要与高IO负载、缓慢的客户端或服务器操作系统响应或操作系统错误有关。也可能与TCPkeepalive参数设置有关。还有一点就是我们环境中使用的是NFS，可能还安装了数据库服务器、中间件服务器等。这些系统需要调整OS的网络参数，而这些参数的调整可能不适合NFS服务。一些常见的冲突参数如下：lnet.ipv4.tcp_keepalive_timelnet.ipv4.tcp_keepalive_intvllnet.ipv4.tcp_keepalive_probeslnet.ipv4.tcp_tw_recycle=0lnet.ipv4.tcp_tw_reuse=0lnet.ipv4.tcp_retries1=3tcp_keepalive_intvllnet.1=3tcp_keepalive_probeslnet.ipv4.tcp_tw_recycleHANG的问题分析往往不容易定位，原因很多。但是如果df命令hang是可以重现的，那么还是有办法分析的。最好的防御是使用strace来跟踪df命令的堆栈。通过查看挂起的位置更容易定位问题。最后要注意的是，messageslog一定要先分析，不管是客户端还是服务端的messageslog，都应该尽快查看。虽然很有可能我们看到的只是NFS命令超时等比较笼统的信息。
