我们有一个非常繁忙的服务器集群。 我们的16台应用程序服务器为每台机器上的本地SSD提供应用程序，但它们也处理图像，然后由我们的cdn提供服务。 正因为如此，我们有一对中央映像服务器，我们从我们的应用程序服务器上挂载。
我们最近遇到了一个需要我们closures的图像服务器的问题。 没有什么大不了的，我们的CDN仍然会服务于我们大部分的图像，所以没有人应该注意到停机时间。 不完全的..
应用程序服务器不是继续正常的操作，而是加载并崩溃，或者变得没有响应。 经过一天的挖掘，我们把问题缩小到了我们的nfs坐标上。 即使没有读取或写入NFS的装载，简单的事实，这是事端，导致Apache完全冻结。
没有什么大不了的，我们做了一些研究，发现我们将nfs卷作为硬盘挂载，我们需要切换到软mount，使用intr ，同时设置timeo值和retr值。 我们把重试次数设置为0，并设置timeo=1 （十分之一秒，所以我认为1是最低的）。 通过这些设置，我们closures映像服务器以复制早期的崩溃，并等待发生的事情。
结果是好的，但只是整个系统没有崩溃，但服务，因为如此缓慢，它可能已经下降。 看来，即使在十分之一秒的时间内，nfs挂载时间也太长了，所以我们最终在负载平衡器上积累了大量的连接，也许是1/10的容量。
为了validation我的结果，我从16个应用服务器中的4个卸载了nfs mount，并且向这4个服务器请求级别是完全正常的。
那么，有没有办法为nfs mount设置一个较低的超时时间，或者在发生错误时卸载驱动器，并且在down服务器恢复联机后自动重新挂载？ 或者，有没有另一种解决scheme，我不能为我们的系统增加一些复杂性？
我要做的第一件事情是将重新设置选项设置为1（或0，但我不知道这是否会按预期工作）。 这应该会缩短实际超时的时间