0

在负载测试期间，我们在其中一个节点中观察到非常高的 Full GC。我们使用了 3 个 glassfish 节点。在其他 2 个节点 GC 使用是正常的，但是在节点 1 中，对象无法释放并且对象缓慢到达XMX settings。我已经验证了所有 3 个节点JVM settings。他们是一样的。验证的服务器日志和 3 个节点的负载相同。不知道为什么 1 个节点有这个 GC 问题而不是其他节点。

JVM设置：

-XX:+UnlockDiagnosticVMOptions -XX:ParallelGCThreads=8 -XX:MaxPermSize=512m -XX:+AggressiveOpts -XX:NewRatio=2 -XX:+LogVMOutput -XX:+UseParallelGC -XX:LogFile=/opt/glassfish/domains/xyz/logs/jvm.log -Xmx4096m -Xms4096m

操作系统：红帽企业 Linux 服务器版本 5.6 (Tikanga)

JVM Version  
java version "1.6.0_24"  
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)  
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

这是 FULL GC 期间来自问题节点的 GC 示例。

 323233.103: [Full GC [PSYoungGen: 1305536K->1041065K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3837289K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 24.3236370 secs] [Times: user=24.32 sys=0.00, real=24.32 secs] 
323264.008: [Full GC [PSYoungGen: 1305536K->1106487K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3902711K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 22.2367020 secs] [Times: user=22.22 sys=0.01, real=22.24 secs] 
323291.647: [Full GC [PSYoungGen: 1305536K->1106550K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3902774K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 22.0651020 secs] [Times: user=22.06 sys=0.00, real=22.06 secs] 
323318.604: [Full GC [PSYoungGen: 1305536K->1106756K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3902980K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 22.4309650 secs] [Times: user=22.42 sys=0.00, real=22.43 secs] 
323345.717: [Full GC [PSYoungGen: 1305536K->1041019K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3837243K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 24.6671980 secs] [Times: user=24.65 sys=0.00, real=24.66 secs] 
323377.049: [Full GC [PSYoungGen: 1305536K->1102486K(1351872K)] [PSOldGen: 2796223K->2796223K(2796224K)] 4101759K->3898710K(4148096K) [PSPermGen: 105778K->105778K(106048K)], 22.5150360 secs] [Times: user=22.50 sys=0.00, real=22.51 secs]
4

1 回答 1

1

解决问题的一种方法是找出老一代中的对象是什么。这可以通过使用jmap -histo选项来完成。

运行jpsnotedown 进程 ID，然后调用jmap -histo pid. 您将获得每个类的对象计数。

它可能是缓存/会话复制或在导致问题的一个节点上运行的某些后台任务。找出正在填满内存的类将指出问题所在。

于 2012-09-05T17:42:05.410 回答