Spring Boot 가사 진단 실전 기록

이틀 동안 서비스 가사 문제 에 부 딪 혔 는데 구체 적 인 현상 은 서비스 가 더 이상 어떠한 요청 도 받 지 않 고 클 라 이언 트 가 Broken Pipe 를 던 지 는 것 이다.
시스템 상태 확인
top 을 실행 하면 CPU 와 메모리 사용량 이 높 지 않 지만 명령 을 통 해

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

대량의 CLOSE 발견WAIT 포트 점용,이 서비스의 api 를 계속 호출,시간 초과 후 CLOSE 발견WAIT 의 수도 늘 지 않 았 다.즉,서비스 가 거의 완전히 경직 된 셈 이다.
JVM 상태 확인
스 레 드 에 자물쇠 가 있 을 수 있 습 니 다.먼저 스 레 드 상황 을 덤 프 하여 실행 하기 로 결 정 했 습 니 다.

jstack <pid> > /tmp/thread.hump

tomcat 스 레 드 도 기본적으로 정상 적 이 고 모두 parking 상태 인 것 으로 밝 혀 졌 다.

이것 은 비교적 이상 하 다.GC 가 STW 를 초래 한 것 이 아니 냐 고 계속 생각 하고 jstat 를 사용 하여 쓰레기 회수 상황 을 살 펴 보 자.

app@server:/tmp$ jstat -gcutil 1 2000 10
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 27.79 65.01 15.30 94.75 92.23 1338 44.375 1881 475.064 519.439

깜짝 놀 랐 다.YG C 의 횟수 는 무려 475 s 로 YG C 를 앞 질 렀 다.틀림없이 어떤 원인 이 FGC 를 촉발 시 켰 을 것 이다.다행히 우 리 는 GC log 를 열 었 다.

한동안 Allocation Failure 로 인 한 Full GC 가 빈번히 발생 하 는 것 을 발 견 했 습 니 다.그리고 eden 구역 의 사용 비중 도 매우 커서 자주 신 설 대상 이 옛날 로 탈출 하 는 것 을 고려 하여 문 제 를 일 으 켰 다.업무 개발 에 대해 물 어 봤 더 니 외부 도 킹 API 가 페이지 를 나 누 지 않 았 는 지 확인 하고 조회 후 대량의 대상 이 생 길 수 있 습 니 다.
외부 API 가 일시 적 으로 상대방 에 게 수정 을 연락 할 수 없 기 때문에 문 제 를 먼저 해결 하기 위해 기 존 맥 스 뉴 사이즈 에 대해 서 는 192 MB 에서 배로 확장 했다.며칠 간 의 관찰 을 통 해 gc 가 기본적으로 정상 으로 돌아 가 는 것 을 발견 하 였 다.

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 3.37 60.55 8.60 95.08 92.98 87 2.421 0 0.000 2.421

확장 하기 전에 힙 을 덤 프 했 어 요.

jmap -dump:format=b,file=heapDump <PID>

MAT 를 통 해 메모리 유출 을 분석 한 결과 jdbc 의 한 종류 로 추정 되 지만 전체 점용 용량 은 많 지 않다.

스 레 드 수 를 분 석 했 는데 약 240 여 개 로 정상 적 인 때 와 큰 차이 가 없 었 다.그리고 대량의 것 은 sleep 의 정시 라인 이다.
총결산
이번 조 사 는 사실 진정한 원인 을 찾 지 못 했다.간접 표상 은 FGC 가 빈번하게 서비스 가사 로 이 어 진 것 이다.또한 acturator 포트 는 정상적으로 작 동 하여 helch check 프로 세 스 가 서비스 가 정상 이 라 고 오해 하고 경고 가 울 리 지 않 았 습 니 다.당신 도 비슷 한 상황 에 부 딪 히 면 함께 토론 하 는 것 을 환영 합 니 다.
자,이상 이 이 글 의 모든 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가 치 를 가지 기 를 바 랍 니 다.여러분 의 저희 에 대한 지지 에 감 사 드 립 니 다.