stub_status 不能预测硬件需求，但能揭示当前瓶颈：active connections 接近上限时需查内存；waiting 占比过高（>90%）说明内存和文件句柄压力大；reading+writing 持续偏高则可能指向网络或磁盘 i/o 瓶颈。
直接看 Nginx 状态数据本身不能“预测”硬件需求，但它能告诉你当前资源用得是否吃紧、瓶颈在哪，从而反推下一步该升级什么——内存？CPU？还是网卡？关键不是猜未来，而是读懂现在。
盯住 stub_status 的三个核心数字
启用 stub_status 后访问 /nginx_status，会看到类似：
Active connections: 18423
server accepts handled requests
2456789 2456789 19876542
Reading: 42 Writing: 156 Waiting: 18225
重点看这三项：
-
Active connections：当前活跃连接数。若长期接近
worker_connections × worker_processes上限（比如设了 1024×4=4096，却常达 3900+），说明连接池快满了，容易触发拒绝或超时——这时优先检查内存是否够用（每个连接约需几 KB 缓冲区），而不是加 CPU -
Waiting：处于 keepalive 空闲等待状态的连接。如果它占 Active 的 90% 以上（如上面例子中 18225/18423 ≈ 99%），说明大部分是长连接，I/O 压力低，CPU 几乎不忙，但内存和文件句柄消耗高——应关注内存是否充足、
worker_rlimit_nofile是否调高 - Reading + Writing：正在收发数据的工作连接。这两项持续偏高（比如合计常超 500），且伴随响应时间上升，往往指向网络带宽打满或磁盘 I/O 拖累（尤其开了 proxy_cache 但没配 SSD 缓存盘）
结合自定义日志，定位真实瓶颈
仅看连接数不够，得知道“慢在哪”。用自定义日志格式记录耗时：
log_format perf '$remote_addr [$time_local] "$request" $status $body_bytes_sent ' '<br> $request_time $upstream_response_time $upstream_cache_status';
分析日志时重点关注：
- 若
$request_time大、但$upstream_response_time小 → 瓶颈在 Nginx 本体：可能是 SSL 握手慢（查 CPU 单核利用率是否持续 >80%）、Gzip 压缩太重、或正则匹配复杂（Lua 脚本多）→ 这时要换更高主频 CPU，而非堆核心数 - 若两者都大，且
$upstream_cache_status长期为MISSED→ 缓存失效严重，可能 keys_zone 内存不足（见下一点），或后端响应慢拖垮整体 → 此时加内存比加 CPU 更有效 - 若大量请求
$request_time在 60s 左右整数倍 → 很可能是后端超时或客户端断连，和 Nginx 硬件关系不大，别盲目升级
用 keys_zone 使用率判断内存是否真够
proxy_cache 开启后，keys_zone 是共享内存，专门存缓存 key。它不随并发量涨，只和“你打算长期缓存多少个不同 URL”有关。
估算方法很直接：
- 查你实际用到的
proxy_cache_key表达式（比如$scheme$host$request_uri） - 抽样 10 分钟真实访问日志，提取所有去重后的 key 值，统计总数 N
- 按官方基准：1MB keys_zone ≈ 存 8000 个 key → 至少需要
ceil(N ÷ 8000)MB，再加 30% 冗余 - 如果上线后
$upstream_cache_status持续 MISS，而磁盘缓存目录里文件越积越多，nginx -s reload后也不改善 → 基本就是 keys_zone 不足，内存扩容最直接
把状态数据当标尺，动态调配置
硬件不是一步到位，而是跟着状态走：
- 每天固定时间跑一次
curl http://127.0.0.1:8080/status/json，存入数据库，画出 Active connections 和 Waiting 的 7 日趋势 → 若 Waiting 曲线持续抬升，说明用户端 keepalive 时间变长，应适当调大keepalive_timeout并确保内存预留足够 - 发现某次促销前
Active connections峰值从 1.2 万跳到 5.8 万，而当前 16GB 内存下 swap 开始频繁使用 → 下次扩容就明确：内存必须到 32GB，且要配万兆网卡，因为连接数翻 4 倍，网络包处理压力同步放大 - CPU 使用率长期低于 30%，但
Reading/Writing高、延迟升 → 别换 CPU，去查网卡中断是否集中在一个核上（用cat /proc/interrupts），考虑开启 RPS 或换多队列网卡
