RocketMQ 4.2.0 broker JVM 최적화 매개 변수 깊이 분석

배경
온라인 에서 RocketMQ 를 사용 한 지 꽤 되 었 습 니 다. 상당히 안정 적 이 라 고 할 수 있 습 니 다. 코드 와 구조 에 있어 합 리 적 인 사 고 를 제외 하고 일련의 작 동 최적화 매개 변수 도 연구 할 가치 가 있 습 니 다. 그 다음 에 broker 의 작 동 매개 변 수 를 예 로 들 어 분석 할 수 있 습 니 다.
시작 명령

/usr/lib/jvm/java-1.8.0-openjdk.x86_64/bin/java -server -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:SurvivorRatio=8 -verbose:gc -Xloggc:/dev/shm/mq_gc_%p.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintAdaptiveSizePolicy -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch -XX:MaxDirectMemorySize=15g -XX:-UseLargePages -XX:-UseBiasedLocking -Djava.ext.dirs=/usr/lib/jvm/java-1.8.0-openjdk.x86_64/jre/lib/ext:/home/user/rocketmq-all-4.2.0-master/bin/../lib -cp .:/home/user/rocketmq-all-4.2.0-master-b/bin/../conf:.:/usr/lib/jvm/java-1.8.0-openjdk.x86_64/lib:/usr/lib/jvm/java-1.8.0-openjdk.x86_64/jre/lib: org.apache.rocketmq.broker.BrokerStartup -c /home/user/rocketmq-all-4.2.0-master/conf/2m-noslave/broker-b.properties

이 를 통 해 알 수 있 듯 이 긴 명령 중 JVM 매개 변 수 는 진실 이 적지 않다.
매개 변수 분석

-server

\ # server 방식 으로 시작 할 것 을 지정 합 니 다. 이것 은 x64 아래 의 필수 옵션 입 니 다. 일반적으로 기본 값 도 server 모드 입 니 다. 안전 표시 와 함께 client 모드 보다 성능 이 너무 좋 습 니 다.

-Xms4g 
-Xmx4g

\ # 쓰레기 회수 가 끝 날 때마다 JVM 이 메모 리 를 재배 치 하지 않도록 초기 더미 크기 와 최대 크기 는 4g 입 니 다.

-Xmn2g

\ # 젊 은 세대 크기 를 2G 로 설정 합 니 다.전체 JVM 메모리 크기 = 젊 은 세대 크기 + 늙 은 세대 크기 + 지속 적 인 세대 크기 (또는 MetaSpace 공간 크기).지구 대 는 일반적으로 고정 크기 가 64m 이기 때문에 젊 은 세 대 를 늘 리 면 연로 대 크기 가 줄어든다.이 값 은 시스템 성능 에 큰 영향 을 미 치 므 로 Sun 은 전체 더미 의 3 / 8 로 설정 하 는 것 을 추천 합 니 다.
 

-XX:+UseG1GC

\ # G1 쓰레기 수집 기 오픈
 

-XX:G1HeapRegionSize=16M

\ # 더미 에 있 는 region 할당 크기 를 지정 합 니 다.각 Region 은 E, S, O 와 H 로 표시 되 어 있 는데 이 는 각 Region 이 실 행 될 때 하나의 역할 을 하 는 것 을 의미한다. 그 중에서 H 는 기 존의 알고리즘 에 없 는 것 으로 Humongous 를 대표 한다. 이 는 이러한 Region 이 거대 한 대상 (humongous object, H - obj) 을 저장 하고 새로운 대상 의 크기 가 Region 크기 의 절반 을 초과 할 때 새로운 하나 또는 여러 연속 Region 에서 직접 분배 한 다 는 것 을 의미한다.H 로 표시 합 니 다.메모리 에 있 는 한 Region 의 크기 는 - XX: G1HeapRegionSize 매개 변 수 를 통 해 지정 할 수 있 습 니 다. 크기 구간 은 1M, 2M, 4M, 8M, 16M, 32M 에 불과 합 니 다. 한 마디 로 2 의 멱 차방 입 니 다. G1HeapRegionSize 가 기본 값 이면 더미 초기 화 시 Region 의 실천 크기 를 계산 합 니 다.G1 region 은 1M - 32M (2 의 지수) 을 뛰 어 넘 고 분배 요구 가 4M 을 조금 넘 었 다.따라서 8M 의 region 사 이 즈 는 허 밍 어 스 분 배 를 피하 기 에는 부족 하 다.16MB 가 필요 합 니 다.
 

-XX:G1ReservePercent=25

\ # 메모리 가 전체 크기 의 백분율 을 차지 하여 승진 실 패 를 방지 합 니 다. 기본 값 은 10% 입 니 다.JVM 은 생존 또는 승진 대상 을 회수 할 때 스 택 영역 이 넘 치면 실패 합 니 다. 쌓 인 사용 이 최대 치 에 도 달 했 기 때문에 더 이상 확장 할 수 없습니다.G1 GC 는 만일 의 경우 'to - space' Survivor 영역 에 더 많은 공간 이 필요 할 수 있 도록 상한 메모리 예약 을 설정 합 니 다.
 

-XX:InitiatingHeapOccupancyPercent=30 

\ # 전체 더 미 를 몇% 까지 사용 할 때 GC 주 기 를 시작 합 니 다. 전체 더 미 를 기반 으로 한 세대 의 점용 상황 뿐만 아니 라 G1 은 이 값 에 따라 GC 주 기 를 촉발 할 지 여 부 를 판단 합 니 다. 0 은 GC 에 있 었 고 기본 값 은 45% (45%) 입 니 다.이 곳 은 30% 로 조절 하여 가능 한 한 빨리 GC 주 기 를 촉발 합 니 다.0 은 GC 에 있다 는 뜻 이다.
 

-XX:SoftRefLRUPolicyMSPerMB=0

\ # 이 매개 변 수 는 비교적 유용 합 니 다. 공식 적 으로 는 Soft reference 는 가상 컴퓨터 에서 고객 보다 집중 적 으로 생존 하 는 것 이 더 길다 고 설명 합 니 다.제거 빈 도 는 명령 행 인자 - XX: SoftRefLRUPolicy MSPerMB = 으로 제어 할 수 있 습 니 다. 이 는 메 가 더미 의 빈 공간 에 있 는 soft reference 가 생존 (강하 지 않 으 면 도달 할 수 있 습 니 다) 의 밀리초 수 를 지정 할 수 있 습 니 다. 이 는 메 가 더미 의 빈 공간 에 있 는 soft reference (마지막 강 한 참조 가 회수 되 었 을 때) 가 1 초 동안 생존 하 는 것 을 의미 합 니 다.주의 하 세 요. 이것 은 근사치 입 니 다. 왜냐하면... soft reference 는 쓰레기 를 회수 할 때 만 제거 되 며 쓰레기 수 거 는 항상 발생 하지 않 습 니 다.시스템 은 기본적으로 1 초 입 니 다. 1 초 를 기다 릴 필요 가 없습니다. 바로 지우 지 않 아 도 됩 니 다. - XX: SoftRefLRUPolicy MSPerMB = 0 으로 바 꿉 니 다.
 

-XX:SurvivorRatio=8

\ # eden 영역 크기 와 그 중의 survivor 의 비율 을 8 로 설정 합 니 다.suvivor 구역 은 2 개, 즉 전체적인 survivor 와 eden 의 비율 은 2 대 8 이다.

-verbose:gc #   -XX:+PrintGC      。                    ，    ：
                                              [Full GC268K->168K(1984K), 0.0187390 secs]
-Xloggc:/dev/shm/mq_gc_%p.log #gc log        
-XX:+PrintGCDetails  #   -XX:+PrintGC         gc    
-XX:+PrintGCDateStamps or XX:+PrintGCTimeStamps #GC     ，      
-XX:+PrintGCApplicationStoppedTime #  gc         

\ # 위 5 개의 매개 변수 설정 을 통 해 지정 한 경로 에서 자세 한 gc 실행 로그 정 보 를 얻 을 수 있 습 니 다.
 

-XX:+PrintAdaptiveSizePolicy

\ # 수집 에 적응 하 는 크기 를 인쇄 하고 기본적으로 닫 습 니 다.협조 - XX: - UseAdaptive SizePolicy 를 사용 하여 자체 적응 크기 를 닫 고 쓰레기 회수 기 로그 에 추 가 된 survivor 공간 통계 정 보 를 얻 습 니 다.
 

 -XX:+UseGCLogFileRotation #    ，      。      。
 -XX:NumberOfGCLogFiles=5 #   0，     。     log   5
 -XX:GCLogFileSize=30m #   0，       。      30m

위의 세 가 지 를 동시에 설정 하면 로그 순환 스크롤 작용 을 하여 서버 의 디스크 소 모 를 방지 할 수 있 습 니 다.
 

-XX:+AlwaysPreTouch

\ # main 을 사용 하기 전에 JVM 은 먼저 모든 메모리 에 접근 하여 운영 체제 가 JVM 에 메모 리 를 진정 으로 할당 하도록 합 니 다. 후속 JVM 은 원활 하 게 메모리 에 접근 할 수 있 습 니 다.
JAVA 프로 세 스 가 시 작 될 때 JVM 에 적합 한 메모리 크기 를 지정 할 수 있 지만 이러한 메모리 운영 체 제 는 JVM 에 제대로 할당 되 지 않 고 JVM 이 이 메모리 에 접근 할 때 만 진정 으로 할당 되 므 로 다음 과 같은 문제 가 발생 할 수 있 습 니 다.
1. GC 때 신세대 대상 이 옛날 로 승진 하려 면 메모리 가 필요 합 니 다. 이때 운영 체제 가 진정 으로 메모 리 를 분배 해 야 영 gc 의 정지 시간 을 늘 릴 수 있 습 니 다.  2. 메모리 조각 에 문제 가 있 을 수 있 습 니 다.
 

-XX:MaxDirectMemorySize=15g 

\ # Direct ByteBuffer 가 할당 한 메모리 가 지정 한 크기 에 도달 하면 Full GC 를 실행 합 니 다.이 값 은 상한 선 이 있 습 니 다. 기본 값 은 64M 이 고 최대 sun. misc. VM. max DirectMemory () 입 니 다. 프로그램 에서 - XX: MaxDirectMemory Size 의 설정 값 을 얻 을 수 있 습 니 다.확 대 를 통 해 직접 쌓 아 올 리 는 Full GC 를 줄 입 니 다.
direct ByteBuffer 는 full gc 를 통 해 메모리 의 'direct' 를 회수 합 니 다. ByteBuffer 는 스스로 상황 을 감지 하여 system. gc () 를 호출 합 니 다. 그러나 매개 변수 에 DisableExplicitGC 를 사용 하면 이 빠 른 메모 리 를 회수 할 수 없습니다. - XX: + DisableExplicitGC 플래그 는 자동 으로 System. gc () 호출 을 빈 동작 으로 변환 합 니 다. 즉, 응용 프로그램 에서 System. gc () 를 호출 하면 빈 동작 이 됩 니 다.그럼 설정 하면 우리 가 수 동 으로 메모 리 를 회수 해 야 합 니 다.
FULL GC 말고 direct 를 회수 할 수 있 는 게 있어 요. ByteBuffer 요?CMS GC 는 Direct ByteBuffer 의 메모 리 를 회수 하 는데 CMS 는 주로 old space 공간 을 위 한 쓰레기 수 거 다.하지만 Oracle JDK 6u 32 이후 버 전 입 니 다.
ByteBuffer 는 두 가지 가 있 습 니 다.
heap ByteBuffer -> -XX:Xmx
1. 하 나 는 hep ByteBuffer 입 니 다. 이 대상 은 JVM 의 메모리 에 분배 되 고 자바 가상 컴퓨터 에서 쓰레기 수 거 를 직접 책임 집 니 다.
direct ByteBuffer -> -XX:MaxDirectMemorySize
2. 하 나 는 direct ByteBuffer 로 jni 를 통 해 가상 컴퓨터 외 메모리 에서 분 배 됩 니 다.jmap 를 통 해 이 빠 른 메모리 의 사용 상황 을 볼 수 없습니다.top 을 통 해서 만 메모리 사용 상황 을 볼 수 있 습 니 다.

-XX:-OmitStackTraceInFastThrow 

\ # fast throw 최 적 화 를 사용 하지 않 고 온라인 문제 검 사 를 가속 화 합 니 다.이것 은 HotSpot VM 이 이상 에 대한 최 적 화 를 전문 적 으로 하 는 것 으로 fast throw 라 고 합 니 다. 일부 이상 이 코드 에서 특정한 위치 에 여러 번 던 지면 HotSpot Server Compiler (C2) 는 fast throw 로 이상 한 곳 을 최적화 시 키 고 미리 분 배 된 유형 이 일치 하 는 대상 을 직접 던 집 니 다. 이 대상 의 message 와 stack trace 는 모두 비 워 집 니 다.장점: 이 이상 을 던 지 는 것 이 매우 빠 르 고 메모 리 를 추가 로 분배 할 필요 도 없고 창고 에 올 라 갈 필요 도 없다.단점: 어디 가 문제 인지 알 아야 할 때 stack trace 가 보이 지 않 아 조사 에 불리 하 다.
 

 -XX:-UseLargePages

\ # 큰 페이지 (huge pages) 최 적 화 를 사용 하지 않 습 니 다.어떤 경우 에는 메모리 낭비 나 인 스 턴 스 를 시작 할 수 없습니다.기본 시작.
 

 -XX:-UseBiasedLocking

\ # JVM 기본 값 으로 편향 잠 금 을 사용 합 니 다.경쟁 이 치열 한 상황 에서 편향 자 물 쇠 는 시스템 부담 을 증가 시킨다 (매번 편향 여 부 를 판단 해 야 한다).  。
외국
G1 을 사용 할 때 는 되도록 설정 하지 마 십시오. -XX: 뉴 사이즈 = 4g - XX: 맥 스 뉴 사이즈 = 5g 전시 이용자 제한 region 의 범위 가 4 - 5G 사이 여서 G1 GC 의 적응력 이 제한 됐다.G1 이 제한 설정 을 더 작은 값 으로 제거 해 야 한다 면 할 수 없습니다.G1 GC 가 공간 범 위 를 늘 려 야 한다 면 할 수 없 는 공간 을 초과 합 니 다!
- Xss 15120 \ # 스 레 드 (thread) 를 추가 할 때마다 15M 메모리 가 즉시 소모 되 며, 최 적 치 는 128 K 여야 합 니 다. 기본 값 은 512 k 인 것 같 습 니 다.
- XX: NewRatio = 4 \ # 는 신세대 (eden + 2 * survivor) 와 옛날 (영구 테이프 나 metaspace 포함 되 지 않 음) 의 비율 을 나타 낸다.
- XX: + PrintGCAPplicationConcurrentTime \ # GC 사이 에 얼마나 실행 되 었 는 지