怎样优化Nginx的内存使用

Nginx内存优化实用指南

一 核心原则与快速检查

• 先建立可量化的基线：用命令观察进程实际占用与变化趋势，例如查看 RSS（物理内存）与内存映射分布，定位是否为单个请求/连接导致的内存激增。
  • 示例：top -p $(pgrep nginx | tr '\n' ',')、ps -o pid,rss,command -p $(pgrep nginx)、pmap -x $(pgrep nginx | head -n1) | tail -n 10
• 区分内存类型：关注 共享内存 SHM（如 SSL 会话缓存）、缓存内存（如 proxy_cache/fastcgi_cache）、以及各 worker 的堆内存，避免“误把缓存当泄漏”。
  • 示例：ipcs -m | grep nginx、grep -r "proxy_cache" /etc/nginx/
• 快速止血：临时降低并发、关闭高内存功能、平滑重启以释放内存（不中断服务）。
  • 示例：limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;、proxy_cache off;、nginx -s reload

二 关键配置优化

• 进程与连接
  • 将 worker_processes 设为 auto（或 CPU 核心数），避免过多 worker 造成内存与上下文切换开销。
  • 结合业务并发与内存预算设置 worker_connections；估算总并发：最大连接数 = worker_processes × worker_connections。
  • 示例：worker_processes auto; events { worker_connections 1024; }
• 请求与响应缓冲
  • 合理设置客户端缓冲，避免为每个连接/请求过度分配；对大请求体设置上限并启用磁盘临时文件。
  • 示例：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;
• 长连接与超时
  • 适度缩短 keepalive_timeout、设置 keepalive_requests，降低空闲连接占用的内存与文件描述符压力。
  • 示例：keepalive_timeout 30s; keepalive_requests 100;
• 压缩与内容处理
  • 启用 Gzip（或 Brotli，需模块），对可压缩类型开启压缩，减少网络流量与后端压力（以 CPU 换带宽/内存）。
  • 静态资源启用 sendfile、tcp_nopush、expires，并关闭不必要的访问日志，降低 I/O 与内存占用。
  • 示例：sendfile on; tcp_nopush on; expires 7d; access_log off; add_header Cache-Control "public";

三 缓存与共享内存

• 代理/网关缓存
  • 使用磁盘型 proxy_cache_path，设置合理的 keys_zone 与 max_size，并控制 inactive 回收时间，避免缓存无限增长挤占内存。
  • 示例：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m;
• SSL 会话缓存
  • 使用共享内存的 ssl_session_cache，在命中率与内存占用间平衡；HTTPS 流量大时尤为重要。
  • 示例：ssl_session_cache shared:SSL:20m; ssl_session_timeout 10m;
• 连接与带宽治理
  • 对异常来源进行并发限制，作为应急与常态治理手段，降低突发流量对内存的冲击。
  • 示例：limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;

四 排查与定位

• 定位高占用来源
  • 用 pmap 查看 worker 内存段分布，识别是否因大请求/大响应、第三方模块或缓存导致占用异常。
  • 检查错误日志与监控指标（如每个 worker 的 RSS、缓存命中率），交叉验证配置变更前后的差异。
• 识别配置热点
  • 关注易放大内存的参数：large_client_header_buffers（每个请求可能占用“数量×大小”）、proxy_buffers（每个连接可能占用“数量×大小”）、以及缓存键/范围请求等。
  • 示例：large_client_header_buffers 4 16k;（每个请求最高可能约 64KB）、proxy_buffers 8 16k;（每个连接最高可能约 128KB）
• 可疑泄漏与第三方模块
  • 编译时开启 –with-debug 并启用 error_log ... debug;，逐步禁用第三方模块定位问题；必要时用系统工具（如 cgroups）对 Nginx 进程组做内存上限与回收验证。

五 监控与压测闭环

• 监控与日志
  • 建立以 Prometheus + Grafana 为核心的监控，持续跟踪：总内存使用、每个 worker RSS、缓存命中率、连接数、请求耗时等；访问日志建议使用缓冲写入降低 I/O 压力。
  • 示例：access_log /var/log/nginx/access.log main buffer=32k flush=5s; error_log /var/log/nginx/error.log warn;
• 压测与容量规划
  • 使用压测工具（如 wrk、ab、k6）在预发/灰度环境验证不同配置下的 内存占用/QPS/延迟 三角关系，逐步收敛到“满足 SLO 的最小内存配置”。
• 变更与回滚
  • 采用“小步变更 + 可回滚”策略，每次只调整 1–2 个关键参数，观察至少 一个完整的业务高峰周期，确认稳定后再推进。