JVM 가비지 수집에 대한 간단한 사례 분석

1 HotSpot 매개 변수 분류

 

  > 표준 :-처음에는 모든 HotSpot 지원

  > 비표준 : -X로 시작, 특정 버전의 HotSpot은 특정 명령을 지원합니다.

  > 불안정 : -XX로 시작하면 다음 버전이 취소 될 수 있습니다.

java -X 표준 매개 변수보기

 

2 실험을 통한 JVM 매개 변수 이해

 

public class HelloGC {

    public static void main (String [] args) {

      System.out.println ( "HelloGC!");

      목록 목록 = new LinkedList ();

      for (;;) {

        byte [] b = 새로운 바이트 [1024 * 1024];

        list.add (b);

      }

    }

  }

 

2.1 javac HelloGC.java 컴파일

2.2 java -XX : + PrintCommandLineFlags HelloGC

2.3 자바 -Xmn10M -Xms40M -Xmx60M -XX : + PrintCommandLineFlags -XX : + PrintGC HelloGC

젊은 세대의 크기 설정 : -Xmn10M

최소 힙 크기 설정 : -Xms40M

최대 힙 크기 설정 : -Xmx60M

GC 정보 인쇄 : + PrintGC

여기서 GC는 YGC를 의미하지만 Full GC의 정보이기도합니다.

2.4 java -Xmn10M -Xms40M -Xmx60M -XX : + PrintCommandLineFlags -XX : + PrintGCDetails -XX : + PrintGCTimeStamps HelloGC

인쇄 GC 세부 정보 설정 : + PrintGCDetails

인쇄로 전송 된 인쇄 된 CG가 발생할 때 타임 스탬프를 설정합니다. + PrintGCTimeStamps

2.5 자바 -XX : + UseConcMarkSweepGC -XX : + PrintCommandLineFlags HelloGC

이전 가비지 수집기를 다음과 같이 설정하십시오. CMS

2.6 java -XX : + UseConcMarkSweepGC -XX : + PrintCommandLineFlags -XX : + PrintGC HelloGC

2.7 java -XX : + UseConcMarkSweepGC -XX : + PrintCommandLineFlags -XX : + PrintGCDetails HelloGC

2.8.java -XX : + PrintFlagsInitial 기본 매개 변수 값

2.9.java -XX : + PrintFlagsFinal 최종 매개 변수 값

 

요약하자면 :

 

 

에덴 공간 5632K, 94 % 사용됨 [0x00000000ff980000,0x00000000ffeb3e28,0x00000000fff00000)

             다음 메모리 주소는 사용 된 공간의 시작 주소, 끝 주소 및 전체 공간의 끝 주소를 나타냅니다.

 

1. 처리량 : 사용자 코드 시간 / (사용자 코드 실행 시간 + 가비지 수집 시간)

2. 응답 시간 : STW가 짧을수록 응답 시간이 좋습니다.

문제:

과학적인 계산, 처리량. 데이터 마이닝, 처리량. 일반 처리량 우선 순위 : (PS + PO)

응답 시간 : 웹 사이트 GUI API (1.8 G1)

3 로그 매개 변수 설정

  -Xloggc : /opt/xxx/logs/xxx-xxx-gc-%t.log -XX : + UseGCLogFileRotation -XX : NumberOfGCLogFiles = 5 -XX : GCLogFileSize = 20M -XX : + PrintGCDetails -XX : + PrintGCDateStamps -XX : + PrintGCCause

케이스:

1. 500,000 개의 PV 데이터 웹 사이트 (디스크에서 메모리로 문서 추출) 원본 서버 32 비트, 1.5G가 있습니다.

   웹 사이트가 상대적으로 느리다는 사용자 피드백 때문에 회사는 업그레이드하기로 결정했으며 새 서버는 64 비트, 16G입니다.

   결과적으로 사용자는 지연이 매우 심각하지만 효율성이 이전보다 낮다고 피드백합니다.

   1. 원래 웹 사이트가 느린 이유는 무엇입니까?

      많은 사용자가 데이터를 탐색하고, 많은 데이터가 메모리에로드 됨, 메모리 부족, 빈번한 GC, 긴 STW, 느린 응답 시간

   2. 왜 더 뒤떨어져 있습니까?

      메모리가 클수록 FGC 시간이 길어집니다.

   3. 무엇을해야합니까?

      PS-> PN + CMS 또는 G1

2. 시스템 CPU가 100 % 인 경우가 많습니다. 어떻게 조정합니까?

   CPU가 100 %이면 시스템 리소스를 차지하는 스레드가 있어야합니다.

   1. CPU가 높은 프로세스 확인 (맨 위)

   2. 프로세스에서 CPU가 높은 스레드 (상위 -Hp)

   3. 스레드 스택 (jstack) 내보내기

   4. 시간을 소비하는 방법 (스택 프레임) 찾기 (jstack)

   5. 작업자 스레드의 높은 비율 | 가비지 콜렉션 스레드의 높은 비율

3. 시스템 메모리가 너무 높습니다. 문제를 어떻게 찾을 수 있습니까? (면접 빈도)

   1. 힙 메모리 (jmap) 내보내기

   2. 分析 (jhat jvisualvm mat jprofiler ...)

4. JVM 모니터링 방법

   1. jstat jvisualvm jprofiler arthas top ...

 

추천

출처blog.csdn.net/huzhiliayanghao/article/details/106931443