sendfile_max_chunk 是 Nginx 控制 sendfile 单次传输量的参数，用于避免大文件传输阻塞 worker 进程，通过限制每次 sendfile 数据量（如 1m）实现协程式让渡，提升并发响应能力。
sendfile_max_chunk 是 Nginx 中用于控制 sendfile 系统调用单次传输数据量的参数，主要作用是避免大文件传输时长时间独占 worker 进程，影响其他请求处理。它不直接限制“带宽”或“总传输量”，而是通过拆分传输批次，让出 CPU 和事件调度权，提升并发响应能力。
理解 sendfile_max_chunk 的作用机制
启用 sendfile on 后，Nginx 默认由内核直接从文件描述符复制数据到 socket，绕过用户态内存拷贝，效率高。但若文件很大（如几百 MB 视频），一次 sendfile() 可能持续较长时间，导致该 worker 无法及时处理新连接或超时请求。
sendfile_max_chunk 强制将单次 sendfile 操作的数据量限制在指定字节数内（例如 1m 表示 1MB），之后主动让出控制权，交由事件循环调度其他任务。本质上是一种“协程式让渡”，而非硬性限速。
合理设置 sendfile_max_chunk 的建议值
- 默认值为 0，表示不限制单次传输大小（即尽可能一次送完），适合小文件或低并发场景
- 对中高并发、含大静态资源（如视频、安装包）的服务，建议设为
512k～2m - 若观察到 worker 进程 CPU 持续 100% 且响应延迟升高（尤其在大量下载时），可尝试调低至
256k - 不要设得过小（如
4k），否则频繁系统调用反而增加开销，抵消sendfile优势
配合其他参数协同优化
单独调整 sendfile_max_chunk 效果有限，需结合以下配置：
-
sendfile on;：必须开启，否则该参数无效 -
tcp_nopush on;：与sendfile协同，确保数据以满包方式发送，减少网络小包 -
worker_connections和multi_accept：确保足够连接容量承接让渡后的新请求 - 避免与
aio on混用（尤其在 Linux 上），二者机制冲突，可能导致不可预期行为
验证是否生效的方法
可通过以下方式确认配置已加载并起效：
- 执行
nginx -t && nginx -s reload后检查错误日志，确认无 warning - 使用
strace -p $(pgrep nginx) -e trace=sendfile64抓取系统调用，观察返回值是否接近设定的 chunk 大小 - 在高负载下用
pidstat -u 1对比调整前后 worker 进程的 %usr 和 %wait，理想情况是 CPU 峰值下降、等待时间分布更均匀
