Java : "used memory"그래프의 빈번한 스파크

Question

Java 어플리케이션의 성능상의 문제로 프로파일 링을 위해 JavaMelody를 사용했으며 비정상적인 것은 "Used Memory"그래프입니다. 그것은 ~ 8GB 라인에 도달하는 것처럼 보이는 짧은 스파이크를 많이 가지고 있습니다. 그리고 이해합니다. GC는 메모리를 정리하고 있습니다. 누군가가 이러한 스파이크의 의미를 추적 할 수 있습니까? 그들은 특정 문제를 지적한 것처럼 보입니다.

GC JVM과 같이 구성된다 : -XX : PermSize = 384m -XX :를 MaxPermSize = 512m -XX : + UseCompressedOops -XX : + UseFastAccessorMethods -XX : + CMSClassUnloadingEnabled -XX : + UseParNewGC -XX : -UseParallelOldGC -XX : -UseAdaptiveSizePolicy -XX : SurvivorRatio = 128 -XX : newSize와 = 4,055m -XX : MaxNewSize = 4,055m -XX : + UseConcMarkSweepGC -XX : CMSInitiatingOccupancyFraction = 60 -XX : + 컴퓨터 사용 시작 작업 만 사용 -Xms12888 m -Xmx12888m -Dsun.rmi.dgc.client.gcInterval = 1800000 -Dsun.rmi.dgc.server.gcInterval = 1800000

그래프 (녹색, 청색 "최대"는 "평균"된다)이고 : Memory graph - 16:00 - 8:00 system without load, 8:00+ - system is under load

8 시까 지 시스템에 부하가 없습니다. 당신은 JVM에 대한 정상 작동 당신의 에덴 공간에서 객체를 할당하는 것 같은

는 부하의 8시 후

있지만 거대한 하나 (~ 20 개에 동시 작업)

Answer 1

이 보인다. 나는 당신이 할당 비율이 무엇인지 알아 내고 그것을 줄일 수있는 방법이 있는지를보기 위해 Flight Recorder와 같은 메모리 프로파일 러를 사용할 것을 제안한다.

특히, 몇 초에 한 번 이상 GCing을하면 생성하려는 쓰레기 양을 줄이려고합니다. 이 시간보다 길면 중요한지 여부에 따라 유스 케이스에 달려있다.

최근에 메모리 프로파일을 작성하지 않았다면 응용 프로그램의 다른보기를 얻으려면 그렇게하십시오. 성능이 문제가되지 않는 경우에도 버그를 찾는 것이 유용하다는 것을 알게되었습니다.

-XX : SurvivorRatio = 128

는

이 꽤 높은 당신은 매우 짧은 살고 객체의 여지가 제안합니다. 이것들은 최적화하기 쉽습니다.

저는 최근에 뉴욕의 클라이언트를위한 규칙 엔진을 사용했고 할당 비율을 줄이는 데 하루를 소비함으로써 성능이 2.3 배 향상되었습니다. CPU에 두 번째 날을 보내면 처리량이 4 배가됩니다.