오래된 노드가 한 노드에 가득 차 있음

로드 테스트 중에 노드 중 하나에서 매우 높은 Full GC가 관찰되었습니다. 우리는 3 개의 glassfish 노드를 사용했습니다. 다른 두 노드에서 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 : 레드햇 엔터프라이즈 리눅스 서버가 여기에

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)

5.6 (Tikanga)를 출시 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]

출처

2012-09-05 malay biswal

문제를 해결하는 한 가지 방법은 이전 세대의 개체를 찾는 것입니다. 이것은 jmap -histo 옵션을 사용하여 수행 할 수 있습니다.

run jps은 프로세스 ID를 명시한 후 jmap -histo pid을 호출합니다. 각 클래스에 대한 개체 수가 계산됩니다.

캐싱/세션 복제 또는 문제의 원인이되는 노드에서 실행되는 일부 배경 작업 일 수 있습니다. 기억을 채우는 클래스를 찾아 내면 문제를 지적 할 것입니다.

출처

2012-09-05 17:42:05 gkamal

감사합니다. gkamal. jmap을 실행하고 알려 드리겠습니다. 이 파일은 로그 파일을 덤프 할 것인가? 그렇다면 위치는 어디에 있는가? 어떤 도구를 사용하여 jmap 로그를 분석 할 수 있습니다. 그러나 내 질문에 왜 노드 1 난 다른 2 노드 동안 나는 GC의 문제를했습니다. 누군가이 문제에 직면했다면, 당신의 경험을 공유하십시오. –

오래된 노드가 한 노드에 가득 차 있음

답변

관련 문제