JVM 튜닝 도구 상세 설명 및 실제 전투 튜닝

튜닝 도구

jps

• Java 실행 프로세스보기

jmap

jmap -histo 30340  #查看历史生成的实例
jmap -histo:live 30340  #查看当前存活的实例，执行过程中可能会触发一次full gc

• num : 일련 번호
• 인스턴스 : 인스턴스 수
• 바이트 : 점유 공간의 크기
• 클래스 명 ： 类 名称 ， [C는 char [] ， [S는 short [] ， [I는 int [] ， [B는 byte [] ， [[I는 int [] []

jmap -dump:format=b,file=/Users/mac/Desktop/java学习/Dump/2.hprof 31274

• 생성 된 덤프 파일을 / Users / mac / Desktop / java learning / Dump 폴더에 넣습니다.
• 생성 된 덤프 파일은 일부 메모리 정보 를 보기 위해 perfma로 구문 분석 할 수 있습니다 .
  

jstack

• jstack을 사용하여 스레드 교착 상태 문제보기

jstack -pid

"Thread-1"스레드 이름
prio = 5 priority = 5
tid = 0x000000001fa9e000 스레드 ID
nid = 0x2d64 로컬 스레드 ID에 해당하는 스레드 nid
java.lang.Thread.State : BLOCKED 스레드 상태

• Thread-1은 Thread-0의 잠금을 기다리고 있고 Thread-0은 Thread-1의 잠금을 기다리고 있으므로 교착 상태가 됩니다.

가장 자주 사용되는 CPU 코드보기

• 가장 자주 사용되는 스레드를 찾으려면 top 명령을 사용하십시오.
• jstack을 사용하여 스레드 ID로 해당 코드를 찾습니다.

jinfo

• jvm 매개 변수보기

jinfo -flags <pid># 查找出所有的参数

jstat

jstat -gc pid 1000 10# 评估gc 压力 每1秒输出，一共输出10次

• S0C : 첫 번째 생존 영역의 크기 (KB)
• S1C : 두 번째 생존 영역의 크기
• S0U : 첫 번째 생존 영역의 사용 된 크기
• S1U : 두 번째 생존 영역의 사용 된 크기
• EC : Eden Park의 크기
• EU : Eden Park의 사용 크기
• OC : 노년 크기
• OU : 노년기에 사용 된 크기
• MC : 방법 영역 크기 (메타 공간)
• MU : 사용 된 방법 영역 크기
• CCSC : 압축 된 클래스 공간 크기
• CCSU : 압축 된 클래스 공간 사용 크기
• YGC : 젊은 세대 가비지 컬렉션 수
• YGCT : 젊은 세대 가비지 수집에 소비되는 시간 (초)
• FGC : 노년기의 가비지 컬렉션 수
• FGCT : 노년기에 가비지 수집에 소비 된 시간 (초)
• GCT : 가비지 수집에 소비 된 총 시간 (초)

**-Xloggc : / Users / mac / Desktop / java learning / GC / gc- % t.log ** 매개 변수를 사용할 수도 있습니다.

• / 사용자 / 맥 / 데스크탑 / 자바 학습 / GC / GC-% t.log로 파일을 입력하고 도구 사용 gceasy를 GC의 파일을 분석하는
  

JVM 동작 추정

어린 물체의 성장률

• EU (eden 영역 사용)를 관찰하여 초당 eden에 추가되는 객체 수를 추정하여 jstat -gc pid 1000 10 명령을 실행할 수 있습니다 (1 초에 한 번, 총 10 회 실행) . 시스템 부하가 높지 않은 경우 주파수를 1 초에서 1 분 또는 10 분으로 변경하여 전체 상황을 관찰 할 수 있습니다. 일반적인 시스템은 피크 기간과 일일 기간이있을 수 있으므로 다른 시간에 다른 조건에서 물체의 성장률을 추정해야합니다.

젊은 GC 트리거 빈도 및 매번 시간 소모

• 젊은 세대의 사물의 성장률을 알면 에덴 존의 크기에 따라 Young GC가 얼마나 자주 발생하는지 추론 할 수 있습니다. Young GC의 평균 시간은 YGCT / YGC 공식으로 계산할 수 있습니다. 결과를 바탕으로, Young GC 실행이 얼마나 오래 걸리기 때문에 시스템이 얼마나 오래 걸릴지 알 수 있습니다.

각 Young GC에서 얼마나 많은 개체가 살아남아 노년기에 접어들 었는지

• Young GC의 빈도는 이미 알고 있었기 때문입니다. 5 분마다 jstat -gc pid 300000 10 명령을 실행하여 eden, survivor 및 old age 사용량의 변화를 관찰 할 수 있습니다. 각 gc 후, eden 일반적으로 면적 사용량이 크게 감소합니다. 생존자와 노년기가 커질 수 있습니다. 이러한 증가 된 개체는 각 Young GC에서 살아남는 개체입니다. 동시에 각 Young GC 이후에 노후화되는 개체 수를 확인할 수 있습니다. , 그래서 당신은 노년기에 물체의 성장률을 계산할 수 있습니다.

전체 GC 트리거 주파수 및 매번 시간 소모

• 노년기에 물체의 성장률을 알면 Full GC의 트리거 빈도를 계산할 수 있으며 Full GC에 걸리는 시간은 FGCT / FGC 공식을 사용하여 계산할 수 있습니다.

사실, 최적화 아이디어는 각 Young GC가 젊은 세대에 남아있는 후 살아남은 개체를 Survivor 영역의 50 % 미만으로 만드는 것입니다. 대상이 노년기에 들어 가지 않도록하십시오. JVM 성능에 대한 빈번한 Full GC의 영향을 방지하려면 Full GC의 빈도를 줄이십시오.

아서스 문서

• Arthas를 다운로드 한 폴더로 이동하여 ./as.sh를 실행합니다.
• 명령 :
  전체 프로세스의 실행 상태, 스레드, 메모리, GC, 운영 환경 정보를 볼 수있는 대시 보드 입력 대시 보드 :
• 스레드 프로세스 ID보기 세부 사항
• thread -b보기 교착 상태

실제 전투 : Full GC 지연 해결 아이디어

• 메타 스페이스로 인한 Full GC 여부
• 많은 수의 "생사"개체가 노년기에 도달했는지 여부
  • 생존자 영역에 너무 많은 개체가 직접 노년기에 들어가기 때문에 생존자 영역의 개체에 대한 젊은 GC
• 공간 보장 메커니즘은 2 개의 Full GC로 이어집니다.
  • 구세대의 메모리가 평균 프로모션 크기보다 작기 때문에 fullGC 1 개와 젊은 GC
  • 젊은 GC, Full GC 이후 노년으로 승격
• 큰 물체가 노년기에 이르렀는지 여부