crontab导致CPU异常的问题分析及处理

简介: 今天查看数据库负载没有发现问题,但是当我使用top命令的时候,发现有一个进程占用了大量的cpu资源而且已经执行很长时间了。这一下子引起了我的注意。   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TI...
今天查看数据库负载没有发现问题,但是当我使用top命令的时候,发现有一个进程占用了大量的cpu资源而且已经执行很长时间了。这一下子引起了我的注意。
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
25807 oraccbs1  25   0  8728  732  564 R 100.0  0.0   2021:19 /bin/sh -c /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log 
13578 oraccbs1  18   0 40.2g  49m  29m D 61.0  0.0   6:40.18 oraclePRODB (LOCAL=NO)
17085 oraccbs1  18   0 40.2g  48m  24m R 40.6  0.0  36:44.43 oraclePRODB (LOCAL=NO)
30894 oraccbs1  18   0 40.3g  56m  27m D 38.1  0.0  54:40.46 oraclePRODB (LOCAL=NO) 
10616 oraccbs1  18   0 40.3g  54m  24m R 36.8  0.0  28:15.49 oraclePRODB (LOCAL=NO)
17089 oraccbs1  18   0 40.2g  49m  25m R 36.8  0.0  60:11.90 oraclePRODB (LOCAL=NO)
12103 oraccbs1  18   0 40.2g  31m  22m R 35.6  0.0 149:38.06 oraclePRODB (LOCAL=NO)
30898 oraccbs1  18   0 40.2g  50m  32m D 35.6  0.0  56:03.90 oraclePRODB (LOCAL=NO)

对于这个脚本我比较陌生,一般这些维护性的工作主要都是客户来做的。尝试查看了下这个脚本的内容,发现是一个检测脚本,
脚本的内容很清晰,是来监控归档目录和home目录的空间使用情况,当超过阀值的时候,就发送短信给响应的人来处理。
内容大体如下:
#Send Short Message  if %used greater than 80% : ARCHIVE
        PERC_ARCH_USED=`df -P ${ARCH_PATH}|awk '{ print $5 }'|grep "%"|tr -d "%"`
        export casename=`uname -n`_${database}_Percent_Archive_Used_IS_${PERC_ARCH_USED}
        if [[ $PERC_ARCH_USED -gt 80 ]]; then
        sqlplus -s xxxxx @$myDir/Sql/sendsms.sql $casename
        fi


#Send Short Message  if %used greater than 80% : $ORACLE_HOME
        PERC_HOME_USED=`df -P ${HOME_PATH}|awk '{ print $5 }'|grep "%"|tr -d "%"`
        export casename=`uname -n`_${database}_Percent_HOME_Used_IS_${PERC_HOME_USED}
        if [[ $PERC_HOME_USED -gt 80 ]]; then
        sqlplus -s xxxxxx @$myDir/Sql/sendsms.sql $casename
        fi

这样一个脚本的执行肯定执行一次就完了。它是从哪里执行的呢,首先想到的就是crontab。
crontab是在系统级作为作业自动执行的利器,可以进行各种细粒度的配置,使用也很方面。
先来查看一下crontab的情况,结果在crontab的最后发现一个配置就是正在执行的job.
> crontab -l
#------------------------------------------------
# Test Log DB for house keeping .....
#------------------------------------------------
#0,30 * * * *  /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log  
这样来看似乎问题找到了原因,但是奇怪的是根据crontab里面的设置,这个job已经被禁用了,怎么还在运行?
毕竟这个问题还不能完全肯定是操作问题还是其他的原因导致的,就先不轻率的决定,把问题分给客户,从我的角度来说,怎么才能得到一些信息来说明这个问题才是关键。
首先是crontab的执行频率问题。如果没有接触过crontab可能会有些陌生。
crontab命令包含6个参数,命令的一些基本说明如下:

*      *   *   *   *  command
  分   时  日  月  周   命令

  第1列表示分钟1~59 每分钟用*或者 */1表示
  第2列表示小时1~23(0表示0点)
  第3列表示日期1~31
  第4列表示月份1~12
  第5列标识号星期0~6(0表示星期天)
  第6列要运行的命令

在这个例子中。0,30是第一个参数,就代表每个小时的0分,30分执行一次下面的脚本。
0,30 * * * *  /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log
如果要求脚本在指定的时间段,比如只在5分,20分,30分的时候执行,
5,20,30 * * * *  /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log
如果要求脚本在指定的时间段,比如只在每天晚上的11:30执行,就可以写成下面的形式。
30 23 * * *  /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log

从配置来看,job是每隔半个小时执行一次,而且所做的检查工作也不复杂,执行时间应该会很短。配置中这个job已经被禁用,如果我们能够证明这个job是通过crontab执行的就能够说明是操作问题。因为crontab里面已经禁用,但是实际上job还在运行。
通过进程的信息,我们知道这个进程已经执行了近2021分钟,我们来推算一下执行的时间。2021/60=33个小时,从下午3点往前推33个小时,就是在29号早晨的7点左右开始执行的。
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                       
25807 oraccbs1  25   0  8728  732  564 R  100.0   0.0    2021:19   /bin/sh -c /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log  

这个时候日志就是最好的证明工具,可以在/var/spool/mail/oraccbs1下面找到相应的日志。
日志中最近的一次执行时间是在昨天的早晨7:30,之后就没有任何相关的日志了。
Mon Dec 29 07:30:01 2014
Return-Path:
Received: from localhost.localdomain (xxxxx[127.0.0.1])
        by localhost.localdomain (8.13.8/8.13.8) with ESMTP id sBT0U1mr013412
        for ; Mon, 29 Dec 2014 07:30:01 +0700
Received: (from oraccbs1@localhost)
        by localhost.localdomain (8.13.8/8.13.8/Submit) id sBT0U1Jh013347;
        Mon, 29 Dec 2014 07:30:01 +0700
Date: Mon, 29 Dec 2014 07:30:01 +0700
Message-Id:
From: root@localhost.localdomain (Cron Daemon)
To: oraccbs1@localhost.localdomain
Subject: Cron   /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated

/bin/sh: fork: Resource temporarily unavailable

From oraccbs1@localhost.localdomain  Mon Dec 29 07:30:05 2014
。。。。
得到了这些基本信息,就能够基本确定问题了。
至于crontab的修改,可以使用crontab -e来完成。感觉就跟vi操作一样。客户做了确认之后,手工kill掉了那个job,那个问题就解决了。
有很多朋友反馈说为什么会导致CPU异常,因为问题已经修复了,我就从支离破碎的日志中做了简单的分析。
可以通过上面的日志看到 fork: Resource temporarily unavailable 这个问题,说明在执行crontab job的时候发生了问题,这个问题可能是数据库中其它的资源消耗导致的,也可能是发送消息的环节导致的,因为发送消息的细节是客户来维护,他们不愿意透露更多的细节,我们只能做主观上的猜测了。
不过通过下面的日志能够得到一些信息。就是crontab的job很可能是个僵尸进程。存在两个相同的进程。
>ps -ef|grep DailyChk

oraccbs1 14187  7786  0 14:59 pts/10   00:00:00 grep DailyChk

oraccbs1 25793     1  0 Dec29 ?        00:00:00 /bin/sh -c /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log

oraccbs1 25807 25793 99 Dec29 ?        1-09:58:51 /bin/sh -c /opt/app/oracle/xxxxxx/Script/DailyChk/chk_path_full.ksh PRODB 2>&1 >/opt/app/oracle/Script/DailyLog/chk_path_full.log

最后从昨天的top截图中发现了如下的内容,可以基本断定问题是crontab 的那个job成为了僵尸进程导致的。
Tasks: 7196 total,  26 running, 7165 sleeping,   0 stopped,   5 zombie
Cpu(s):  7.8%us,  1.5%sy,  0.0%ni, 90.1%id,  0.1%wa,  0.1%hi,  0.4%si,  0.0%st
Mem:  363033360k total, 116349772k used, 246683588k free,  2176616k buffers

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
12月前
|
SQL 弹性计算 监控
实例底层ECS的CPU异常
由于实例底层ECS的CPU异常,数据库实例个别节点会在某个时间段内CPU突然飙升,导致部分业务SQL执行出现超时问题如何处理
|
Java Linux
Java服务CPU100%异常排查实践总结
写作目的 最近看牛客网发现了CPU 100% 怎么办这个问题,这个问题的重点是定位和解决,会用到Linux和java的的很多命令,所以写篇博客记录和总结一下。
138 0
Java服务CPU100%异常排查实践总结
CPU异常定位手段
节点服务CPU使用异常,导致CPU资源使用紧张,可以使用top和pstack定位异常代码问题
187 0
|
Java 数据安全/隐私保护 测试技术
我修复的印象最深的一个bug,一个导致CPU和内存异常到无法响应的BUG
系统上线一段时间后,客户反映接口响应特别慢,甚至没有响应,第一时间依次检查了网络、服务器资源使用情况,发现服务器CPU和内存占用率都非常的高,经过一阵紧张的排查,最终发现问题出现的根源,这就是我修复的印象最深的一个bug就是由于String的用法不当所造成的。
422 0
我修复的印象最深的一个bug,一个导致CPU和内存异常到无法响应的BUG
|
存储 弹性计算 运维
SLS新版告警入门-监控主机CPU异常
随着用户量的增加,后台服务经常需要部署在多台服务器或者集群中来提高性能和增强可用性,在提供服务的过程中,由于程序bug或者业务徒增导致CPU飙高,如果CPU持续飙高,可能会导致机器down机,对服务造成不可用。 本文以此为背景,在主机监控时序数据中,配置SLS告警,来监控主机CPU飙高,并且在CPU飙高时发出告警到钉钉机器人。
540 0
|
存储 弹性计算 编解码
某接口cpu使用率异常排查记录
1. 问题现象: 某项目跑在 p01~02 2台ECS上,主要用途是聚合服务,给H5页面提供直接访问的接口。最近版本新增加了接口 wechat/mp/qrcode,用途是根据请求参数生成小程序二维码,以swoole+lumen方式对外服务接口上线后,cpu使用率逐步上升,直至100%;同时请求响应时长也逐步攀升 上图是问题期间p01cpu使用率,几个下降过程是因为上线(会重启服务进程)或者手动重启服务进程;后面发现p01 p02cpu基本打满,临时加了 p03 p04 2台ecs以降低问题的影响。
1489 0
|
MySQL 关系型数据库 数据库
|
MySQL 关系型数据库 RDS
RDS for MySQL CPU 性能问题分析
RDS for MySQL CPU 性能问题分析 RDS for MySQL CPU 使用率高是使用 RDS for MySQL 实例过程中比较常见的一类性能问题。 由于实例 CPU 资源打满会直接导致业务受损,且问题发生过程迅速、临界时间短 统计采集困难、问题发生后统计指标呈反向曲线,加之日常运维过程中问题征兆容易被忽视,非常容易导致用户体感问题突然性强烈,因此在这里我们对 RDS for MySQL 的 CPU 使用率高的原因做一个比较详细的分析说明。
2225 0