Nginx这5个参数，能把你从熬夜抢修变成准时下班？十年BAT架构师的实战调优清单

凌晨两点，报警又响了，页面超时、CPU飙到90%，你在命令行里翻着 nginx.conf，心里只有一个念头：到底哪儿挂了？说实话，我见过太多团队把性能问题归咎于业务代码，其实很多时候只是几个配置没调好。Nginx不是魔法，但它的几个核心参数会决定你是熬夜抢修还是安稳下班。下面把我这些年在大流量场景里反复验证的思路和可执行步骤讲清楚，少走弯路。

先说最容易被忽视但最关键的工作进程数。Nginx 是事件驱动的，一个 worker 的效率很高，但如果工作进程数和机器核心数严重不匹配，就会出现无谓的上下文切换和竞争。我常用的方法是先观察机器的 CPU 核心数，然后把配置改成 worker_processes auto; 并配合 epoll（Linux 默认），这样能让每个核心有独立的 worker，避免 CPU 的互相抢占。我的同事小李之前把进程设成固定值，线上高并发时出现 CPU 利用率不均、负载飙高，改成 auto 并做一次平稳重启后，平均响应时间立刻下降了近 30%。不过别忘了，进程数优化是基础，后面还有文件描述符和连接数要配合。

单个进程能开多少连接，直接决定了总并发能力。理论上并发上限等于 worker_processes 乘以 worker_connections，但这只是数学公式，实际受操作系统对单进程文件描述符限制影响很大。遇到过一个项目，他们把 worker_connections 设成 1024，流量到来时出现大量 502、504，检查才发现系统 ulimit -n 太低，根本撑不起并发连接。我的建议是先评估业务每个连接的时长和并发峰值，再把 worker_connections 设置为几千到上万的量级，同时调整操作系统的文件句柄上限，确保系统层不会成为瓶颈。记住，改这个参数前先做好基准压测，否则你只是盲改数字。

长连接（keepalive）是双刃剑，可以显著减少 TCP 握手成本，也可能因为连接占用导致可用连接耗尽。经验上把 keepalive_timeout 设在 15 到 30 秒之间，keepalive_requests 设在千级，可以在多数浏览器短会话场景下节省大量连接重建成本。但要注意，如果你的后端响应慢或者有大量僵尸连接，过长的 keepalive 会把可用连接耗尽，反而让请求排队变多。遇到这个问题时，先观察连接的平均时长和 TIME_WAIT 数量，必要时对不同路径采用不同的 keepalive 策略，而不是一刀切。

传输层的优化常常能带来出乎意料的收益。启用 Gzip 并把压缩级别设在中等，比如 5 或 6，通常在带宽是瓶颈时能明显提升页面加载体验，但要避免对已经压缩过的资源（比如图片、zip、视频）重复压缩。设置最小压缩长度为 1k，并限定 mime 类型为文本类，会在 CPU 消耗和带宽节省之间取得比较平衡。我亲眼见过一个电商项目在峰值时关掉 Gzip 后带宽使用飙升，打开并合理设置后，首页首屏时间缩短，CDN 回源压力也下降了。

静态文件传输的优化同样重要，sendfile 联合 tcp_nopush 可以让服务器在内核态完成文件传输，减少用户态的拷贝和 CPU 占用。这在大文件或静态资源密集的场景下效果明显。但别忘了如果你的流量经过了 SSL/TLS，零拷贝的收益会被削弱，某些内核或组合下还会有兼容问题。我的经验是把 sendfile 与 tcp_nopush 在纯静态节点上开启，把 SSL 节点单独评估并做压测验证，再决定是否启用。

总体的调优流程要比单调改配置更重要。先做基线监控，明确瓶颈是 CPU、IO、还是连接耗尽，然后每次只调整一个参数并压测验证，记录 50%/95%/99% 延迟变化以及错误率和系统负载。我的同事张姐有一次通过这种方法，把 95% 延迟从 800ms 降到 300ms，改动点看似简单，但每一步都有数据支撑。最后一点，别忘了把这些经验写进运维文档和自动化脚本里，避免每次交接都像摸索新的火场。

说白了，Nginx 的这些参数不是玄学，关键在于先量化问题，再有序调整。你可以把我的流程当作一套可执行的检查清单：先看进程和核心匹配，再看连接上限和系统文件描述符，接着评估 keepalive 的利弊，再考虑压缩和零拷贝的场景适配，最后用压测验证每一步收益。这样做的好处是你不仅解决了当下的性能问题，还把下一次故障的排查时间从几个小时缩短到几十分钟。

我知道很多人被线上突发流量逼得头疼，也有人把这些调优当作一次次试错。说说你的故事：最近一次被 Nginx 搞崩的是哪个场景？你当时怎么定位和修复的，或者你有哪些还没搞透的参数想一起讨论？欢迎把细节写出来，我们共同把这些坑填平。

素材来源：关注△mikechen△，十余年BAT架构经验倾囊相授。