首先，很抱歉发布了一个显而易见的学习问题。我知道这是一个坏习惯，但我希望我仍然能在这里得到帮助，因为我做了很多研究，却找不到任何答案。
这设想情况是这样的：一个 NFS 客户端在 NFS 服务器上写入一个 50GB 的单一文件。在以平均 125 MByte/s 的速度写入 4GB 后，速度下降到 12MByte/s。
问题：您如何解释呢？
这给定回答问题是：写入 4GB 后，服务器不响应 COMMIT，而客户端定期发送 COMMIT，直到服务器响应，因为客户端想要清空其缓存。在此期间，数据速率下降到最慢元素的水平。
我所能找到的有关 COMMIT 过程的解释如下：
客户端写入数据，当数据传输到服务器时，客户端发送 COMMIT。服务器将数据写入稳定存储并使用 verf-Cookie 响应 COMMIT。如果 cookie 与客户端 cookie 相同，则客户端可以清空其缓存。
以下是我的问题：如果服务器没有通过发送 verf-cookie 来响应 COMMIT-Procedure，那么客户端是否会定期发送 COMMIT 并且数据速率会大幅下降？如果是，数据速率会下降到什么水平。我无法从答案中得出数据速率会下降到什么水平的结论。
答案1
我认为发生了以下情况：
客户端发送的数据写入服务器端的 FS 缓存。一旦发送 COMMIT 请求，这些数据就会开始刷新到持久存储 (DISK)。根据服务器的磁盘性能，这可能需要一些时间。假设磁盘性能为 300MB/s。刷新 4GB 需要 13 秒。如果此时间长于 NFS 超时，则客户端可能会发送另一个 COMMIT 请求，假设第一个请求丢失。COMMIT/WRITE 验证器用于确保服务器不会在这些操作之间重新启动。
在这种情况下，您可以执行以下操作：
- 通过指定增加客户端上的 NFS 超时时间o=mount 选项。虽然这只会使固定重试 COMMIT。
- 告诉服务器尽早开始刷新数据并避免日志延迟。
使用
sysctl -w vm.dirty_background_ratio=0
sysctl -w vm.dirty_ratio=0
sysctl -w vm.dirty_background_bytes=67108864
sysctl -w vm.dirty_bytes=536870912
应该根据服务器 IO 性能和网络吞吐量来调整大小。
控制内核何时开始将数据刷新到服务器磁盘并发送到客户端的服务器。
注意：此选项是全局的，将影响所有文件系统。