共计 4099 个字符，预计需要花费 11 分钟才能阅读完成。
昨天上午查看 Zabbix 监控界面时，发现其中一台服务器的进程数量和 1 分钟负载已经达到了一个非常惊人的数量，Zabbix 默认报警数值是进程数量在 5 分钟平均值大于 1000，1 分钟系统负载 5 分钟平均值大于 5。
先大体列一下服务器的软硬件信息：
服务器硬件：Dell PowerEdge R720, 2 x Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz；62.87 GB；PERC H710 SAS RAID5
服务器操作系统：Ubuntu 14.04 LTS，内核：3.13.0-24-generic
图 1：Zabbix 报警信息（Zabbix 消息通知设定的是严重（average）级别以上通过 Web 短信网关发送短信报警）：
[img]http://img.linuxidc.com/attachments/forum/201509/08/195529je4vrmhf1z1hss1h.jpg[/img]
图 2：Zabbix 上触发器的报警条件
[img]http://img.linuxidc.com/attachments/forum/201509/08/195529cu6fa67furam3ucu.jpg[/img]
接着不久，就不断有同事反映该服务器响应非常慢，有些应用页面打开很久才出来。由于机房远在天边而且没有远程登录控制台的登录信息（这些信息在客户处），因此只能用 xshell 通过 SSH 登录到 Linux 系统，打开 top 命令看看系统运行情况，发现当前系统内已经有 5800 多个进程在运行，其中系统负载（1、5、15 分钟）都达到了 5400+，但奇怪的是 CPU、内存和硬盘 IO 都并不高，按照常理，如此高的系统负载，CPU 和 IO 等早已经应该是消耗殆尽了，但 top 显示并没有。
图 3.1: Linux 系统中的 top 信息
[img]http://img.linuxidc.com/attachments/forum/201509/08/195529kglnnnul7yqk47kw.jpg[/img]
7 秒前 上传下载附件 (269.83 KB)
图 3.2 通过 iostat、vmstat 等命令发现磁盘 IO 并不高，但系统负载却很高
[img]http://img.linuxidc.com/attachments/forum/201509/08/195530o9x98i46xi9jcrq6.jpg[/img]
7 秒前 上传下载附件 (96.88 KB)
有个开发人员说 pid 为 14898 的 java 进程并没有分配这么大的内存，这个进程有问题，要求负责编写该程序的另一个开发人员检查程序，当时我想，一个 java 进程也不至于把系统负载搞的这么高，一定有别的重要的原因没有发现。我按照往常的方法，先查看一下系统中究竟运行了什么样的程序导致系统内进程这么多，因此执行 ps –ef | more，查看一下系统内全部进程的运行情况，结果发现此命令根本没法执行，刚输出了不到一个屏幕就卡死在屏幕上了，赶紧复制一个 ssh session，继续执行，简单执行 ps，看看能不能执行，结果发现 ps 输出的内容中有大量的 ps 进程，此处感想还好 ps 还能运行只是参数不能加太多了。打开 top 命令，查看一下一个 ps 命令对应的 pid，用 top –p pid 打开，发现是 Zabbix 用户执行的 ps 命令，瞬间感觉不好，别是因为我之前写的 Zabbix 脚本中有问题导致 ps 命令没有退出，才导致的系统一分钟负载这么高。
图 4：用 top 查看 zabbix 用户的进程信息，top –u zabbix
[img]http://img.linuxidc.com/attachments/forum/201509/08/195531ij0e0oaqayo00z89.jpg[/img]
之前有同事电话问我系统中有个 java 进程无法结束，导致某个应用现在有两个 java 进程该怎么办，我跟他说试试 sudo，结果 sudo 也不好用，root 权限也无法杀死。由于当时在家里有事没在公司因此也没去查什么原因。所以此时，我想用 kill 杀掉 zabbix 的 ps 进程时就遇到了同样的问题，发现 ps 进程根本杀不死。无论是使用什么样的进程信号，TERM 还是 KILL 都不好用。仔细一看，原来这些进程的状态都成了 D 状态（上图中 S 显示的那一列）。
关于 D 状态：D 状态是一种特殊的进程状态代码（PROCESS STATE CODES），其英文示意是 Uninterruptible sleep (usually IO)，意思是不可中断的睡眠（通常是由于 IO 问题引起的），这个 IO 可能是多种 IO，内存、硬盘、网络、总线都是可能的。既然是 D 状态，那即便是 root 用户也无法杀死的，因为这样的进程它已经不接受任何进程信号，所以任何方式都将无法将其杀死，只能重新启动服务器。但这问题还没找到根源，不能草草的下结论。
检查 Zabbix 的用户参数中设定的脚本和命令行，发现大部分命令行有 ps，但并不没有任何问题，因此初步排除 Zabbix 脚本或命令行中存在的问题，如下图所示：
图 5：Zabbix 用户参数命令行：
[img]http://img.linuxidc.com/attachments/forum/201509/08/195531dviyxgoy0yiwogyo.jpg[/img]
因此只能用 strace 命令找出 ps -ef 进程卡在那里。命令是 strace -o strace_psef.log –f ps –ef
图 6：通过 strace 命令找出命令执行中对系统的调用和收到的信号等信息
[img]http://img.linuxidc.com/attachments/forum/201509/08/195531il82jqqmf5jzlzj2.jpg[/img]
通过上图可以发现到 open 文件 /proc/24602/cmdline 时遇到了停止（等待），通过 cat /proc/24602/cmdline 文件发现也无法正确执行，也会卡死。中间发现像 netstat，ps -p 24602 –o cmd 这种命令都无法使用，甚至 ps -p 1 –o cmd 都无法显示，由于这些命令都是使用 /proc 目录下的文件的，因此 /proc 目录存在问题的可能性非常大，因此继续找原因，继续 top -p 24602 找出这个进程名称（发现除了 top 可用以外，pstree 同样也是可用的）。
图 7.1：ps -p 24602 –o cmd
[img]http://img.linuxidc.com/attachments/forum/201509/08/195531obeyr9o96o5r3dkg.jpg[/img]
图 7.2：ps -p 1 –o cmd 都无法显示
[img]http://img.linuxidc.com/attachments/forum/201509/08/195531p2dczqu1iucot83l.jpg[/img]
7 秒前 上传下载附件 (24.96 KB)
图 7.3：附加的疑问，pts 数值无法还原至 0,
[img]http://img.linuxidc.com/attachments/forum/201509/08/195532drzt8tr8p4rg4mvq.jpg[/img]
通过 top -p 24602 命令发现这个 pid 为 14602 的进程也是 D 状态的
图 8：通过 top -p 24602 找出这个进程名称
[img]http://img.linuxidc.com/attachments/forum/201509/08/195532ed3k04onsaffrq4f.jpg[/img]
但是发现 top 中不能使用 c 命令查看这个进程的命令行，因此只能进入 /proc 目录看看有没有人品能看到该进程使用的一些 fd（文件描述符，file descriptor），结果发现人品不错，通过 cp 复制出来的 /proc/24602 中找到了 task 目录下的 fd，如下图所示：
图 9：通过 fd 找到这个进程属于哪一个应用里面的
[img]http://img.linuxidc.com/attachments/forum/201509/08/195532n5muzonzyy4ywng6.jpg[/img]
发现出问题的这个应用程序就是前天同事问我的那个，也是研发人员说存在问题的那个应用。经过昨天晚上的重启后发现，此进程的内存占用率依然很高，初步判断是程序的问题，当然也要检查一下 IO 问题，但是 Ubuntu 这个系统比较奇怪，系统日志中对此没有任何可用的信息，而 java 程序中产生的日志太多、信息太杂还是让更专业的开发人员去查吧。
到现在，问题的始作俑者算是找到了，但是为什么是由于 IO 问题导致还没找到原因，从上午开始写此文到现在，写此文之前已经告诉有关研发人员去分析代码去了，现在去问了下，初步定位在程序内部有一个模块存在死循环（不断的查询远端数据库）导致的，具体怎么改和深入测试还需要一些时间。
图 10.1：昨天晚上该程序（图中 pid 为 2988）的内存占用为 1.4GB 左右，符合常理，但今早上就 11GB 了（截图之前有过 13GB、12GB 的记录）
[img]http://img.linuxidc.com/attachments/forum/201509/08/195533nes0hmy6ed6fozsm.jpg[/img]
图 10.2：最新截图，又 13GB 了。
[img]http://img.linuxidc.com/attachments/forum/201509/08/195533du7k5c78u678ib37.jpg[/img]
图 11：问题处理的总体思路如下图所示：
通过此次事件，总结经验如下：
1. 通过 fd 判断进程的 cmd，除此之外，top -c，pstree -a，ps -ef 等
2. 通过 strace 命令分析进程在哪里等待
3. 了解进程的 D 状态
tag:strace 命令用法, 进程状态 D,Linux 进程分析,Linux 进程调试,strace 调试程序
–end–
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2015-09/122801.htm
