sendfile优化需嵌入Nginx多进程+异步事件驱动流水线：Linux下必须显式启用epoll、关闭accept_mutex、开启multi_accept；配合tcp_nopush、禁用gzip/proxy_buffering；按文件大小分级配置，绑定CPU核并调优内核参数。
sendfile 的优化不是单独调一个开关的事，它必须嵌入 Nginx 多进程 + 异步事件驱动的整体流水线里才能释放极致吞吐。核心在于让零拷贝路径不被阻塞、不被拆断、不被上下文切换打断。
确保 sendfile 与事件模型真正协同
Linux 下必须显式启用 epoll，并关闭 accept_mutex：
- events 块中固定写死 use epoll;（不能依赖自动探测，避免 fallback 到 poll/select）
- accept_mutex off;：多 worker 同时竞争新连接时，避免串行化 accept，否则 sendfile 的并发分发会被卡在连接接入层
- multi_accept on;：每个 worker 在一次事件循环中尽可能 accept 所有就绪连接，减少后续 epoll_wait 轮询次数，让 sendfile 更早进入数据传输阶段
匹配内核能力做直通式传输
sendfile 不是万能的——它只在特定条件下走零拷贝路径（如文件未被 mmap 修改、无 proxy_buffering、无 gzip）。要让它稳定生效：
- sendfile on; 必须开启
- tcp_nopush on;：配合 sendfile，把整个文件响应打包成一个 TCP 报文段发出，避免 Nagle 算法拆包导致多次 syscall
- directio 4m;（对 ≥4MB 文件）：绕过页缓存，直接 DMA 读盘 + sendfile 写网卡，适合大静态资源（如视频、安装包），但需确保文件对齐（directio_alignment 512;）
- 禁用可能中断零拷贝链路的配置：proxy_buffering off;、gzip off;（若需压缩，改用应用层或 CDN 处理）
worker 进程与系统资源闭环对齐
sendfile 的吞吐上限由 worker 并发能力、文件句柄数、内核 socket 缓冲区共同决定：
- worker_processes auto;，并搭配 worker_cpu_affinity auto;：让每个 worker 绑定独立 CPU 核，避免跨核 cache line bouncing 影响 sendfile 的内存拷贝/映射效率
- worker_connections 65535;，但前提是系统 ulimit -n ≥ worker_processes × worker_connections × 2（预留后端连接和临时 fd）
- 内核参数同步调优：net.core.wmem_max 和 net.core.rmem_max 设为 4–16MB，匹配 sendfile 大块传输节奏；vm.dirty_ratio 可适当提高（如 40），避免脏页回写抢占 sendfile 的 I/O 带宽
按业务特征做路径分级
不是所有文件都适合走 sendfile —— 小文件、热文件、带条件逻辑的资源需要差异化处理：
- ≤8KB 小文件：关闭 sendfile，启用 tcp_nodelay on; + 内存缓存（open_file_cache），降低 syscall 开销
- 高频小图/字体等：用 sendfile_max_chunk 256k; 限制单次 sendfile 量，防止单请求长期占用 worker 事件循环
- 大文件下载服务：单独开一组 dedicated worker（用 pid /var/run/nginx-download.pid; 隔离），配置更高 worker_connections 和专用 directio 策略
