1.概述
BSS域中的Statserv集群中的server时常无法显示监控状态,具体表现为OK或者Warning列无信息,一般当Server比较繁忙时会出现这种问题,当请求较少时会恢复与AdminServer的通信。然而Statserv集群中的Server并不会自动恢复,通过观察GC情况,判断该Server挂起。
在最近的升级中,XXX工程师将数据量进一步减少,系统运行状态明显好转,只在12月14日下午statserv_206_01出现无法显示健康状态情况。
2.调优建议
目前将集群中存在的问题罗列并提出调优建议,观察是否会出现问题。
2.1.JVM PermSize问题
观察GC执行情况执行情况:
从截图中的数据主要有两个问题:
1、从截图中标红的列为Permanent区,该区是独立于Heap区以外的内存区域,该区主要加载一些固定的类,随着应用的运行该区会逐渐增大,而且该内存区域中的对象是不参与minor gc的。该内存区的占用为99.86%,下面是JVM的参数设置:
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 2147483648 (2048.0MB)
NewSize = 1048576 (1.0MB)
MaxNewSize = 4294901760 (4095.9375MB)
OldSize = 4194304 (4.0MB)
NewRatio = 8
SurvivorRatio = 8
PermSize = 16777216 (16.0MB)
MaxPermSize = 268435456 (256.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 212795392 (202.9375MB)
used = 4623464 (4.409278869628906MB)
free = 208171928 (198.5282211303711MB)
2.1727274996631505% used
From Space:
capacity = 12582912 (12.0MB)
used = 0 (0.0MB)
free = 12582912 (12.0MB)
0.0% used
To Space:
capacity = 12058624 (11.5MB)
used = 0 (0.0MB)
free = 12058624 (11.5MB)
0.0% used
PS Old Generation
capacity = 1908932608 (1820.5MB)
used = 77040992 (73.47201538085938MB)
free = 1831891616 (1747.0279846191406MB)
4.0358151815907375% used
PS Perm Generation
capacity = 78643200 (75.0MB)
used = 78600232 (74.95902252197266MB)
free = 42968 (0.04097747802734375MB)
99.9453633626302% used
可以看到需要关注的Permanent区实际大小为75.0MB,而启动参数为-server -Xms2048m -Xmx2048m -XX:MaxPermSize=256m,只设置了最大Permanent区的大小,并没有设置初始值,虽然当某一块内存区域出现空间不足时会自动进行扩展,但是在该Server并未出现扩大Permanent区的现象,也就是说-XX:MaxPermSize=256m并未起作用。 2、截图数据中蓝色的部分,主要观察FGC和YGC,这两列分别表示的意义为FULL GC和MINOR GC 的次数,从蓝色框中的两列的数据可以看到JVM执行了一次FULL GC,而且从FULL GC执行后各个区的使用情况看,并未创建太大的对象,唯一的解释为:Permanet Generation中存放的为一些class的信息等,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下会执行Full GC。
上述两种情况均由Permanent区不足导致,因此建议:
将该参数修改为-XX:PermSize=256m,该参数的意义是当启动Weblogic Server时就将Permanent区设置为256M。
具体修改的方法为(以statserv_206_01为例):
点击statserv_206_01进入statserv_206_01配置页面:
点击进入Server Start进入启动参数设置界面,主要修改的参数为:
将上图中的-XX:MaxPermSize=256m参数修改为-XX:PermSize=256m,或者在-XX:MaxPermSize=256m前面添加-XX:PermSize=256m。
2.2.内存溢出
从本次Server挂起后的日志分析,有如下错误信息。、
<2012-12-14 上午11时15分02秒 CST> <Warning> <HTTP Session> <BEA-100089> <The session id: YT1cQKYNcFpZNhv6snWZ2vvSJ2pVTW0jRx515l8p4GSn2XR491TT has been accessed from -2355747093831050072S:133.224.218.206:BSSWEB:statserv_206_01, a server that is neither the primary (1841954021422617079S:133.224.218.204:[19661,19661,-1,-1,-1,-1,-1]:BSSWEB:statserv_204_01) nor the secondary (7660179456118168886S:133.224.218.205:[19661,19661,-1,-1,-1,-1,-1]:BSSWEB:statserv_205_01). The request URL was: http://133.224.218.228:80/stat>
Exception in thread "DoSManager" Exception in thread "Timer-1" java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.util.HashMap.newKeyIterator(HashMap.java:840)
at java.util.HashMap$KeySet.iterator(HashMap.java:874)
at java.util.HashSet.iterator(HashSet.java:153)
at com.octetstring.vde.DoSManager.run(DoSManager.java:438)
出现上述错误主要是JVM堆内存不足造成的,即处理新的请求时需要创建新的对象来存储相关数据,但是当创建对象时JVM并没有足够大的内存提供,因此会出现请求失败的现象。
下面的数据为12月14日JVM内存使用情况。
时间
JVM_NAME
JVM空闲率
2012-12-14 08:00:00
statserv_206_01
91.18
2012-12-14 08:05:00
statserv_206_01
90.53
2012-12-14 08:10:00
statserv_206_01
90.82
2012-12-14 08:15:00
statserv_206_01
89.92
2012-12-14 08:20:00
statserv_206_01
90.21
2012-12-14 08:25:00
statserv_206_01
89.18
2012-12-14 08:30:00
statserv_206_01
85.83
2012-12-14 08:35:00
statserv_206_01
88.77
2012-12-14 08:40:00
statserv_206_01
90.76
2012-12-14 08:45:00
statserv_206_01
87.81
2012-12-14 08:50:00
statserv_206_01
66.18
2012-12-14 08:55:00
statserv_206_01
86.85
2012-12-14 09:00:00
statserv_206_01
89.6
2012-12-14 09:05:00
statserv_206_01
87.18
2012-12-14 09:10:00
statserv_206_01
78.84
2012-12-14 09:15:00
statserv_206_01
85.43
2012-12-14 09:20:00
statserv_206_01
84.39
2012-12-14 09:25:00
statserv_206_01
81.8
2012-12-14 09:30:00
statserv_206_01
88.74
2012-12-14 09:35:00
statserv_206_01
89.6
2012-12-14 09:40:00
statserv_206_01
84.18
2012-12-14 09:45:00
statserv_206_01
90.72
2012-12-14 09:50:00
statserv_206_01
90.13
2012-12-14 09:55:00
statserv_206_01
90.44
2012-12-14 10:00:00
statserv_206_01
89.14
2012-12-14 10:05:00
statserv_206_01
90.21
2012-12-14 10:10:00
statserv_206_01
82.62
2012-12-14 10:15:00
statserv_206_01
62.12
2012-12-14 10:20:00
statserv_206_01
76.63
2012-12-14 10:25:00
statserv_206_01
62.51
2012-12-14 10:30:00
statserv_206_01
70.76
2012-12-14 10:35:00
statserv_206_01
67.38
2012-12-14 10:40:00
statserv_206_01
79.43
2012-12-14 10:45:00
statserv_206_01
74.64
2012-12-14 10:50:00
statserv_206_01
85.04
2012-12-14 10:55:00
statserv_206_01
76.92
2012-12-14 11:00:00
statserv_206_01
90.54
2012-12-14 11:05:00
statserv_206_01
90.05
2012-12-14 11:10:00
statserv_206_01
84.93
2012-12-14 11:15:00
statserv_206_01
71.78
2012-12-14 11:20:00
statserv_206_01
33.12
2012-12-14 12:00:00
statserv_206_01
1.39
从上面的数据(IT网管监控数据)可以看出在11点20分时,JVM堆内存剩余率开始减少,而且中间出现了数据缺失的现像,到12点以后已经没有数据返回了,运行到后面堆内存一直减少以至于出现了OOM的问题,导致Server挂起。而且从集群中未挂起的Server看在12月14号11点开始有STUCK线程出现,即有数据处理时间过长的现象,从应用处返回的信息是数据量比较大,处理比较慢,从整体上看11点后有大量的请求过来,整个集群都比较繁忙,最终导致statserv_206_01OOM,最终挂起。整体上看用户都是在11点左右开始使用此报表系统,在之前几乎没有用户使用该系统,用户量大导致数据量大,最终导致OOM挂起。
为了明确问题,增加启动参数,当出现内存溢出(OOM)时,产生heapdump,heapdump是内存快照,可将当时的内存信息保存下来,便于分析是何种原因导致了内存溢出,或者是何种对象占用了大量的内存空间。Heapdump是非常重要的分析JVM内存的手段,请重视一下。
添加的参数为:-XX:+HeapDumpOnOutOfMemoryError,该参数的添加方法与2.1中的参数相同,添加该参数后,需要重启Weblogic Server,当发生内存溢出时会在域目录下生成heapdump,方便分析当时的内存使用情况。
建议:将上述两个参数添加到所有的weblogic Server中,以便后续如果出现故障,方便故障原因。
该贴被funny编辑于2014-2-24 10:32:15