system进程占用磁盘高 [Java进程占用CPU高怎么解决]

1、system进程占用磁盘高 java进程占用cpu高怎么解决 java进程占用cpu高怎么办?跟着一起学习java进程占用cpu高的解决方法吧。 java进程占用cpu高的解决方法 故障分析 在故障发生时，weblogic的被管服务器mserver2的gc日志出现连续full gc现象，如下所示： 68354.936: full gc 68354.936: tenured: 1441791k-1441791k(1441792k), 50.8704538 secs 1823487k-1793402k(1823488k), perm : 122693k-122655k(131072k), 50.8

2、707784 secs 68406.966: full gc 68406.966: tenured: 1441791k-1441791k(1441792k), 43.3959313 secs 1823487k-1795107k(1823488k), perm : 122691k-122691k(131072k), 43.3962451 secs 68452.057: full gc 68452.057: tenured: 1441791k-1441791k(1441792k), 43.8102222 secs 1823487k-1793985k(1823488k), perm : 122692

3、k-122692k(131072k), 43.8105214 secs 68497.417: full gc 68497.417: tenured: 1441791k-1441791k(1441792k), 44.0541711 secs 1823487k-1791516k(1823488k), perm : 122692k-122692k(131072k), 44.0545032 secs 68542.904: full gc 68542.904: tenured: 1441791k-1441791k(1441792k), 51.2142139 secs 1823478k-1792950k(

4、1823488k), perm : 122709k-122681k(131072k), 51.2145271 secs 由此，推断有大量对象占用了jvm的内存，并且在gc后没有释放。 同时，实例的输出日志中，发觉有session复制现象，如下所示： 这说明，weblogic的被管服务器mserver2在向mserver1复制会话。 由于mserver1无法处理两个被管服务器的业务，很快也访问缓慢了。 之后，重启了weblogic的2个实例，系统复原正常。 在接下来的系统监控中，发觉weblogic其中一个实例的java进程的cpu用法率依旧特别高，针对这一现象，我们dump出cpu的用法状况，

5、发觉有些java线程用法cpu资源较高，且占用时间较长，如下所示： pid username size rss state pri nice time cpu process/lwpid 27662 cncbss 2225m 1631m cpu10 0 10 0:22.46 22% java/73 27662 cncbss 2225m 1631m cpu9 0 10 0:20.31 22% java/72 27662 cncbss 2225m 1631m run 0 10 0:22.12 22% java/75 经过多次dump cpu用法状况，这三个线程仍旧存在。 此后dump weblog

6、ic的线程，发觉是如下线程导致高消耗cpu： executethread: 51 for queue: weblogic.kernel.default daemon prio=5 tid=0x00ef7008 nid=0x4a runnable 0x79480000.0x79482021 at java.util.vector.indexof(vector.java:363) - waiting to lock 0xa21b73f8 (a java.util.vector) at java.util.vector.contains(vector.java:321) at cnc.util.fy

7、col.add(fycol.java:204) at cnc.util.fycol.add(fycol.java:194) at cnc.util.recordset.(recordset.java:199) at cnc.util.recordset.(recordset.java:93) at cnc.util.fydao.query(fydao.java:264) at cnc.util.fydao.query(fydao.java:234) at listquery.listquerybean.getfreelist(listquerybean.java:404) at listque

8、ry.listquery_gq76y8_eoimpl.getfreelist(listquery_gq76y8_eoimpl.java:98) at listquery.listquery_gq76y8_eoimpl_wlskel.invoke(unknown source) at ernal.serverrequest.sendreceive(serverrequest.java:166) at weblogic.rmi.cluster.replicaawareremoteref.invoke(replicaawareremoteref.java:290) a

9、t weblogic.rmi.cluster.replicaawareremoteref.invoke(replicaawareremoteref.java:248) at listquery.listquery_gq76y8_eoimpl_816_wlstub.getfreelist(unknown source) at cnc.query.list.querylist.createexcel(querylist.java:790) at cnc.query.list.exportdcessrequest(exportdata.java:39) at cnc.query.lis

10、t.exportdbe$0$doget(exportdata.java:15) at cnc.query.list.exportdata.doget(exportdata.java) at javax.servlet.http.httpservlet.service(httpservlet.java:740) at javax.servlet.http.httpservlet.service(httpservlet.java:853) at ernal.servletstubimpl$servletinvocationaction.run(

11、servletstubimpl.java:1077) at ernal.servletstubimpl.invokeservlet(servletstubimpl.java:465) at ernal.servletstubimpl.invokeservlet(servletstubimpl.java:348) at ernal.webappservletcontext$servletinvocationaction.run(webappservletcontext.java

12、:7047) at ernal.authenticatedsubject.doas(authenticatedsubject.java:321) at weblogic.security.service.securitymanager.runas(securitymanager.java:121) at ernal.webappservletcontext.invokeservlet(webappservletcontext.java:3902) at ernal.

13、servletrequestimpl.execute(servletrequestimpl.java:2773) at weblogic.kernel.executethread.execute(executethread.java:224) at weblogic.kernel.executethread.run(executethread.java:183) 经推断，这是清单查询的功能。 之后，转由开发人员对清单查询代码进行分析。 总结及改进措施 此次故障是由于个别程序性能不佳消耗cpu过高导致，在35个这样查询的状况下就会使系统出现缓慢现象，而且清单查询对jvm内存消耗也较大，假如有大量

14、清单查询会使jvm的内存出现溢出状况。 由于在目前状况下，1台服务器的处理力量不足，特殊是在业务高峰时，weblogic的1个被管服务器并不足以支撑2个被管服务器的业务，因此其中一台服务器出现宕机、挂起等严峻故障，往往另外一台也会出现相同故障。 鉴于上述状况，我们提出下列改进看法： 1、 在第三台机器上增加一个weblogic实例，加入到集群系统。这样在一台被管服务器出现故障时，另外两台依旧可以实现负载均衡功能，宕机的可能性大大降低。 2、 将清单查询从bss系统中移出去，目前这一项目正在进行。 3、 改良清单查询程序的性能。 附： 收集高 cpu 占用率的数据 对于有关收集高 cpu 占用率

15、的数据的特定操作信息，请依据您的操作系统执行以下步骤。 重要说明： 这些操作系统的全部信息都基于 sun jvm。 目前在 jrockit 中还没有方法将 pid 从说明 cpu 占用率的操作系统指令(prstat、top、pslist 等等)映射到 thread dump 中的正确线程。 从 jrockit 的 70sp4rp2 和 81sp2rp1 以后的版本起，就可实现此映射。 例如，在 linux 中，thread dump 在以后的版本中将采纳如下形式(pid 显示在 thread dump 中)： executethread: 20 for queue: default id: 0

16、x00000e80 prio: 5 active, daemon, gcable thread: 0x469b0af0 lastj: 0xac0f19c pt_thr: 237596 pid: 23166 at com.jrockit.vm.classes.defineclass0(native method)0x8b4b798 at com.jrockit.vm.classes.defineclass(unknown source)0x8b4b8b1 at java.lang.classloader.defineclass(unknown source)0x8b4b46f 在上例中，pid

17、是 23166，您可以通过 linux 或任何所在系统上的 top(或任何您需要在操作系统上用法的特定指令)输出挺直关联该 pid。 转换为十六进制号码 备注：为帮助您计算在本模式中争论的十六进制值，您可以在 shell 脚本中用法下列行将十进制号码转换为十六进制号码。假如您用法 unix 操作系统，那么转换会很便利。 dec2hex.sh: printf dec - hex: %d = %x n $1 $1 用法： $ sh dec2hex.sh 755 dec - hex: 755 = 2f3 solaris 1. 在 java 进程中运行 prstat指令。重复几次这个操作，以便您能够看到一种模式。例如：prstat -l -p 1 1 2. 在 java 进程中运行 pstack指令以获得从轻量型进程 (lwp) 到 pid(进程 id)的映射。 示例：pstack 9499 并将输出结果重定向到一个文件。 假如您用法 solaris 中的常规线程库(即，在 ld_library_path 中没有 /usr/lib/lwp)，lwp 就不会挺直映射到操作系统线程，因此您必需从进程中执行 pstack(所以检查看您是否正在用法替代线程库)。 3. 经过一段时间后对服务器进行若干 thread