sendfile在混合文件场景下因i/o路径差异引发资源争抢：小文件易致socket缓冲区压满、page cache淘汰风暴，大文件则可能因sendfile_max_chunk过大或tcp_nopush误配导致延迟；需按文件类型分location配置、调优内核参数并用perf/ss/stack交叉定位。
理解 sendfile 在混合文件场景下的行为差异
sendfile 系统调用本身不参与“调度”，但它的启用与否、配合的内核参数及 Nginx 配置，会显著影响 I/O 路径选择，进而放大高并发下小文件与超大文件共存时的资源争抢。小文件（如 CSS/JS/图标，100MB）则易触发内核 socket 缓冲区压满、TCP 重传抖动、page cache 淘汰风暴，导致 sendfile 实际退化为普通 read+write，甚至引发 soft lockup 或上下文切换飙升。
关键配置与内核参数协同验证
仅开 sendfile on 不够，需检查三类联动项：
-
tcp_nopush 和 tcp_nodelay 的取舍：高并发小文件建议
tcp_nopush on（合并 TCP 包），但大文件下载时若启用了tcp_nopush，可能因等待 full buffer 延迟首包或卡住流控；可考虑按 location 分离：location ~ \.(mp4|zip|iso)$ { tcp_nopush off; } -
sendfile_max_chunk：默认 0（无限制），在大文件场景下易导致单次 sendfile 占用过长 CPU 时间（尤其 ext4 + barrier 场景）。建议设为
512k或1m，强制分片，降低单次系统调用耗时，缓解调度延迟 -
内核侧配合：确认
/proc/sys/net/ipv4/tcp_wmem和tcp_rmem未被压到下限；/proc/sys/vm/dirty_ratio若过高（如 40），大文件写入可能触发突发 flush，干扰 page cache 回收——建议调至 15~20
定位抖动根源的实操方法
不用猜，用工具链交叉验证：
- perf record -e 'syscalls:sys_enter_sendfile' -p $(pidof nginx)：观察 sendfile 调用频率、返回值（-EAGAIN？-EIO？）、耗时分布；若大量超 10ms，说明底层 block 设备或 page cache 压力已显现
-
ss -i 查看各连接的
retrans、rcv_space、qsize：若某类大文件连接持续qsize接近rcv_space，说明接收端吞吐不足，倒逼发送端 sendfile 阻塞 -
cat /proc/$(pidof nginx)/stack 抽样：频繁出现
ext4_file_read_iter→wait_on_page_bit→io_schedule，表明 page cache 缺页严重，sendfile 正在同步回填，此时应关 sendfile 或调小sendfile_max_chunk
混合场景下的推荐实践
没有银弹，但有收敛路径：
- 对静态小文件（sendfile on +
tcp_nopush on，确保高效零拷贝 - 对大文件（>50MB），关闭该 location 的
sendfile，改用aio on;+directio 4m;，绕过 page cache，避免污染；同时配output_buffers 1 128k;控制用户态缓冲 - 启用
open_file_cache max=10000 inactive=30s;并搭配open_file_cache_valid 60s;，减少小文件重复 open 开销，间接缓解大文件带来的 fd 压力 - 监控维度加一项：
nginx_stub_status中的Reading连接数突增 +Writing持续高位，大概率是 sendfile 在大文件上卡住 socket 发送队列
