Linux如何优化Nginx性能参数_Linux Nginx性能参数优化大全-LINUX-PHP中文网

worker_processes 应设为 cpu 核心数（如 4），配合 worker_cpu_affinity 精确绑核（如 0001 0010 0100 1000），容器中需按 --cpus 限制匹配配置，否则静默降级为单核运行。

linux如何优化nginx性能参数_linux nginx性能参数优化大全

Linux 下 Nginx 的 worker_processes 不设成 auto 或对应 CPU 核心数，就等于把多核当单核用。但光设对数量还不够——默认所有 worker 进程可能挤在同一个 CPU 核上跑，导致上下文切换频繁、缓存失效多。

实操建议：

worker_processes auto 是安全起点，但生产环境建议显式写成具体数字（如 worker_processes 4），避免容器等场景下 auto 误读为 1
配合 worker_cpu_affinity 绑核，例如 4 核机器用 worker_cpu_affinity 0001 0010 0100 1000，让每个 worker 独占一个核
容器中若限制了 CPU quota（如 --cpus=2），worker_processes 必须 ≤ 2，且 worker_cpu_affinity 要按实际可调度的逻辑核来配，否则会静默降级为单核运行

很多人以为长连接越多越好，结果发现并发上不去、TIME_WAIT 暴涨、甚至出现 accept() failed (24: Too many open files)。根本原因是：过长的 keepalive 会让 worker 进程长时间持有空闲连接，挤占本可用于新请求的连接槽位。

实操建议：

keepalive_timeout 建议设为 15–30 秒（HTTP/1.1 场景），CDN 回源或内网调用可放宽到 60 秒；超过 60 秒基本没收益，反而拖慢连接回收
keepalive_requests 控制单连接最大请求数，默认 100 够用；高 QPS 小包场景（如 API 网关）可调到 1000，但要同步检查 worker_connections 是否足够
如果用的是 HTTP/2，keepalive 行为由客户端控制，Nginx 侧 keepalive_timeout 影响变小，重点应放在 http2_max_concurrent_streams 和 http2_idle_timeout 上

这三个参数都跟 TCP 发送行为有关，但作用阶段不同：sendfile 决定是否绕过用户态拷贝，tcp_nopush 控制 Nagle 算法是否延迟发包，tcp_nodelay 则强制立即发小包。开错组合会导致吞吐掉 20%+ 或首字节延迟升高。

实操建议：

静态文件服务（HTML/CSS/JS/图片）必须开 sendfile on + tcp_nopush on，这是零拷贝 + 包合并的最佳搭配
动态接口（如 FastCGI/Proxy）建议关 sendfile（设为 off），因为响应体常带 header、chunked 编码或流式输出，sendfile 不适用；此时开 tcp_nodelay on 可减少交互延迟
tcp_nopush 和 tcp_nodelay 不要同时设为 on——它们逻辑冲突，Nginx 会以 tcp_nodelay 为准，但配置冗余易引发误解

这个缓存确实能降低 stat() 系统调用开销，但一旦配置不当，轻则缓存击穿（大量文件变更未及时更新），重则内存暴涨（缓存了不该缓存的临时文件）、甚至因缓存失效策略 bug 导致 500 错误（尤其在频繁部署的 CI/CD 环境）。

实操建议：

只对稳定不变的静态资源目录启用，例如 open_file_cache max=10000 inactive=20s，inactive 时间别超过 30 秒，否则变更后用户会长时间看到旧文件
务必配 open_file_cache_valid 30s 和 open_file_cache_min_uses 2，否则访问一次就进缓存，但只用一次的临时文件（如日志下载链接）会污染缓存
禁用 open_file_cache_errors on——它会让 Nginx 把 “文件不存在” 这类错误也缓存住，导致 404 被缓存 60 秒（默认值），线上出问题很难排查

真正影响性能的从来不是单个参数调多大，而是这些参数之间的耦合关系。比如改了 worker_connections 却忘了同步调大系统 fs.file-max 和进程级 ulimit -n，再怎么优化都卡在系统限制上。