Nginx 在 NFS 等网络文件系统上必须禁用 sendfile，因其内核不支持远程句柄直传，会退化为 read/write 导致性能骤降；应配置 sendfile off、aio on、directio 及优化挂载参数，并优先采用本地化或对象存储替代方案。
在跨存储挂载网络文件系统（如 NFS、CIFS、GlusterFS）时，Nginx 的 sendfile 不仅无法发挥零拷贝优势，反而会显著退化甚至失效——因为内核的 sendfile() 系统调用**不支持远程文件句柄直传**。NFSv3/v4 客户端在遇到 sendfile 请求时，多数会静默回退到用户态 read()+write() 路径，导致 CPU 升高、延迟飙升、QPS 断崖下降。
为什么 sendfile 在 NFS 上基本失效
根本原因在于：sendfile() 依赖底层文件系统提供有效的 file_operations.sendfile 接口，而主流 NFS 客户端（尤其是 Linux 内核 NFS client）未实现该接口的高效转发。实测表明：
- NFSv3 挂载下，
strace观察到大量read/write调用，几乎无sendfile系统调用 - NFSv4.1+ 支持
copy_file_range，但需服务端开启pnfs且客户端显式启用（Nginx 不调用该接口） - 即使挂载选项含
noac或actimeo=0，也无法恢复sendfile路径
必须关闭 sendfile 并切换为优化型用户态路径
面对 NFS 等网络存储，正确做法不是“调优 sendfile”，而是主动禁用它，并通过其他方式降低用户态拷贝开销：
-
强制关闭：
sendfile off;（放在http或location块中） -
启用异步 I/O 加速读取：
aio on;+directio 4m;（绕过 page cache，避免 NFS 缓存一致性问题） -
增大缓冲区减少 write() 次数：
output_buffers 2 128k;（合并小块写入，降低 syscall 频次） -
禁用干扰项：确保
gzip off;、sub_filter off;、etag off;，防止额外解析开销
挂载层协同优化（关键但常被忽略）
Nginx 层优化效果受限于 NFS 客户端行为，必须同步调整挂载参数：
-
使用 NFSv4.2（推荐）：支持
server-side copy和更稳定的属性缓存，比 NFSv3 平均降低 30% 延迟 -
挂载选项示例：
nfsvers=4.2,hard,intr,rsize=1048576,wsize=1048576,acregmin=10,acregmax=30,namlen=255 -
禁用 atime 更新：
noatime,nodiratime（减少元数据写入，对 NFS 尤其有效） - 避免 soft 挂载：soft 模式在超时时会直接报错，hard + intr 才能保障请求可中断、不卡死 worker
替代方案：静态资源尽量本地化或用对象存储
若业务允许，应从根本上规避 NFS 传输瓶颈：
-
边缘节点预热：将高频访问的静态资源（CSS/JS/图片）通过脚本或 CI/CD 同步至本地磁盘，Nginx
root指向本地路径，保留sendfile on; -
对接对象存储：用
ngx_http_proxy_module+proxy_cache代理 S3/MinIO，配合proxy_buffering on;和合理proxy_cache_valid，让热点文件落盘缓存 - CDN 回源分层：Nginx 作为 CDN 源站时，只承担回源压力，静态资源由 CDN 边缘节点直出，彻底绕过 NFS 传输
