Question

我们在负载测试期间在其中一个节点中观察到非常高的Full GC。我们使用了3个玻璃鱼节点。在其他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

O / S：Red Hat Enterprise Linux Server 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]

Answer 1

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

运行jps，注明进程ID，然后调用jmap -histo pid。您将获得每个班级的对象计数。

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

老一代在一个节点填满

1 个答案: