Ubuntu下Nginx内存占用过高怎么办

Ubuntu 下 Nginx 内存占用过高的排查与优化

一、快速定位占用来源

• 观察整体与进程内存：使用 top/htop 聚焦 RES（常驻内存），并按内存排序；用命令仅观察 Nginx 进程：top -p $(pgrep nginx | tr ‘\n’ ‘,’)；查看各 worker 的 RSS：ps -o pid,rss,command -p $(pgrep nginx)。
• 查看内存分布与共享内存：pmap -x | tail 观察是否有异常大块；ipcs -m | grep nginx 检查共享内存段。
• 检查缓存与配置：grep -r “proxy_cache|fastcgi_cache” /etc/nginx/ 确认是否启用缓存；审查缓冲区与连接相关指令（如 large_client_header_buffers、proxy_buffers、client_max_body_size）。
• 日志与监控：tail -f /var/log/nginx/error.log | grep -i “memory”；结合 Prometheus + Grafana 观察每个 worker 内存、缓存命中率与连接数趋势。

二、常见根因与对应处理

• 工作进程过多：每个 worker 会复制一份内存常驻集，进程数过多会线性放大内存。建议将 worker_processes 设为 auto（或不超过 CPU 逻辑核心数），并按负载逐步微调。
• 单个请求/请求头过大：过大的请求头或请求体会触发更大的缓冲区分配。多数场景将 client_header_buffer_size 设为 4k~8k 即可，超长头部再用 large_client_header_buffers 4 8k 按需分配；同时限制上传大小 client_max_body_size（如 10m）。曾出现将 client_header_buffer_size 设为 20000k 导致内存暴涨的案例，修正为 32k 后恢复。
• 代理/上游响应缓冲不合理：过大的 proxy_buffers 会为每个连接预分配较多内存。可按响应体大小调小，例如 proxy_buffers 8 16k; proxy_busy_buffers_size 32k; proxy_buffer_size 4k;。
• 缓存配置不当：proxy_cache_path 的 max_size 过大或 inactive 时间过长会占用过多内存/磁盘；可按需设置如 max_size=10g、inactive=60m，并评估是否需要关闭或缩小缓存以缓解短期压力。
• SSL 会话缓存过大：HTTPS 场景下 ssl_session_cache 共享内存设置过大也会抬升内存，可改为 shared:SSL:20m; ssl_session_timeout 10m;。
• 第三方模块或内存泄漏：若内存随时间单调增长且不回落，可能是模块或泄漏。可临时移除可疑模块、编译时开启 –with-debug、将 error_log 调为 debug（仅排查期间）、必要时用 gdb/pmap/smaps 分析 worker 内存段与转储内容。

三、关键配置示例与计算

• 进程与连接（按 CPU 与并发目标设定）：
  • worker_processes auto;
  • events { worker_connections 1024~4096; use epoll; multi_accept on; }
  • 估算最大并发连接数：最大连接数 = worker_processes × worker_connections；同时关注系统 ulimit -n 与 worker_rlimit_nofile。
• 请求与头部：
  • client_header_buffer_size 4k; large_client_header_buffers 4 8k;
  • client_body_buffer_size 16k; client_max_body_size 10m;
• 代理缓冲（按上游响应体大小调整）：
  • proxy_buffer_size 4k; proxy_buffers 8 16k; proxy_busy_buffers_size 32k;
• 缓存与静态资源：
  • proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
  • 静态资源启用 sendfile on; tcp_nopush on; expires 7d; access_log off; 减少内存拷贝与日志开销。
• 长连接与压缩：
  • keepalive_timeout 30s; keepalive_requests 100;
  • gzip on; gzip_types text/plain text/css application/json;（压缩会增加 CPU 使用，注意权衡）

四、应急与长期治理

• 应急降压：
  • 临时限制并发：limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;
  • 临时关闭或缩小缓存：proxy_cache off; 或减小 ssl_session_cache；
  • 平滑重启释放碎片：nginx -s reload；必要时 systemctl restart nginx。
• 运行期约束：
  • 使用 cgroups 限制 Nginx 进程组内存（如写入 memory.limit_in_bytes），防止单实例失控。
• 监控与验证：
  • 建立以 每个 worker 内存、连接数、缓存命中率 为核心的监控与告警；每次调参后对比前后 RSS/缓存命中率/错误率 的变化，逐步逼近最优配置。