linux 高cpu 分析

1.1查看CPU占用值

通常发生该类故障的时候,会反映在用户响应时间长,weblogic服务器运行速度异常缓慢,请求或者操作出现超时等。在接到故障通知后,登陆问题机器,执行查看进程命令:
ps –ef | grep java

在这里我们要根据具体的告警内容来选出需要查看的进程:
sxydfw 9391 9342 99 20:10 pts/1 01:00:22 /app/wls10/jdk1.6.0_45/bin/java -server -Xms1536m -Xmx1536m -XX:PermSize=128m -XX:MaxPermSize=256m -Dweblogic.Name=ydfwServer2 -Djava.security.policy=/app/wls10/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.policy -Dweblogic.ProductionModeEnabled=true -Dweblogic.security.SSL.trustedCAKeyStore=/app/wls10/Oracle/Middleware/wlserver_10.3/server/lib/cacerts -Dport=7001 -DappName=sxydfw_ydfwServer2 -da -Dplatform.home=/app/wls10/Oracle/Middleware/wlserver_10.3 -Dwls.home=/app/wls10/Oracle/Middleware/wlserver_10.3/server -Dweblogic.home=/app/wls10/Oracle/Middleware/wlserver_10.3/server -Dweblogic.management.discover=false -Dweblogic.management.server=t3://10.190.118.154:37001 -Dfile.encoding=GBK -Dwlw.iterativeDev=false -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=false -Dweblogic.ext.dirs=/app/wls10/Oracle/Middleware/patch_wls1035/profiles/default/sysext_manifest_classpath:/app/wls10/Oracle/Middleware/patch_ocp360/profiles/default/sysext_manifest_classpath weblogic.Server

1.2 获取进程号
从进程信息中能获知该进程的PID为9391,是由应用账号sxydfw启动的。接下来我们要具体看一下该进程对CPU的具体占用情况:
执行查看该进程CPU占用情况的命令:

top -Hp 9391 -d 1 -n 1

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9509 sxydfw 25 0 2213m 815m 29m R 59.7 10.4 6:57.44 java
9422 sxydfw 25 0 2213m 815m 29m R 57.7 10.4 7:12.52 java
10017 sxydfw 19 0 2213m 815m 29m R 41.8 10.4 5:26.36 java
9507 sxydfw 19 0 2213m 815m 29m R 39.8 10.4 7:26.53 java
9508 sxydfw 25 0 2213m 815m 29m R 39.8 10.4 9:11.57 java
9632 sxydfw 19 0 2213m 815m 29m R 39.8 10.4 3:03.78 java
10116 sxydfw 25 0 2213m 815m 29m R 39.8 10.4 1:44.88 java
10010 sxydfw 19 0 2213m 815m 29m R 31.8 10.4 4:28.82 java
10014 sxydfw 25 0 2213m 815m 29m R 25.8 10.4 3:04.17 java
9419 sxydfw 25 0 2213m 815m 29m R 19.9 10.4 12:03.31 java

该命令可以间隔5秒中左右重复执行几次,重复收集信息来确定占用线程。从上面的截图能看到,排在前面的就是占用CPU高的线程信息。其中线程9509和9422的均占CPU超过百分之五十以上,我们要具体分析这两个线程。

2.1 监控日志

现在生产环境中的weblogic进程均是nohup标准启停脚本来启动的,所以现在进入该问题server的nohup日志目录,用tail –f 命令在后台监控日志的情况。
本次实例中的后台日志为/applog/sxydfwlog下nohup_start_ydfwServer2_XXXX.log,故执行命令:

tail –f nohup_start_ydfwServer2_XXXX.log

通知当日值班的应用支持组的老师,请他用应用账号在后台执行kill -3 进程号 操作,注意要每隔15秒执行一次,执行3次。
本次实例中取进程号进行操作:

Kill -3 9391

此时在监控的日志nohup_start_ydfwServer2_XXXX.log中就会出现关于该进程的Thread Dump信息,然后将之前取得的两个线程号由十进制转换为十六进制,在threaddump信息中查找对应的内容:

9509 -> 2525:

"[ACTIVE] ExecuteThread: ‘4‘ for queue: ‘weblogic.kernel.Default (self-tuning)‘" daemon prio=10 tid=0x00002aaab4ebb000 nid=0x2525 ru
nnable [0x00000000442a8000]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.writeBytes(Native Method)
at java.io.RandomAccessFile.write(RandomAccessFile.java:482)
at.com.portal.struts.action.common.UpLoadFileServlet.mergeFile(UpLoadFileServlet.java:224)
at com.portal.struts.action.common.UpLoadFileServlet.doPost(UpLoadFileServlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at com.portal.filter.EncodeFilter.doFilter(EncodeFilter.java:48)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)

9422- > 24ce:
"[ACTIVE] ExecuteThread: ‘1‘ for queue: ‘weblogic.kernel.Default (self-tuning)‘" daemon prio=10 tid=0x00002aaab4bfb800 nid=0x24ce ru
nnable [0x0000000042389000]
java.lang.Thread.State: RUNNABLE
at java.io.RandomAccessFile.writeBytes(Native Method)
at java.io.RandomAccessFile.write(RandomAccessFile.java:482)
at com.portal.struts.action.common.UpLoadFileServlet.mergeFile(UpLoadFileServlet.java:224)
at com.portal.struts.action.common.UpLoadFileServlet.doPost(UpLoadFileServlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at com.portal.filter.EncodeFilter.doFilter(EncodeFilter.java:48)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)

分析上述信息,检查是什么原因引起的CPU高利用率。本次事例中是执行到某个函数时造成了故障,故需要联系开发组老师重点排查标亮部分的方法调用情况。如果weblogic自身的问题,则可以联系BEA客服支持。

时间: 2024-08-28 09:57:47

linux 高cpu 分析的相关文章

jstack来分析。当linux出现cpu被java程序消耗过高时

我们使用jdk自带的jstack来分析.当linux出现cpu被java程序消耗过高时,以下过程说不定可以帮上你的忙: 1.top查找出哪个进程消耗的cpu高 21125 co_ad2    18   0 1817m 776m 9712 S  3.3  4.9  12:03.24 java                                                                                           5284 co_ad    

Linux 线程占用CPU过高定位分析

今天朋友问我一个Linux程序CPU占用涨停了,该如何分析, CPU占用过高,模拟CPU占用过高的情况 先上一段代码: 1 #include <iostream> 2 #include <thread> 3 #include <vector> 4 5 6 int main(int argc, char **argv) { 7 8 std::vector<std::thread> test_threads; 9 for(int i = 0; i < 9;

Linux下如何查看高CPU占用率线程 LINUX CPU利用率计算

目录(?)[-] proc文件系统 proccpuinfo文件 procstat文件 procpidstat文件 procpidtasktidstat文件 系统中有关进程cpu使用率的常用命令 ps 命令 top命令 单核情况下Cpu使用率的计算 基本思想 总的Cpu使用率计算 计算方法 某一进程Cpu使用率的计算 计算方法 实验数据 某一线程Cpu使用率的计算 计算方法 实验数据 多核情况下cpu使用率的计算 实验一 描述 数据一 数据二 实验二 描述 数据一 数据二 主要问题 Java 系统

云服务器 ECS Linux 系统 CPU 占用率较高问题排查思路

https://help.aliyun.com/knowledge_detail/41225.html?spm=5176.7841174.2.2.ifP9Sc 注意:本文相关配置及说明已在 CentOS 6.5 64 位操作系统中进行过测试.其它类型及版本操作系统配置可能有所差异,具体情况请参阅相应操作系统官方文档. 如果云服务器 ECS Linux 系统的 CPU 持续跑高,则会对系统稳定性和业务运行造成影响.本文对 CPU 占用率较高问题的排查分析做简要说明. CPU 负载查看方法 使用 v

通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码

http://heylinux.com/archives/1085.html通过 thread dump 分析找到高CPU耗用与内存溢出的Java代码 首先,要感谢我的好朋友 钊花 的经验分享. 相信大家在实际的工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况. 通常这种情况发生时,我们会认为这些问题理所当然的该由开发人员自己去解决,因为操作系统环境是没有任何问题的. 但实际上,我们是可以帮助他们的,效果好的话还可以定位到具体出问题的代码行数,思路如下: 1.通过对CPU与内存的

linux概念之cpu分析

http://ilinuxkernel.com/?cat=4 Linux CPU占用率原理与精确度分析1  CPU占用率计算原理在Linux/Unix 下,CPU 利用率分为用户态.系统态和空闲态,分别表示CPU 处于用户态执行的时间,系统内核执行的时间,和空闲系统进程执行的时间. 下面是top显示的值1.1%us,  1.6%sy,  0.0%ni, 97.2%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st      us: User time         用

嵌入式 如何定位死循环或高CPU使用率(linux)

如何定位死循环或高CPU使用率(linux) 确定是CPU过高 使用top观察是否存在CPU使用率过高现象 找出线程 对CPU使用率过高的进程的所有线程进行排序 ps H -e -o pid,tid,pcpu,cmd --sort=pcpu |grep xxx 得到如下结果,其中线程2909使用了7.8%的CPU. 2907 2913 0.0 ./xxx 2907 2909 7.8 ./xxx 也可以通过查看/proc中的信息来确定高CPU线程. 打印了4列,线程ID,线程名,用户时间和内核时间

MYSQL数据库服务CPU高问题分析与优化

MySQL服务性能监控分析与优化是永恒的主题,做为性能测试人员有时也要站在DBA角度出发进行适当分析与优化,这也是性能测试人员能长期生存发展之路.而资源的使用监控分析才是性能故障分析的根本首要任务.在数据库服务器内部,如果执行的操作会严重受到内存.CPU或磁盘吞吐量中任何一个的影响,则可以将它视为瓶颈. 因此理解服务器如何运行,资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的活动,具体案例如下. 这些监控分析优化方法等细节我们在品课学院性能实战课堂中都会以实战方式进行实操性测试监控分析实

sqlserver 索引优化 CPU占用过高 执行分析 服务器检查

原文:sqlserver 索引优化 CPU占用过高 执行分析 服务器检查 1. 管理公司一台服务器,上面放的东西挺多的.有一天有个哥们告诉我现在程序卡的厉害.我给他说,是时候读点优化的书了.别一天到晚没个正形,现在写的程序卡的跑不动.他说我本地 是好好的,跑的很快.我说别扯那么多没用的,服务器不比你的本子强得多.待洒家上去看看.不看不知道一看吓一跳,CPU占用在95上下.开个程序是不卡,可整点有些时间是卡的一匹.这就令人很难受了. 本来服务器上也没有什么,就一个网站和几个数据库.那一个个分析吧,