sendfile 是 nginx 提升静态文件 i/o 吞吐量的核心机制，通过零拷贝绕过用户态；仅适用于本地磁盘静态文件，需配置 sendfile on 与 tcp_nopush on，并避免 gzip 等干扰指令。
sendfile 是 Nginx 提升静态文件 I/O 吞吐量最直接有效的机制，核心价值在于绕过用户态、减少内存拷贝和上下文切换。它不适用于动态内容或反向代理场景，只在服务本地磁盘文件时生效。
启用 sendfile 并确认生效
sendfile 默认在较新版本中已开启，但需显式配置并验证：
- 在 http/server/location 块中写入 sendfile on;（注意不是 sendfile_enable 或类似变体）
- 搭配 tcp_nopush on; 使用——该指令让内核攒够一个 MTU 大小再发包，与 sendfile 的零拷贝路径协同，避免小包泛滥
- 检查是否被其他指令覆盖：gzip on、sub_filter、add_header 等会强制禁用 sendfile，遇到响应被修改的场景应关闭 gzip 或改用 location 分离静态资源
- 可通过 strace -e trace=sendfile64 nginx -t 或查看 access 日志中 X-Accel-Buffering: no（若启用）辅助判断路径是否走零拷贝
适配不同文件类型与大小
并非所有文件都适合统一启用 sendfile，需按特征分层处理：
- 小文件（
- 大文件（>10MB，如视频、安装包）：除 sendfile on 外，建议加 aio threads; 和 directio 4m;，让内核线程异步预加载，避免单次 sendfile 调用因磁盘寻道阻塞 worker
- 极小文件（
- 注意：NFS 或某些网络存储可能不支持 sendfile，此时会自动退化为 read/write，可通过 error log 中 “sendfile() failed” 提示识别
规避常见失效条件
sendfile 很容易因配置冲突或运行时条件 silently 失效，需主动排查：
- 反向代理场景（proxy_pass）下 sendfile 自动禁用——因为数据源是 socket 而非文件句柄，此时应优化 upstream keepalive 和缓冲区（如 proxy_buffering off + proxy_buffer_size）替代
- 启用了 range 请求（断点续传）时，sendfile 仍可用，但需确保内核支持（Linux ≥2.6.33），旧系统可能回退
- 使用 X-Accel-Redirect 时，sendfile 依然生效，但需确保后端返回的 X-Accel-Redirect 路径指向真实文件系统路径，而非符号链接或权限受限目录
- SELinux 或 AppArmor 限制可能导致 sendfile 权限拒绝，需检查 audit.log 中 avc denied 记录
配合系统级参数放大效果
sendfile 的性能上限受内核网络栈制约，需同步调优：
- 增大 TCP 发送缓冲区：net.ipv4.tcp_wmem = 4096 65536 1048576（第三项为最大值），避免大文件发送时因缓冲不足触发重传
- 启用 TCP 快速打开（TFO）：net.ipv4.tcp_fastopen = 3，缩短连接建立阶段耗时，间接提升首包到达效率
- 禁用网卡 offload 冲突：某些厂商网卡驱动与 sendfile 的 DMA 链路存在兼容问题，可临时设 ethtool -K eth0 tso off gso off 测试是否改善吞吐抖动
- 对 SSD 存储，可适当提高 vm.dirty_ratio（如 30），允许更多脏页缓存，配合 sendfile 减少频繁刷盘干扰
