sendfile_max_chunk用于限制sendfile单次传输字节数，避免大文件长期独占worker进程；需配合sendfile on使用，典型值为512K～2M，可提升并发稳定性而非总传输速度。

调优 sendfile_max_chunk 主要用于控制 Nginx 在启用 sendfile 时，每次系统调用（sendfile()）最多传输的字节数，从而避免大文件响应长时间占用 Worker 进程、阻塞其他请求。

理解 sendfile_max_chunk 的作用

该指令仅在 sendfile on 且内核支持 sendfile()（如 Linux）时生效。它不改变总传输量，而是将一个大文件的发送拆分为多个小块，每块不超过设定值。这样 Worker 在每次发送后可及时返回事件循环，处理其他连接上的读写事件，提升并发响应能力。

默认值通常为 0（表示不限制单次大小），此时内核可能一次拷贝数 MB 数据，导致 Worker 阻塞几十毫秒甚至更久——尤其在高并发、混合小/大文件场景下，会明显拉低吞吐和首字节时间（TTFB）。

合理设置 sendfile_max_chunk 的建议值

没有绝对最优值，需结合典型文件大小、磁盘 I/O 延迟、网络带宽及并发压力综合判断。常见实践如下：

• 一般业务（含图片、JS/CSS 等中小文件）：设为 512k 或 1m（即 524288 或 1048576 字节）较平衡，兼顾效率与响应性
• 以视频或大附件为主的站点：可尝试 256k，进一步降低单次阻塞风险
• 极低延迟要求（如实时 API + 静态资源共存）：可压至 64k，但注意过小会增加系统调用次数，轻微抬高 CPU 开销
• 不建议设为 0（不限制），除非确认负载极低且无小请求抖动问题

配置方式与验证要点

在 http、server 或 location 块中添加：

sendfile on;
sendfile_max_chunk 512k;

生效后可通过以下方式验证效果：

• 用 strace -p <worker_pid> -e trace=sendfile64 观察实际每次传输字节数是否被限制
• 对比调优前后，使用 ab 或 wrk 测试混合请求（如 90% 小文件 + 10% 10MB 文件）的 P95 延迟与 QPS 变化
• 检查 nginx -t 确保语法正确；该指令在较新版本（1.7.11+）才支持，旧版本需升级

配合其他机制协同优化

单靠 sendfile_max_chunk 不足以解决全部拥塞问题，建议同步检查：

• 启用 aio（异步 I/O）：Linux 上配合 aio on 和 directio，对超大文件绕过页缓存，减少内存拷贝
• 限制连接处理粒度：通过 epoll 多路复用 + 合理的 worker_connections 和 multi_accept 避免事件积压
• 分离动静资源：将大文件交由专用静态服务（如 Ceph/S3 + CDN）托管，Nginx 专注代理与缓存调度