高权重节点内存溢出排查需先确认是否真溢出，再查清仅该节点发生原因及流量分配是否失衡；登录节点执行ps、/proc/limits和dmesg三步定位，结合access_log中$upstream_addr统计验证流量倾斜，并检查健康状态、响应头大小等自身脆弱点。
高权重节点内存溢出，不是权重本身吃内存，而是它被分到过多请求后，暴露了自身资源瓶颈或配置缺陷。排查关键在于：确认是不是真溢出、查清为什么只在这台节点上发生、以及判断流量分配是否合理放大了问题。
先验证是不是这台节点真在内存溢出
别直接调 Nginx 配置，先登录该高权重点（比如 192.168.1.20），用三步快速定位：
- ps -o pid,vsz,rss,comm -C java -C node -C python —— 看主进程 RSS 是否持续上涨，15 分钟内涨超 200MB 且不回落，基本可定性
- cat /proc/$(pgrep -f 'your-app.jar')/limits | grep "Max address space\|Max locked memory" —— 检查是否被 ulimit 限制住，导致 OOM killer 杀进程
- dmesg -T | tail -20 | grep -i "killed process" —— 若出现 “Out of memory: Kill process”，说明已触发系统级 OOM
检查流量是否真的过度倾斜到该节点
权重只是调度输入，实际分发可能严重偏离预期。必须用真实数据验证：
- 在 Nginx 的 access_log 中加入 $upstream_addr，跑 5 分钟压测（ab -n 5000 -c 200，禁用 keepalive），再统计：
- awk '{print $12}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
- 若 192.168.1.20:8080 占比远超其理论权重（如 weight=5 / 总权重=12 → 应≈42%，但实占 78%），说明加权轮询被干扰——重点查它是否被健康检查临时剔除过、是否响应慢导致 Nginx 自动重试跳过其他节点
看它是不是在“带病扛压”
高权重会加速暴露节点自身的脆弱点。重点查这几项：
- 响应头过大：直连 curl -v http://192.168.1.20:8080/health | grep '^proxy_buffer_size 还是默认 4k，就会反复触发 502 并堆积缓冲区
- 连接积压：运行 ss -s | grep "tw" 和 netstat -s | grep "listen overflows"，数值每分钟增长 >10，说明 accept queue 溢出，请求卡在内核态不进应用
- 日志里有没有高频报错：如 "too many open files"、"max virtual memory exhausted"、"GC overhead limit exceeded"，这些不会立刻崩，但会让内存使用曲线陡升
检查 upstream 配置是否无意加剧压力
有些配置看着合理，实则和高权重形成“组合伤害”：
- slow_start 被关闭：新上线的高权重点若没设 slow_start，Nginx 会瞬间把满额流量砸过去，毫无缓冲
- max_fails=0 或没配：该节点已开始间歇性超时，但因没健康检查，Nginx 还照常按权重转发，等于持续往故障节点导流
- keepalive 连接池复用不当：upstream 块里没配 keepalive 128，又开了 proxy_http_version 1.1，结果每个请求建新连接，socket 缓冲 + TLS 握手开销双倍吃内存
