세 번째.
기사를 쓰는 것 자체가 시간이 걸려요.
알기 쉬운 기사로 만들기는 어려워요.
조금씩 개량하다.
저장과 추적을 도와주면 고무될 거예요.
　
그럼 본론입니다.
jstat과 GC 로그 등을 봤는데 메모리를 열기가 어려운 경우
메모리의 내용을 분석하기 위해 덤프를 꺼내다.

무더기를 얻다

먼저 jstat 및 ps 명령 등을 사용하여 개체 JVM의 프로세스 ID를 가져옵니다.

jps -v | less -SN

프로세스 ID를 알고 jmap 명령으로 덤프합니다.
서버의 디스크 용량을 확인하십시오.
Heap 크기를 2GB 이상 파일로 설정
이 가능하다, ~할 수 있다,...

jmap -dump:format=b,file=./heapdump.hprof {プロセスID}

파일을 지정된 위치에 덤프할 수 있습니다.
-dump:live,format=...이렇게 라이브를 켜면 GC가 일어나요.
명령을 실행할 때만 유효한 대상을 저장할 수 있습니다.
어쨌든 이번엔 다 가져가야 돼.

쌓인 내용을 분석하다

도구를 사용하여 해결합니다.
java 표준 jhat, Memory Analyzer, Heap Analyzer 등
이번엔 몇 번?.
Eclipse 기반이므로 크기가 큰 덤프 파일을 열 때
MemoryAnalyzer.ini 설정을 통해 도구 자체의 무더기 크기를 설정합니다
늘려주세요.
Open Heap Dump 이전에 가져온 파일 지정
다음 대화 상자에서 Leak Suspects Report 를 선택합니다.
조금만 기다리면 오버뷰가 열리니 리포트의 Leak Suspects를 선택하세요.
Memory Analyzer
그럼 도구가 메모리 유출 혐의가 있는 곳을 찾아줄 거야.
※ 도대체가 의심일 뿐, 다른 경우도 있고, 찾을 수 없는 유출도 있습니다.
위의 그림에서 T4CPPretedStation은 5000개 미만의 인스턴스를 유지하고 있습니다.
용량의 25%를 사용했다고 알려주세요.
Details>> 이 링크를 누르면 해당 객체의 상위 참조가 표시됩니다.

TxConnection Listener 부하 50명이 T4CP Prepted Station 약 100개를 유지하고 있는 것 같아요.
5천개(4천953개)의 T4CPPPreptedStation이 있는 모습이다.
TxConnectionListener가 T4CPPreptedStation을 직접 가지고 있는 건 아닌 것 같아요.
이 뷰는 여기밖에 안 보여요.
Dominator Tree에서 T4Cproprepared Statimeent를 검색하여 참조 소스를 찾습니다.

내용은 SQL 정보의 캐시 등입니다.뭐, Prepture Station이니까.
그럼 이 참조점을 거슬러 올라가자.
T4CPreptedStation을 클릭하여 Path To GC Roots->with all reference를 선택한 후
참조 소스를 추적합니다.

등급별로는 캐치(PrepturedStatement Cache)가 유지되고 있다.
여기까지의 정보부터 50개의 연결(TxConnectionListener)
현금 100개 있는 거 아니까.
DB(데이터 소스)의 연결 설정이 위에서 설명한 대로 되어 있는지 확인합니다.

Connection Pool Size는 50, Statent Cache Size는 100입니다.
가설이 옳은 것 같다.아무리 봐도 너무 많아.네.
적당한 값으로 조정한 뒤 다시 덤프 처리를 해 메모리 사용률도 크게 줄었다.
이번 이유는 중간부품의 설정입니다.
개발된 앱에 의한 유출이 의심된다면
Dump는 서버가 시작될 때, 몇 분 후, 몇 시간 후에 여러 번 확인해야 합니다.
쌓아올리는 차점을 2개 뽑는 기능이 있어서 남은(누출된) 대상은 없는지
큰 사이즈의 대상이 있는지 등을 검사하다.
오늘은 여기까지!

자바 개발의 성능 개선!1Jstat을 통해 스택/GC 확인

자바 개발의 성능 개선!2GC 로그의 해석 및 Heep 설정