我们有一个非常繁忙的服务器集群。我们的 16 个应用服务器通过每台机器上的本地 SSD 为我们的应用程序提供服务，但它们也处理图像，然后通过我们的 CDN 提供服务。因此，我们有几个中央图像服务器，我们从应用服务器通过 nfs 安装它们。
我们最近遇到了图像服务器的问题，我们不得不关闭它们。没什么大不了的，我们的 CDN 仍将提供我们的大多数图像，所以没有人会注意到停机时间。不完全是。
应用服务器非但没有继续正常运行，反而负载猛增、崩溃或无响应。经过一天的调查，我们将问题缩小到 nfs 挂载。尽管没有对 nfs 挂载进行读写，但它宕机这一简单事实就导致 apache 完全冻结。
没什么大不了的，我们做了一些研究，发现我们将 nfs 卷挂载为硬挂载，我们需要切换到软挂载，使用intr，并设置 timeo 值和 retr 值。我们将重试次数设置为 0，并设置timeo=1（以十分之一秒为单位，所以我相信 1 是我们能设置的最低值）。在完成这些设置后，我们关闭了图像服务器以复制之前的崩溃，并等着看会发生什么。
结果更好，但只是整个系统没有崩溃，但服务太慢了，可能已经停止了。看来，即使是十分之一秒，对于 nfs 挂载超时来说，这也太长了，所以我们最终在负载平衡器上积压了大量的连接，可能只有十分之一的容量。
为了验证我的结果，我从 16 台应用服务器中的 4 台卸载了 nfs 挂载，对这 4 台服务器的请求级别完全正常。
那么，有没有办法为 nfs 挂载设置较低的超时时间，或者在出现错误时卸载驱动器，并在停机服务器重新上线后自动重新挂载？或者，有没有我忽略的另一种解决方案，不会给我们的系统增加很多复杂性？
答案1
我要做的第一件事是将retrans选项设置为 1（或 0，但我不知道这是否会按预期工作）。这应该会缩短实际超时所需的时间