oracle真实案例之oem大量占用cpu与内存问题的解决方法

没有见过这样高的负载，以前见过最多的就是负责1000多，java的问题内存：

连交换内存都使用完了，物理内存就剩下71m了，太危险了top：

发现了6个僵尸进程与大量的perl进行现在查看一下僵尸进程

发现都是[sh] <defunct>进程，以前遇到过这样的问题，都是由于cron里启动脚本的时候，没有加入错误输入到空设备里导致，解决方法是在cron里运行脚本后，添加>>/dev/null 2>&1，查看一下cron，查看是否与我的想法一致

果然是没有错误的输出，添加完>>/dev/null 2>&1在重启cron服务器就解决了在查看perl进程

发现2726个进程，占用了大量的cpu与内存去metalink里查看，发现这个问题是oem的故障导致，oracle给的问题的描述与解决方法为：

还是2726个，没有变化内存
55m空闲下面我们杀掉perl进程，使用 kill -9 $(ps -ef|grep perl|grep -v grep|awk '{print $2}')
?
然后在查看perl进程
现在perl进程没有了查看一下内存
现在内存已经有6673m了，恢复正常查看一下负载
现在负载变为正常了，负载这1分钟的为3.15,5分钟的为242.76,15分钟的为1236.57，虽然负载为3，但我的服务器内为16核，所有负载为3没有问题服务器cpu核数
现在问题解决了，如果想开启oem监控oracle的话，在oracle用户下使用emctl start dbconsole就可以。提示：很多数据库的故障，在解决的时候，我建议大家还是先确定问题是如何产生的，找到解决问题的思路与方法，如果有metalink账号的话，最好登陆里面搜索问题产生的原因与解决方法，不太建议在百度或者谷歌里搜索问题解决方法，因为很多问题在百度或者谷歌里搜索的答案不一定准确或者适合你，如果你的生产库出现了问题，你按照百度或者故障里的解决方法解决，同时你也不明白问题的产生原因与解决的思路、办法的话，那么你只能拼运气来解决问题，解决了还好，皆大欢喜，如果没有解决甚至产生更坏的影响的话，估计你离走人不远了。
本文出自 “吟—技术交流” 博客，请务必保留此出处http://dl528888.blog.51cto.com/2382721/911535