ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ulimit限制导致的 +++ killed by SIGKILL +++

ulimit限制导致的 +++ killed by SIGKILL +++

原创 Linux操作系统 作者:westzq1984 时间:2013-11-14 16:12:40 0 删除 编辑
昨天和同事解决了一个案例,主要是同事解决的,我只是提了些建议。

一套系统的监听,不定时的宕掉,是直接就不见了。
最后确定为ulimit中,限制了进程使用的CPU时间数,超过限制值,系统就会粗暴的直接使用kill -9将进程给干掉

模拟下,在/etc/security/limits.conf中设置
  oracle soft cpu 1
  oracle hard cpu 1

进行ORACLE用户后查看ulimit值,CPU时间已经被限定到60s
[oracle@zhangqiaoc ~]$ ulimit -t
60

编写一个脚本不停的连接数据库
while ((1<2))              
do
 sqlplus -s ctais2/oracle@o11203 @exit.sql
done

同时使用strace跟踪监听
strace -fo /tmp/strace.out -p 19882

发现监听接收到SIGKILL信号被杀掉。多次测试均一致
19884 +++ killed by SIGKILL +++
19883 +++ killed by SIGKILL +++
19882 +++ killed by SIGKILL +++

然后模拟对监听执行kill -9 ,查看strace的输出,一致
5085  +++ killed by SIGKILL +++
5086  +++ killed by SIGKILL +++
5084  +++ killed by SIGKILL +++

只说明,监听是被kill掉的,那么是何进程kill的监听?
通过 .bash_history  检查,不会发现任何异常命令

strace.out也无法找到更多的信息
但是这个情况,给人的感觉就是监听使用资源到达一定程度,被杀掉了

GOOGLE一下LIMIT的资源限制,可以看到基本都降到ulimit,其中对于CPU限制:
  最大允许的CPU使用时间,秒为单位。当进程达到软限制,内核将给其发送SIGXCPU信号,这一信号的默认行为是终止进程的执行。
  然而,可以捕捉信号,处理句柄可将控制返回给主程序。如果进程继续耗费CPU时间,核心会以每秒一次的频率给其发送SIGXCPU信号,直到达到硬限制,
  那时将给进程发送 SIGKILL信号终止其执行。
 
在LINUX上,可以使用stap捕获sigkill信号,获得是被何进程kill的
$ cat sigkill.stp
probe signal.send{
  if(sig_name == "SIGKILL")
    printf("%s was sent to %s (pid:%d) by %s uid :%d\n", sig_name, pid_name , sig_pid, execname(), uid())
}
 
$ sudo stap sigkill.stp
SIGKILL was sent to a.out (pid:23700) by a.out uid :50920

在Solaris上,理论上可以使用dtrace来捕获sigkill信号

从linux的源代码中可以看到,超过硬CPU限制就是简单粗暴的让进程被自杀了
参考 http://blog.csdn.net/bingqingsuimeng/article/details/8599668

但是这个案例很奇怪,对于lgwr,dbwr这种进程,竟然没有被自杀,看来是有人在数据库启动后,才做了这样的更改

如何查看进程当前限制值,只知道LINUX,其他平台未知
[oracle@zhangqiaoc ~]$ cat /proc/7455/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              60                   60                   seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             16384                16384                processes
Max open files            65536                65536                files     
Max locked memory         5368832000           5368832000           bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       73728                73728                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    

启示:
对于稀奇古怪的问题,一般需要先做的检查:
1.安装配置,特别的limit,还有hpux下的/etc/privgroup文件
2.使用raccheck,RDA等工具检查系统
3.strace等工具跟踪
4.还要考虑使用ps -elf / ps vg 一直跟踪进程的资源消耗情况


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8242091/viewspace-776610/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-04-06

  • 博文量
    251
  • 访问量
    953260