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

今天查看数据库负载没有发现问题,但是当我使用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

伟人之所以伟大,是因为他与别人共处逆境时,

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

相关文章:

你感兴趣的文章:

标签云: