작업용 컴퓨터의 운영 체제를 Win7로 교체 한 후, MyClipse는 시작 및 달리기 속도에서 만족스럽지 못했습니다. 특히 다중 페이지 템플릿을 동시에 수정하고 디버깅 할 때 두 파일 사이를 전환하면 항상 약 10 초 동안 고정됩니다. 다양한 플러그인을 끄고 확인하는 것은 도움이되지 않습니다. 그래서 JVM을 대략적으로 공부 한 후, 나는 JVM의 관점 에서이 문제를 해결하기로 결정했습니다.
최적화 시작 :
먼저 myeclipse.ini의 기본 시작 매개 변수를 살펴 보겠습니다.
-xmx512m : 최대 힙 메모리 값을 512m로 설정하십시오
-xx : maxpermsize = 256m : 영구 생성의 최대 값을 256m로 설정
-xx : reservedcodecachesize = 64m : 코드가 차지하는 메모리 크기를 64m로 설정
시작 매개 변수에서 볼 수있는 것은 없으므로 메모리 인쇄를위한 관련 매개 변수를 추가하십시오.
-xx :+printgctimestamps : 각 GC의 타임 스탬프를 인쇄하십시오
-xx :+printgcdetails : 각 GC에 대한 자세한 정보 인쇄
-xloggc : myeclipsegc.log : 파일에 GC 레코드를 출력합니다
-Verbose : GC : 각 GC의 관련 상황을 출력하십시오
그런 다음 myeclipse를 시작하고 myeclipsegc.log에서 정보를 확인하십시오.
스타트 업은 약 30 초가 걸립니다. 로그의 작은 부분을 선택적으로 차단합니다. MyClipse 스타트 업의 첫 10 초 동안 JVM은 300 개 이상의 GC와 9 개의 전체 GC를 실행했음을 알 수 있습니다.
GC 주파수 및 정보에서 메모리 복구 속도가 매우 높고 크기가 지속적으로 조정되고 있음을 알 수 있습니다. 이것은 젊은 세대의 공간이 충분하지 않기 때문에 상당한 초기 가치가 필요합니다.
그런 다음 전체 GC에 집중하십시오.
코드를 다음과 같이 복사하십시오. 5.961 : [Full GC 5.961 : [tenured : 34568k-> 34456k (49676k), 0.1397651 초] 35336k-> 34456k (53452k), [Perm : 26623k-> 26456k (26624k)]. [시간 : user = 0.14 sys = 0.00, real = 0.14 secs]
9.030 : [Full GC 9.030 : [임기 : 53310K-> 52332K (64588K), 0.2034757 SECS] 56020K-> 52332K (69516K), [perm : 43007k-> 42996k (43008k)], 0.20360 300003000030300030 sys = 0.00, real = 0.20 secs]
두 로그의 비교를 통해 전체 GC가 주로 임기 및 파마의 두 영역을 재활용하고 있으며이 두 영역의 크기가 지속적으로 조정되어 크기를 먼저 고정하기로 결정했습니다.
따라서 조정 된 매개 변수는 다음과 같습니다.
-xms512m : 스택의 최소값을 512m로 설정
-XMN192M : 젊은 세대의 크기를 192m로 설정
-xx : permsize = 192m : 영구 생성의 초기 값을 192m로 설정
-xx : maxpermsize = 192m
-xx : reservedcodecachesize = 64m
-xx :+printgctimestamps
-xx :+printgcdetails
-xloggc : myeclipsegc.log
-Verbose : GC
로그 정보를 보려면 MyEclipse를 다시 시작하십시오.
스타트 업은 약 12 초가 걸렸습니다. 로그로부터, 처음 10 초 안에 5 개의 GC 만 수행되었으며 각 영역의 크기에 대한 조정이 관련되지 않았 음을 알 수 있습니다. 이 결과는 작업 중에 자주 다시 시작할 필요가 없기 때문에 허용됩니다.
작업 응답 속도의 최적화 :
다음으로, 나는 오랫동안 문제를 일으킨 HTML 파일을 앞뒤로 전환 할 때 빈번한 지연과 큰 카드 문제를 연구했습니다. JVM의 메모리 변경을보다 직관적으로 연구하기 위해 Java와 함께 제공되는 도우미 도구 인 JCONSOLE을 사용하기로 결정했습니다. 먼저 최적화의 첫 번째 단계에서 간섭을 피하기 위해 myeclipse.ini의 매개 변수를 복원하십시오.
MyEeclipse를 시작하고 JCONSOLE을 시작하고 MyEclipse가있는 JVM에 연결하십시오. 안정적인 후 전체 힙의 메모리 다이어그램은 다음과 같습니다.
다음으로 몇 개의 템플릿을 열고 메모리 변경을 관찰하십시오.
우선, 힙 메모리의 전반적인 사용 :
여러 개의 템플릿을 개설 한 후 힙 메모리의 사용이 원래 100m 미만에서 300m 이상으로 갑자기 증가 함을 알 수 있습니다. 사용량은 3 배가되었지만 여전히 설정 한 512m 범위 내에 있습니다. 따라서 일시적으로 힙 메모리를 계속 늘리는 것을 고려할 수는 없지만 각 영역의 메모리 크기 비율을 조정하는 것을 고려할 수 있습니다.
따라서 우리는이 기간 동안 각 영역의 메모리 사용량을 관찰하며, 그 중에도 구역은 다음과 같습니다.
이 기간 동안 에덴 영역의 메모리 사용률이 크게 증가했으며 GC는 여러 번 발생했습니다. 아래 모니터링 정보를 통해 기본적으로 에덴 영역은 31m의 최대 메모리 만 할당되며, 이는 분명히 충분하지 않다는 것을 알 수 있습니다. 작은 지점의 실행은 Eden 지역에서 GC를 트리거합니다. 이것은 템플릿 오프닝 스위치에서 지연 지연의 이유 중 하나이어야하며 조정해야합니다.
다음은 임기 지역입니다.
기본적으로 JVM 이이 영역에 할당 된 최대 공간은 470m입니다. 메모리 사용이 변경됨에 따라이 영역의 실제 크기가 지속적으로 조정되고 있습니다. 전체 GC는 면적 크기가 조정 될 때마다 발생하며, 이는 자주 큰 블록의 이유 중 하나가되어야합니다. 새 템플릿의 개방은이 조정을 트리거하는 주된 이유입니다. 이 영역의 메모리 사용의 관점에서,이 영역의 메모리 공간을 약 450m로 유지하고 고정하여 일정량의 중복성을 유지해야합니다.
이러한 관점에서 볼 때, 더 큰 임기 영역과 에덴 지역을 유지하기 위해 JVM의 힙 메모리를 확장해야합니다.
마지막으로 Perm 영역을 살펴 보겠습니다.
방법 영역의 일부로,이 영역의 메모리 변화는 크지 않고 상대적으로 안정적이지 않으므로 너무 많은 중복성을 남길 필요가 없습니다. 그러나 현재 개설 된 프로젝트의 실제 코드 볼륨이 크지 않다는 점을 고려할 때 약 128m에 일시적으로 유지하고 향후 천천히 조정하기로 결정했습니다.
따라서 위의 분석에 따르면 매개 변수는 다음과 같이 조정됩니다.
-xmx768m
-xms768m
-xmn256m
-xx : permsize = 192m
-xx : maxpermsize = 192m
-xx : reservedcodecachesize = 64m
MyEclipse를 다시 시작하고 JCONSOLE에 연결하고 동시에 30 개의 템플릿을 열어 테스트를 수행하십시오. 각 영역의 메모리 사용률을 살펴보면 문제가 발견되었습니다. 젊은 세대를 256m로 조정 한 후, Eden이 더 이상 GC에서 자주 발생하지 않기 때문에, 임기 영역으로 입력하는 데이터의 양은 크게 줄어 듭니다. 임기 영역의 메모리 사용 다이어그램은 다음과 같습니다.
위 그림과 같이, 많은 템플릿이 의도적으로 열리면, 450m+ 공간은 250m 미만 만 사용하고 공간 활용률이 너무 낮으므로 조정을해야합니다.
요약
위의 것은 MyClipse를 조정할 수있는 몇 가지 아이디어와 실제 튜닝 프로세스입니다. 실제로 사용하면 선호도에 따라 조정 및 사용자 정의를했습니다. myeclipse.ini의 최종 매개 변수는 다음과 같습니다.
-vmargs
-xmx512m
-xms512m
-xmn192m
-xx : permsize = 128m
-xx : maxpermsize = 128m
-xx : reservedcodecachesize = 64m
이 매개 변수 설정에서 마이 클립의 응답 속도는 비교적 보장되며 다양한 지연 지연의 빈도가 크게 줄어 듭니다. 단점은 영주 거주자가 차지하는 시스템 메모리가 비교적 높다는 것입니다. 동시에 여러 개의 myeclipse를 열고 싶어하는 학생들은 필요와 실제 조건에 따라 적절한 조정을 할 수 있습니다.
위의 내용은이 기사에 관한 모든 것입니다. 모든 사람의 학습에 도움이되기를 바랍니다.