6
아래에서 볼 수 있듯이 예상대로 작동하는 모든 작업 중에 GC 중지 작업에는 +60 초가 걸렸습니다. 그 시간 동안 테라코타 서버가 응답하지 않았기 때문에 (테라코타) 클라이언트가 떨어 졌기 때문에 전체 시간 동안 세계를 멈출 것으로 판단 될 수 있습니다.JVM 분 long GC
이 젊은/보조 GC입니까? 그렇다면 젊은 세대의 기아 때문일 수 있습니까? (eden + survivors?).
109333 (KB) 무료입니까?
다른 메모리 컨테이너를 그래프로 표시 할 예정입니다. 다른 문제를 진단하기 위해 수행 할 수있는 다른 제안은 무엇입니까?
-Xms28672m -Xmx28672m -XX : + UseConcMarkSweepGC -XX : + PrintGCTimeStamps -XX : + PrintGC
제정신
date, startMem=24589884, endMem=24478495, reclaimed=111389, timeTaken=0.211244 (1172274.139: [GC 24589884K->24478495K(29343104K), 0.2112440 secs])
date, startMem=24614815, endMem=24505482, reclaimed=109333, timeTaken=61.301987 (1172276.518: [GC 24614815K->24505482K(29343104K), 61.3019860 secs])
date, startMem=24641802, endMem=24529546, reclaimed=112256, timeTaken=2.68437 (1172348.921: [GC 24641802K->24529546K(29343104K), 2.6843700 secs])
일 JVM은 다음과 같은 설정을 사용하여, 1.6 추가 디버그를위한 구성 조정 GC :
'-XX:+PrintGCDateStamps' Print date stamps instead of relative timestamps
'-XX:+PrintGCDetails' Will show what cpu went for (user, kern), gc algorithm used
'-XX:+PrintHeapAtGC' will show all of the heaps memory containers and their usage
'-Xloggc:/path/to/dedicated.log' log to specific file
응용 프로그램의 기능은 무엇입니까? GC 지터는 여러 스윕에서 많은 양의 메모리가 힙에서 회수 될 때 발생합니다. 각 스윕으로 인해 더 많은 개체가 수집 대상이되어 더 많은 스윕이 발생할 수 있습니다. 2 초 동안 실행해도 GC에 걸리는 시간은 엄청납니다. 응용 프로그램에서 객체를 처리하는 방법을 변경하는 것이 JVM 구성이 아니라 필요한 경로가 될 것입니다. GC 지터를 낮춰야하는 모든 응용 프로그램은 객체를 재 할당하는 대신 재사용해야합니다. – codeghost
세션 (쿠키) 저장소입니다. 숫자 (예 : "reclaimed")는 실제로 회수 된 메모리가 많지 않음을 나타냅니다. 그렇다면 이유를 아는 것이 매우 편리합니다. 나는 (세션) 객체가 어떻게 다루어 지는지, 무엇이 포함되어 있는지 등을 해결해야한다는 것에 완전히 동의한다. 세션을 더 잘 처리하는 프로세스가 있지만, 지금은 왜 GC는 +60 초가 걸리고 이전 0.2 초의 GC보다 더 많은 메모리를 확보하지 못합니다. – user135361
이 블로그 http://kirk.blog-city.com/why_do_i_have_this_long_gc_pause.htm에서 몇 가지 정보를 얻을 수 있습니다. – codeghost