判断cpu是否为性能瓶颈需综合多维指标：cpu空闲率持续低于10%、运行队列长度长期大于cpu核数、上下文切换异常升高、perf top或pidstat显示应用进程cpu占用饱和，并排除java频繁gc等伪高cpu场景。
不能直接按内存大小“换算”权重，必须结合实际处理能力来设定。内存只是影响性能的一个维度，单独看它容易误判——比如一台 64GB 内存但 CPU 瓶颈的服务器，权重设得再高也扛不住请求。
先确认内存是否真是瓶颈
很多场景下，后端压测时 CPU 或磁盘 I/O 先打满，内存反而有富余。建议用以下方式验证：
- 查
top或htop：观察 CPU 使用率是否持续 >80%，同时内存使用率 - 看应用日志或 APM 工具（如 Prometheus + Grafana）：统计 P95 响应时间突增时，对应节点的
load average和wait I/O是否同步升高 - 做简单压测：用
ab或wrk对单台后端发起并发请求，记录 QPS 和平均 RT，对比不同配置机器的实际吞吐
内存大 ≠ 权重高，要算“有效服务能力”
假设三台服务器：
- A：32GB 内存，4 核 CPU，实测稳定 QPS=1200，P95 RT=80ms
- B：64GB 内存，8 核 CPU，但磁盘慢，实测 QPS=900，P95 RT=180ms
- C：16GB 内存，4 核 CPU，SSD+优化参数，实测 QPS=1500，P95 RT=60ms
此时权重不该是 32:64:16（即 2:4:1），而应参考 QPS 比例约 1200:900:1500 → 简化为 4:3:5，再取整为 weight=4、weight=3、weight=5 更合理。
配置时注意这些细节
权重写法必须严格合规，否则 nginx 启动失败：
- 只能出现在
upstream块内的server行末尾，例如：server 10.0.0.10:8080 weight=5 max_fails=2 fail_timeout=30s; - weight 值为正整数，默认是 1；设为 0 表示临时下线（仍参与健康检查）
- 不支持小数、负数、字符串；写错会导致
nginx -t报 invalid number of the "weight" parameter - 搭配
slow_start=60s防止新扩容的大内存机器一上线就被打爆
后续要动态适配，别只靠静态配置
硬件资源不变，但业务逻辑升级、数据库慢查询增多，都会让原本“够用”的内存变成瓶颈。建议：
- 把后端 P95 延迟、CPU 使用率、连接数等指标接入监控系统
- 用
nginx-upstream-dynamic-servers模块 + Python 脚本，每分钟根据指标自动重算权重并推送 - 或上 OpenResty + Lua，在
balancer_by_lua_block中实时选节点，响应越快权重越高
