sendfile_max_chunk 用于限制 sendfile 单次传输字节数，避免大文件长期独占 worker 进程；需配合 sendfile on 使用，典型值为 512k～2m，可提升并发稳定性而非总传输速度。
通过 sendfile_max_chunk 限制单次传输量，本质是控制内核零拷贝（sendfile）每次向 socket 写入的数据上限，从而避免一个超大静态文件（如几 GB 的安装包、视频）在传输过程中长期独占 worker 进程，阻塞其他请求。它不减少总传输时间，但能提升并发响应的公平性与稳定性。
sendfile_max_chunk 的作用机制
该指令仅在启用 sendfile on 时生效，用于约束 Nginx 调用内核 sendfile() 系统调用时，单次搬运的最大字节数。默认为 0（即不限制），此时内核可能一次搬运数百 MB，导致当前 worker 在该连接上长时间不可调度。
设置合理值后，Nginx 会将大文件分块推进：每块传输完，主动让出 CPU，允许处理其他事件（新连接、定时器、其他请求的 read/write）。这相当于为大文件传输“注入呼吸点”。
推荐配置值与依据
典型值范围为 512K ~ 2M，常见生产实践如下：
- 512K（524288）：适合高并发、小文件占比高的场景（如 API + 静态资源混合），响应延迟敏感；
- 1M（1048576）：平衡吞吐与调度公平性，多数 CDN 边缘节点或下载站采用；
- 2M（2097152）：带宽充足、大文件为主且连接数不高的场景（如内部镜像仓库），减少系统调用次数。
不建议设为低于 64K（影响效率）或高于 4M（失去调度意义）。需结合 worker_connections 和平均并发连接数测试调整。
配合其他关键参数协同生效
单独设 sendfile_max_chunk 效果有限，必须搭配以下配置：
-
开启 sendfile：
sendfile on;（否则该指令无效）； -
禁用 tcp_nopush：
tcp_nopush off;（避免其与 sendfile_max_chunk 冲突，因 tcp_nopush 试图攒满 TCP 包再发，会抵消分块效果）； -
启用异步 I/O（可选但推荐）：Linux 上设
aio threads;+directio 4m;可进一步卸载大文件读取压力，尤其对机械盘有效； -
限制单连接带宽（辅助手段）：
limit_rate 10m;可防单连接吃光带宽，但属于应用层限速，和 sendfile_max_chunk 的调度目标不同。
验证是否生效
可通过以下方式确认配置已起作用：
- 用
strace -p $(pgrep nginx) -e trace=sendfile64观察实际每次sendfile64调用的count参数是否接近设定值； - 压测时监控
nginx_stub_status中的Active connections和Writing数，若大文件下载期间Writing数稳定、无持续飙升，说明 worker 未被锁死； - 对比配置前后，相同并发下小请求的 P95 延迟变化——理想情况是大文件下载时，小请求延迟波动明显收窄。
