Nginx问题定位之监控进程异常退出

412次阅读

没有评论

共计 3703 个字符，预计需要花费 10 分钟才能阅读完成。

Nginx 在运行过程中是否稳定，是否有异常退出过？这里总结几项平时会用到的小技巧。

1. 在 error.log 中查看是否有 signal 项，如果有，看看 signal 是多少。

比如，这是一个异常退出的情况：

$grep signal error.log

2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11

如果在进程退出后，有 coredump 文件产生，则会打出如下日志：

$grep signal error.log

2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11 (core dumped)

2. 简单方式，看进程号是否连续

一般来说，在 worker 进程启动时，其进程号都是连续的（至少相差不是很远），如果有进程退出，其进程号就不一定连续。

$ps aux | grep nginx

lizi 7223 0.0 0.0 74844 2024 ? Ss 13:32 0:00 nginx: master process ./nginx
lizi 7292 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7293 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7294 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7295 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7296 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7297 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7298 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7299 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7300 0.0 0.0 78856 5468 ? S 13:33 0:00 nginx: worker process
lizi 7301 0.0 0.0 78856 5452 ? S 13:33 0:00 nginx: worker process

可以看到，10 个 worker 进程，基本从 7292 到 7301，进程号连续。
如下：

$ps aux | grep nginx

nobody 9492 16659 26 09:18 ? 01:10:41 nginx: worker process
root 16659 1 0 Dec24 ? 00:00:00 nginx: master process ./nginx
nobody 16663 16659 11 Dec24 ? 02:41:38 nginx: worker process
nobody 19344 16659 24 10:18 ? 00:50:54 nginx: worker process
nobody 25447 16659 28 07:41 ? 01:43:56 nginx: worker process

进程号已不再连续，说明 nginx 可能有工作进程异常退出。

3. 查看 dmesg 系统消息。

在 man 手册里面是这么描述 dmesg 的：

DESCRIPTION
dmesg is used to examine or control the kernel ring buffer.

查看 dmesg 是检测系统运行状态的常用手段，通常可以帮我们排查很多问题。当然，如果有进程异常退出，dmesg 也可以看到。

$dmesg

nginx[24721]: segfault at 0000000000000001 rip 0000000000000001 rsp 00007ffff58d8180 error 14
nginx[1729]: segfault at 0000000000000190 rip 00000000004c2d27 rsp 00007ffff58d8340 error 4
nginx[22002]: segfault at ffffffffffffffff rip 000000001c959744 rsp 00007fff43caac18 error 6

rip 表示程序退出时的 ip 寄存器内容，当没有 core 文件可用时，可根据此值以及反汇编来查找程序 core 的位置。

4. 打开 coredump 文件。

一般我们在程序启动前，通过 ulimit -c ulimited 来设置 core 文件的大小，也可以修改 /etc/security/limits.conf 文件，添加如下信息：

admin soft core 1000000
admin hard core 1000000

也可以直接修改 nginx 的配置文件，添加如下配置项：

worker_rlimit_core 10000m;

而此时，在 limit 系统中，默认 coredump 文件会写在启动 nginx 时的目录，如果 nginx 在启动时 worker 进程的用户没有权限写到这个目录，进程在异常退出时，就无法产生 coredump 文件。由于 nginx 启动后，或者是由别人启动，我们无法知道 nginx 在启动时的目录，也就无法知道 core 文件的目录。我曾经碰到过这样的问题，通过日志查看，是 coredump 出来了，但却找不到 coredump 的文件。

这里有一个小技巧，查看 /proc/pid/cwd 可以看到进程的工作目录，而 core 文件会产生在工作目录。

nginx 可以配置工作目录来改变默认的工作目录，于是，我们需要配置 working_directory 为目的工作目录，我们的 core 文件也会产生在这个目录。

working_directory /path/to/core;

working_directory 与编译时指定的 –prefix=/path 不同，后者表示在配置文件中所用的相对路径所生产的绝对路径。所以，working_directory 不会影响到配置的引用路径，而仅仅是为了改变 core 文件的路径，当然 nginx 必须有写这个目录的权限，否则无法 core 出来。

所以，这里，我推荐的做法是，配置 worker_rlimit_core 与 working_directory 这两个指令，这样，就不需要修改操作系统的参数就可以正常 core 出来了。

————————————– 分割线 ————————————–

Nginx 负载均衡配置实战 http://www.linuxidc.com/Linux/2014-12/110036.htm

CentOS 6.2 实战部署 Nginx+MySQL+PHP http://www.linuxidc.com/Linux/2013-09/90020.htm

使用 Nginx 搭建 WEB 服务器 http://www.linuxidc.com/Linux/2013-09/89768.htm

搭建基于 Linux6.3+Nginx1.2+PHP5+MySQL5.5 的 Web 服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm

CentOS 6.3 下 Nginx 性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm

CentOS 6.3 下配置 Nginx 加载 ngx_pagespeed 模块 http://www.linuxidc.com/Linux/2013-09/89657.htm

CentOS 6.4 安装配置 Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm

Nginx 安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm

Nginx 日志过滤使用 ngx_log_if 不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm

————————————– 分割线 ————————————–