中午11点半收到短信报警,web服务器cpu利用率较高。
是java进程占用的,内部系统访问量很少(300不到)因此服务器出现高的cpu利用率很不正常,日志方面并没太多错误记录,杀掉重启过一会cpu利用率又飙升了,能达到500%
像是陷入某种死循环,有人提到在git上面看到最近新加的一段代码是个不严谨的循环语句,于是搜找那段语句,是个删除文件的语句,类似如:
if (file.exist()) while (file.delete()) xxx xxx fi
应该是它了,那么为何无法删除呢?
文件不存在,但代码判断过了,
权限问题,如果账号没权限的话,那就会陷入这个死循环中。
再联想——一周前调试的时候用root启动的tomcat,后来自动部署的时候脚本未能杀掉原有进程,只是再开了个新的,于是就出现了两个tomcat,其中一个以root身份运行过且调用过对应的文件,于是即使后来root的那个进程被杀掉,也产生了实质的影响——其身份运行的进程占用的文件目录权限产生变动。(变成了root),所以别的账号无法删除,进而陷入死循环。
解决:
1.更改代码
2.改回相关文件目录的原有属性
两个坑:
代码的死循环不够严谨
坚决不应该以root身份启动有固定用户的进程(属于误操作,应谨慎)
其他思路:
1.查日志,其实能看到很多删除失败的记录,这个应该留意,才能更好找到原因
2.利用jstat分析jvm状态 , jstat -gcutil pid(vmid) 间隔(毫秒) 次数,如:
[root@service ~]# jstat -gcutil 14503 1000 4 S0 S1 E O P YGC YGCT FGC FGCT GCT 43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129 43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129 43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129 43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
这个反映的是gc统计信息,详情参考jstat的使用。
本文出自 “运维故事” 博客,谢绝转载!
原文地址:http://opstory.blog.51cto.com/2097255/1530490