启用sendfile on可实现内核态零拷贝，需配套tcp_nopush on、tcp_nodelay off，并关闭gzip、etag等退化项，确保文件位于本地文件系统且无动态处理，才能真正降低CPU占用、提升QPS。
在高流量服务器上，sendfile 指令不是“锦上添花”，而是关键的性能杠杆——它能让 Nginx 在传输静态资源时大幅降低 CPU 占用、减少内存拷贝、提升吞吐量，尤其在并发请求多、文件体积大（如图片、视频、安装包）的场景下效果显著。
核心优化效果：CPU 和网络效率双降双升
传统 read/write 方式需经历“磁盘 → 内核缓冲区 → 用户空间内存 → socket 缓冲区 → 网卡”路径，涉及两次数据拷贝和多次上下文切换。启用 sendfile on 后，内核直接完成“磁盘 → socket 缓冲区”的搬运，带来三方面实际收益：
- CPU 使用率下降 20%–40%，压测中 1MB 文件 QPS 提升常达 1.5–2 倍
- 内存带宽压力明显减轻，避免用户态缓冲区分配与回收开销
- TCP 包更规整，配合
tcp_nopush on可减少小包数量，降低 ACK 风暴与网络抖动
必须配套的关键配置项
单独开启 sendfile on 效果有限，真正发挥优势需协同以下指令：
-
tcp_nopush on：启用 TCP_CORK，让内核攒满一个 MSS 报文再发，与 sendfile 天然互补 -
tcp_nodelay off：显式关闭 Nagle 算法干扰，避免抵消 tcp_nopush 的合并效果 -
sendfile_max_chunk 0：允许任意大小文件走零拷贝路径（默认即 0，但建议显式声明） -
gzip off或改用gzip_static on：防止压缩逻辑强制退回到用户态处理
高流量环境下的生效前提
即使配置正确，sendfile 也可能被绕过。需确认以下条件全部满足：
- 文件必须位于本地真实文件系统（ext4/XFS），不支持 NFSv3、某些 overlayfs 或容器默认存储驱动
- 响应必须是完整 GET，无 Range 请求、无 chunked transfer-encoding、无动态 header 修改
- 不能使用
alias映射到非 root 目录的非常规路径（旧版 Nginx 存兼容问题） - 后端若为代理，需禁用
proxy_buffering并确保响应体来自本地磁盘（如搭配 X-Accel-Redirect）
验证是否真正在工作
不要只看配置是否写对，要观测实际行为：
- 用
strace -p $(pgrep nginx -f worker) -e trace=sendfile64查看 worker 进程是否调用该系统调用 - 对比开启前后
pidstat -u 1中 CPU% 和ab -n 1000 -c 100 http://host/file.zip的 QPS 变化 - 检查 error log 是否出现
sendfile() failed，常见于权限不足或文件被锁
