一次Linux系统1分钟负载5000+的故障排错

昨天上午查看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短信网关发送短信报警）：

图2：Zabbix上触发器的报警条件

接着不久，就不断有同事反映该服务器响应很是慢，有些应用页面打开好久才出来。因为机房远在天边并且没有远程登陆控制台的登陆信息（这些信息在客户处），所以只能用xshell经过SSH登陆到Linux系统，打开top命令看看系统运行状况，发现当前系统内已经有5800多个进程在运行，其中系统负载（一、五、15分钟）都达到了5400+，但奇怪的是CPU、内存和硬盘IO都并不高，按照常理，如此高的系统负载，CPU和IO等早已经应该是消耗殆尽了，但top显示并无。

图3.1: Linux系统中的top信息

图3.2 经过iostat、vmstat等命令发现磁盘IO并不高，但系统负载却很高

有个开发人员说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

以前有同事电话问我系统中有个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用户参数命令行：

所以只能用strace命令找出ps -ef进程卡在那里。命令是strace -o strace_psef.log –f ps –ef

图6：经过strace命令找出命令执行中对系统的调用和收到的信号等信息

经过上图能够发现到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

图7.2：ps -p 1 –o cmd都没法显示

 

图7.3：附加的疑问，pts数值没法还原至0,

经过top -p 24602命令发现这个pid为14602的进程也是D状态的

图8：经过top -p 24602找出这个进程名称

可是发现top中不能使用c命令查看这个进程的命令行，所以只能进入/proc 目录看看有没有人品能看到该进程使用的一些fd（文件描述符，file descriptor），结果发现人品不错，经过cp复制出来的/proc/24602中找到了task目录下的fd，以下图所示：

图9：经过fd找到这个进程属于哪个应用里面的

发现出问题的这个应用程序就是前天同事问个人那个，也是研发人员说存在问题的那个应用。通过昨天晚上的重启后发现，此进程的内存占用率依然很高，初步判断是程序的问题，固然也要检查一下IO问题，可是Ubuntu这个系统比较奇怪，系统日志中对此没有任何可用的信息，而java程序中产生的日志太多、信息太杂仍是让更专业的开发人员去查吧。

到如今，问题的始做俑者算是找到了，可是为何是因为IO问题致使还没找到缘由，从上午开始写此文到如今，写此文以前已经告诉有关研发人员去分析代码去了，如今去问了下，初步定位在程序内部有一个模块存在死循环（不断的查询远端数据库）致使的，具体怎么改和深刻测试还须要一些时间。

图10.1：昨天晚上该程序（图中pid为2988）的内存占用为1.4GB左右，符合常理，但今早上就11GB了（截图以前有过13GB、12GB的记录）

 

图10.2：最新截图，又13GB了。

图11：问题处理的整体思路以下图所示：

经过这次事件，总结经验以下：

1.经过fd判断进程的cmd，除此以外，top -c，pstree -a，ps -ef等

2.经过strace命令分析进程在哪里等待

3.了解进程的D状态

tag:strace命令用法,进程状态D,Linux进程分析,Linux进程调试,strace调试程序

--end--