要确认 sendfile 是否真正起效，需通过 strace 观察 sendfile64 系统调用是否被调用，并结合 CPU 降低、延迟缩短、QPS 提升等指标验证，同时排查文件系统、Nginx 模块及响应头等零拷贝前提条件，并配合 tcp_nopush 优化网络包发送。
要确认 sendfile 是否真正起效并带来加速，不能只看配置写了 sendfile on，必须从运行时行为和系统指标两个层面交叉验证。实测中常见“配置开着但实际没走零拷贝路径”的情况，关键在于观察内核是否真的调用了 sendfile64 系统调用，以及 CPU、延迟、吞吐是否出现符合预期的变化。
用 strace 实时抓取系统调用路径
这是最直接、最可靠的验证方式，能明确看到 Nginx worker 进程是否在走零拷贝路径：
- 先找一个活跃的 worker 进程 PID：
pgrep nginx | head -1 - 用 strace 监控其 sendfile、read、write 调用：
strace -p PID -e trace=sendfile64,read,write -f 2>&1 | grep -E "(sendfile64|read|write)" - 同时发起请求（如
curl http://your.site/logo.png），观察输出：若持续看到sendfile64(调用，且几乎不出现read(和write(，说明零拷贝生效；若大量出现 read+write 组合，则已退化为传统路径
对比开启/关闭 sendfile 的性能指标变化
在相同压测条件下（例如 wrk -t4 -c100 -d30s），关闭 sendfile 后再开启，观察三类硬指标是否出现显著改善：
- CPU 使用率下降：特别是 sy（系统态）占比应明显降低，典型降幅为 35%～50%，因为绕过了用户态拷贝和频繁上下文切换
- 响应延迟缩短：1MB 静态文件在千兆网络下，P95 延迟通常从 8–12ms 降至 2–4ms
- QPS 提升：实测提升约 2.1 倍（如从 14,000 → 29,500），尤其在高并发、大文件场景下更明显
检查是否满足零拷贝前提条件
即使 strace 显示了 sendfile64，也要排查以下常见失效点，否则加速效果会打折扣或完全丢失：
- 确认文件是本地 ext4/XFS 文件系统上的普通文件，大小 ≥ 4KB，未被其他进程加锁或以 O_DIRECT 方式打开
- 确保未启用
gzip on、sub_filter、proxy_pass或alias指向 NFS/FUSE 路径 - 检查响应头是否含
Content-Length：缺失该头会导致 Nginx 回退到 chunked 编码，无法使用 sendfile
配合 tcp_nopush 观察网络包行为
sendfile 单独开启效果有限，需与 tcp_nopush on 协同才能体现批量传输优势：
- 用
tcpdump -i any port 80 -w sendfile.pcap抓包，对比开启/关闭tcp_nopush时的 TCP 包数量和大小 - 开启后，应看到更少的小包、更多满载 MTU（如 1448 字节）的数据段，说明 sendfile 数据被有效攒包发送
