Nginx 中错误日志如何排查 worker 进程数满或内存溢出导致的崩溃

error_log中“exited on signal 9”或“exited with code 137”是OOM Killer终止的直接线索，需结合dmesg确认“Killed process nginx”、access.log查超大请求，并排查ulimit、cgroup内存限制及ssl_session_cache等隐性内存消耗。

错误日志本身不直接写“worker 数满”或“内存溢出”，但它会留下关键线索——这些线索需要结合系统日志、进程状态和请求特征交叉验证才能准确定位。

看 error.log 里 worker 异常退出的信号类型

重点搜索以下日志行，它们是底层崩溃最直接的映射：

1. worker process [0-9]+ exited on signal 9 → 几乎等同于被 OOM Killer 杀掉（SIGKILL）
2. worker process [0-9]+ exited on signal 11 → 段错误，常见于模块 bug、Lua 内存越界或第三方模块崩溃
3. worker process [0-9]+ exited with code 137 → 137 = 128 + 9，也是 SIGKILL，和 signal 9 含义一致
4. accept() failed (24: Too many open files) → 句柄耗尽，常与内存泄漏并存（缓存未释放→句柄卡住→新连接失败）

比对时间戳，联动 dmesg 和 access.log

单看 error.log 容易误判，必须做三重时间对齐：

1. 记下 error.log 中某条 exited on signal 9 的精确时间（如 [error] 2026/08/20 14:22:33）
2. 执行 dmesg -T | grep -i "killed process" | grep nginx，找同一时刻附近是否有 Out of memory: Kill process 12345 (nginx)
3. 查 access.log 对应时间段：是否存在大量超大请求（如 POST body > 10MB）、高频 SSL 握手、或固定 IP 短时刷千次小请求——这些都可能触发单 worker 内存暴涨

识别内存压力下的间接表现

有些问题在崩溃前就有征兆，error.log 会提前暴露异常行为：

1. 反复出现 upstream timed out，但后端实际响应正常 → 内存紧张导致事件循环延迟、定时器失准
2. 大量 request header or cookie too large 错误 → 客户端发超长头，Nginx 缓冲区持续堆积未清理
3. 密集报 SSL_do_handshake() failed 且集中在某个 worker → ssl_session_cache 配置过大或命中率极低，握手退化为全量堆分配
4. 开启 debug 日志 后，高频出现 pool alloc 或 http cleanup add → 表明内存频繁申请但未及时回收

确认是否真由 worker 数量引发

“worker 数满”不是标准术语，实际指两类情况，需分别排查：

1. worker_connections 耗尽：error.log 中伴随大量 accept() failed (23: Too many open files) 或 no live upstreams；用 ss -s 查当前 TCP 连接总数，对比配置中 worker_connections × worker_processes 是否接近
2. 系统级文件描述符不足：即使 Nginx 配了足够 worker_connections，若 ulimit -n 或 /proc/sys/fs/file-max 不足，也会导致 accept 失败；查 lsof -p $(pgrep nginx | head -1) | wc -l 看单 worker 实际打开数