Weblogic内存回收机制设计不合理导致服务器CPU使用率100%

1、问题现象

      一台16逻辑CPU的Weblogic服务器,CPU使用率持续100%

2、问题排查

2.1 查出占用CPU高的进程

top - 16:43:17 up 18 days,  1:46,  2 users,  load average: 19.06, 17.39, 17.15 Tasks: 453 total,   1 running, 452 sleeping,   0 stopped,   0 zombie Cpu(s): 97.0%us,  1.2%sy,  0.0%ni,  1.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st Mem:  65972384k total, 52586376k used, 13386008k free,   277628k buffers Swap:  4128760k total,        0k used,  4128760k free,  8066144k cached   PID USER      PR  NI  VIRT  RES  SHR S   %CPU       %MEM    TIME+  COMMAND                                                                                         29151 weblogic  20   0 16.8g 8.8g  25m S  1308.7  14.0   1577:45 java                                                                                          10162 weblogic  20   0 12.9g 4.8g  25m S 82.0  7.6  15016:42 java                                                                                             12836 weblogic  20   0 12.7g 4.9g  25m S 81.7  7.8  15314:08 java                                                                                            10051 weblogic  20   0 12.9g 4.8g  25m S 61.5  7.6  12358:46 java                                                                                            9556  weblogic  20   0 13.9g 2.6g  25m S 23.7  4.1  74:23.76 java                                                                                             12742 weblogic  20   0 11.9g 4.7g  24m S  4.6  7.5 903:44.15 java                                                                                            14160 weblogic  20   0 10.8g 4.7g  24m S  2.6  7.5 696:04.27 java

        总共才16个逻辑CPU，29151这一个进程，就占用了百分之一千三百多，也就是说，仅此一个进程，就完全消耗了13颗CPU资源，为一个java进程。

 

2.2 查查29151进程为何方神圣进程

# ps -ef |grep 29151

ps -ef |grep 29151 root     11231 10338  0 16:47 pts/1    00:00:00 grep 29151 weblogic 29151 29092 56 Dec28 ?        1-02:39:03 /usr/local/jdk1.6.0_37/bin/java -server -Xss512K -Xms3000m -Xmx8196m -Xmn2048m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=100 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseFastAccessorMethods -XX:CompileThreshold=5000 -XX:+DisableExplicitGC  -XX:ParallelGCThreads=32-XX:ConcGCThreads=32 -XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=/app/log/jvmgclog/jvmerr8g.log -XX:HeapDumpPath=/app/log/jvmgclog/ -verbose:gc -Xloggc:/app/log/jvmgclog/jvmgclog8g.log-Dweblogic.Name=elXXrning3_4 -Djava.security.policy=/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.policy -Dweblogic.ProductionModeEnabled=true -Dweblogic.security.SSL.trustedCAKeyStore=/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/cacerts -da -Dplatform.home=/weblogic/Oracle/Middleware/wlserver_10.3 -Dwls.home=/weblogic/Oracle/Middleware/wlserver_10.3/server -Dweblogic.home=/weblogic/Oracle/Middleware/wlserver_10.3/server -Dweblogic.management.discover=false -Dweblogic.management.server=http://10.1.XXX.XX:17001 -Dwlw.iterativeDev=false -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=false -Dweblogic.ext.dirs=/weblogic/Oracle/Middleware/patch_wls1036/profiles/default/sysext_manifest_classpath:/weblogic/Oracle/Middleware/patch_ocp371/profiles/default/sysext_manifest_classpath weblogic.Server

   

2.3 为什么一个java进程CPU使用率能达百分之一千三百呢？

从上面2.2节的29151进程信息中，不难看到有两个特别的参数，分别是：

-XX:ParallelGCThreads=32    -XX:ConcGCThreads=32

     上面的配置是，对一个Weblogic的JVM，开启了32个年轻代收集线程，和32个老年代回收器线程。

32+32=64啊，一个JVM光内存回收机制，就并发64个内存收集回收线程，服务器才16个逻辑CPU，这一个JVM就开它64个并行，要知道该虚拟机服务器上，可是并行运行着8个JVM呢。

 

3.3 验证29151进程占用CPU高时是不是在做内存回收（GC）

$ jstack 29151 

    --下面截取部分Weblogic Thread dump信息

（1）年轻代内存回收器（CMS）并行运行信息

2015-12-30 16:44:41 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode):   "VM Thread" prio=10 tid=0x00007f94cc407000 nid=0x7222 runnable   "Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x00007f94cc017000 nid=0x71e1 runnable "Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x00007f94cc019000 nid=0x71e2 runnable …… ……   "Gang worker#29 (Parallel GC Threads)" prio=10 tid=0x00007f94cc04c000 nid=0x71fe runnable   "Gang worker#30 (Parallel GC Threads)" prio=10 tid=0x00007f94cc04d800 nid=0x71ff runnable   "Gang worker#31 (Parallel GC Threads)" prio=10 tid=0x00007f94cc04f800 nid=0x7200 runnable

上面dump信息中，确实列出了32个年轻代内存回收线程（GC）在并行运行中。

 

（2）老轻代内存回收器（GC）并行运行信息

"Concurrent Mark-Sweep GC Thread" prio=10 tid=0x00007f94cc3c0000 nid=0x7221 runnable "Gang worker#0 (Parallel CMS Threads)" prio=10 tid=0x00007f94cc384800 nid=0x7201 runnable "Gang worker#1 (Parallel CMS Threads)" prio=10 tid=0x00007f94cc386000 nid=0x7202 runnable   …… ……   "Gang worker#30 (Parallel CMS Threads)" prio=10 tid=0x00007f94cc3bb000 nid=0x721f runnable "Gang worker#31 (Parallel CMS Threads)" prio=10 tid=0x00007f94cc3bc800 nid=0x7220 runnable "VM Periodic Task Thread" prio=10 tid=0x00007f94cc440000 nid=0x722a waiting on condition   JNI global references: 1299

      上面的dump信息中，确实列出了32个老年代回收线程（CMS）在并行运行中。

3、问题原因结论

      由于配置人员，没有详细计算服务器的实际CPU数量，以及服务器上总共运行的其它程序资源需求等，随意的设置了一个远远超过服务器实际CPU数量的并发机制，导致单个进程CPU使用率达百分之一千三百多，服务器整体CPU使用率接过100%的奇芭现象。

本文作者：黎俊杰（网名：踩点），从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作
欢迎加入系统性能优化专业群，共同探讨性能优化技术。群号：258187244