nginx内存偏高需重点分析worker进程rss：worker独立占用内存，master仅管理；用ps、pgrep定位高rss worker；检查连接不均、大请求体、缓存/缓冲区配置及模块泄漏；结合worker_connections与buffer参数估算合理内存，持续观察rss变化趋势。
当 Nginx 的 worker_processes 配置导致整体内存占用偏高时，关键不是看 Master 进程，而是逐个分析每个 Worker 进程的物理内存（RSS）分布——因为每个 Worker 是独立进程，各自加载配置、维护连接缓冲区和模块状态，内存不共享。
确认哪些是 Worker 进程
Master 进程只做管理，内存极低；真正吃内存的是它的子进程。可用以下命令快速区分：
- ps -C nginx -o pid,ppid,rss,comm --sort=-rss：输出所有 nginx 进程，按 RSS 降序排列；Worker 的 PPID 是 Master 的 PID，而 Master 的 PPID 通常是 1 或 systemd
- pgrep -P $(pgrep nginx)：直接列出所有 Worker 的 PID
- ps -o pid,rss,vsz,comm -p $(pgrep -P $(pgrep nginx)) | sort -k2 -nr：仅查 Worker 并按内存排序
定位内存异常的 Worker
单个 Worker 内存明显高于其他进程（比如相差 2 倍以上），说明它可能承载了过多连接、缓存或存在泄漏倾向：
- 用 ss -s 查总连接数，再用 ss -tnp | grep :80 | awk '{print $7}' | cut -d',' -f2 | cut -d'=' -f2 | sort | uniq -c | sort -nr 粗略估算各 Worker 处理连接数是否严重不均
- 检查该 Worker 是否长期处理大请求体（如文件上传）：结合 access.log 中对应时间窗口的请求大小字段（需开启
$request_length或$body_bytes_sent） - 若启用
proxy_cache或lua_shared_dict，RSS 高可能源于共享内存区已分配但未释放——注意：slab 分配器预占内存页后，ps显示的 RSS 可能包含尚未实际使用的页（按需分页机制）
关联配置与内存增长规律
Worker 内存不是固定值，它随负载动态变化。需结合配置判断是否合理：
- worker_connections × 0.4–0.5 KB 是基础连接开销，乘以 worker_processes 得理论最小内存；若实测 RSS 远高于此（如单 Worker > 800 MB），大概率是缓冲区或模块配置过大
- 重点检查：
client_body_buffer_size、proxy_buffers、ssl_buffer_size、large_client_header_buffers——这些每项都按每个连接或每个响应单独分配 - 启用
worker_rlimit_as 512m可防止单 Worker 虚拟内存失控，配合ulimit -v系统级限制更稳妥
持续观察与基线对比
内存问题常具时序特征，不能只看瞬时快照：
- 用 watch -n 3 'ps -C nginx -o pid,rss,comm --sort=-rss | head -6' 每 3 秒刷新，观察 RSS 是否缓慢爬升且不回落
- 记录压测前后各 Worker RSS 变化：例如并发从 1000 升至 5000 时，RSS 增幅是否线性？若非线性飙升，需排查缓冲区溢出写磁盘、临时文件堆积或第三方模块泄漏
- 对比同配置下不同时间段的 RSS 分布：若某次部署后所有 Worker RSS 整体抬升，优先检查是否新增了 Lua 模块、OpenResty 扩展或开启了
sub_filter等内存敏感功能
