Nginx 中如何利用 error_log 排查 Nginx 共享内存溢出-Nginx-PHP中文网

nginx error_log 不直接记录“共享内存溢出”，但可通过 tls 握手退化、缓存失效、限流绕过、debug 日志中的 shm_alloc failed 或 zone "xxx" is full 等间接线索识别，并需结合 ipcs、nginx -t 和系统指标交叉验证。

nginx 中如何利用 error_log 排查 nginx 共享内存溢出

Nginx 的 error_log 本身不会直接记录“共享内存溢出”字样，但它能反映共享内存区（如 ssl_session_cache、proxy_cache、limit_conn_zone 等）因满载导致的异常行为链。关键不是等它报错，而是识别它留下的“间接证据”，再结合其他手段交叉验证。

error_log 中需重点捕获的共享内存溢出线索

TLS 握手退化相关日志
当 ssl_session_cache 满时，新会话无法缓存，强制走全握手（full handshake），这会显著增加 CPU 和内存开销，并可能在日志中留下痕迹：
- 反复出现 SSL_do_handshake() failed 或 SSL_write() failed（尤其伴随 Resource temporarily unavailable）
- 大量 client SSL certificate verify error（非证书问题，而是握手流程异常中断所致）
- *xxx SSL_read() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca) 类错误集中爆发，但客户端证书实际有效
缓存模块拒绝服务信号
proxy_cache 或 fastcgi_cache 共享内存满时，Nginx 无法新建缓存条目，但通常不报错；可观察：
- upstream cache miss 频率异常升高（需配合 $upstream_cache_status 记录到 access_log）
- cache manager process X exited with code 0 频繁重启（cache manager 负责清理，若反复退出可能因共享内存写入失败）
限流/连接限制失效表现
limit_conn_zone 或 limit_req_zone 共享内存满后，新连接/请求将绕过限制：
- limiting requests, excess: X.XX 日志突然消失，且并发连接数激增（需比对 stub_status 或 /proc/PID/fd/ 数量）
- accept() failed (24: Too many open files) 与 limiting connections by zone 日志并存 → 提示句柄耗尽且限流机制已失能
debug 日志中的内存分配异常
开启 error_log ... debug; 后，搜索以下关键词：
- shm_alloc failed（极少见，但一旦出现即明确指向共享内存分配失败）
- zone "XXX" is full（部分模块如 nginx-module-vts 或 OpenResty 的 resty.limit.count 会显式打印）
- ngx_slab_alloc_locked 大量重复调用 + failed 或超时返回

如何让 error_log 更有效地暴露问题

统一启用 debug 级别（临时）
```
error_log /var/log/nginx/error.log debug;
```
注意：仅用于排查期，日志量剧增，需控制时长并确保磁盘空间充足。

Nginx Config Linter
对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

在 http 块中定义全局变量用于命中率统计

log_format main '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'ssl_reused="$ssl_session_reused" cache_status="$upstream_cache_status"';
access_log /var/log/nginx/access.log main;

通过分析 access.log 中 ssl_reused="."（点号表示未复用）占比是否持续 >80%，反推 ssl_session_cache 是否长期满载。

配合 kill -USR1 触发共享内存状态输出（需 debug 日志支持）
执行 kill -USR1 $(cat /var/run/nginx.pid) 后，主进程会在 error.log 中输出类似：

2026/07/09 02:15:22 [notice] 12345#12345: signal 30 (SIGUSR1) received from 67890
2026/07/09 02:15:22 [notice] 12345#12345: reconfiguring
2026/07/09 02:15:22 [notice] 12345#12345: using the "epoll" event method
2026/07/09 02:15:22 [notice] 12345#12345: start worker processes
2026/07/09 02:15:22 [notice] 12345#12345: start worker process 12346
2026/07/09 02:15:22 [debug] 12345#12345: SHM zone "SSL" used: 99.8% (10485760/10485760)

这类日志需开启 debug 级别才可见，是判断共享内存使用率最直接的依据。

必须联动的验证手段（单靠 error_log 不够）

检查共享内存实际使用情况

ipcs -m | grep nginx
# 查看 key、size、nattch（附着进程数）、lpid（最后操作 PID）

确认是否多个 server 块重复定义同名 zone
运行 nginx -T 2>/dev/null | grep -A2 "ssl_session_cache\|limit_conn_zone"，避免配置冲突导致共享内存被多次初始化或覆盖。
对比系统级指标
若 error_log 中 TLS 相关错误激增，同时 ps -o pid,rss,comm -C nginx 显示 RSS 持续上涨、dmesg | grep -i "killed process nginx" 出现 OOM 记录，则大概率是 ssl_session_cache 设置过大或命中率过低，引发堆内存持续分配而无法回收。

不复杂但容易忽略