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</worker_pid>观察实际每次传输字节数是否被限制 - 对比调优前后，使用
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 专注代理与缓存调度
