Skip to main content

8. GC 로깅, 모니터링, 튜닝, 툴

GC 로깅 및 모니터링에 대해서 다룹니다.

GC 로깅 개요#

GC 로그

  • 훌륭한 정보
  • 시스템이 내려간 원인의 단서를 찾는 콜드 케이스 분석을 할 때 매우 유용합니다.

모든 중요한 애플리케이션에서는 다음 두 가지를 선정해야합니다.

  • GC 로그를 생성해야합니다.
  • 애플리케이션 출력과는 별도로 특정 파일에 GC 로그를 보관합니다.

GC 로깅은 거의 오버헤드가 없으므로, 주요 JVM 프로세스는 항상 로깅을 켜놓아야합니다.

GC 로깅 켜기#

-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintTenuringDistribution-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps

알면 좋은 플래그는 다음과 같습니다.

  • -Xloggc:gc.logGC
    • 이벤트에 로깅할 파일을 지정한다.
  • -XX:+PrintGCDetailsGC
    • 이벤트 세부 정보를 로깅한다.
  • -XX:+PrintTenuringDistribution
    • 툴링에 꼭 필요한, 부가적인 GC 이벤트 세부 정보를 추가한다.
  • -XX:+PrintGCTimeStampsGC
    • 이벤트 발생 시간을 (VM 시작 이후 경과한 시간을 초 단위로) 출력한다.
  • -XX:+PrintGCDateStampsGC
    • 이벤트 발생 시간을 (벽시계 시간 기준으로) 출력한다

GC 로그 vs JMX#

VisualGC는 JVM 힙 상태를 실시간 표시하는 툴이며 JMX(자바 관리 확장, Java Management eXtensions) 인터페이스를 통해서 JVM 데이터를 수집합니다.

JMX는 성능 데이터의 원천으로서 스트리밍 데이터를 즉시 제공한다는 점에서는 GC 로그보다 낫지만, 요즘 툴은 일반적으로 GC 로그 데이터를 스트리밍하는 API를 제공하므로 큰 차이가 없습니다.

JMX의 단점#

JMX를 이용해 애플리케이션을 모니터링하는 클라이언트는 대부분 런타임을 샘플링해 현재 상태를 업데이트합니다.

다만 문제는 가비지 수집입니다. 즉, 각 수집 사이클 전후의 메모리 상태를 알 수가 없으므로 GC 데이터를 깊이 있게, 정확하게 분석할 수 없습니다.

GC 로그 데이터의 장점#

GC 로그에 쌓인 기초 데이터는 특정 GC 이벤트와 연관 지을 수 있어서 모든 의미 있는 분석 작업을 수행할 수 있습니다. (어느 지점에서 수집 비용이 발생하는 지, 어떻게 튜닝해야 긍정적인 결과를 얻을 수 있을지를 수행할 수 있습니다.)


로그 파싱 툴#

유지보수가 잘되는 상용 툴과 오픈 소스 툴이 예시로 있습니다.

센섬#

  • jClarity사가 제작한 사용 메모리 분석기
  • 서비스 모니터링 용도
  • GC 로그 파싱, 정보 추출, 자동 분석 기능을 제공

GC Viewer#

  • GC 로그 파싱 및 그래프 출력 등 기본 기능을 가지고 있음
  • 여러가지로 형태로 볼 수 있습니다.

GC 기본 튜닝#

튜닝을 수행할 때는 다음 4가지 주요 인자를 고려해야합니다.

  • 할당
  • 중단 민감도
  • 처리율 추이
  • 객체 수명

튜닝 시 GC 플래그는 다음과 같이 추가합니다.

  • 한번에 한 플래그씩 추가합니다.
  • 각 플래그가 무슨 작용을 하는지 숙지해야합니다.
  • 부수 효과를 일으키는 플래그 조합도 있음을 명시합니다.

다음을 확인함을 통해서 GC인지 아닌지를 판단해야합니다.

  • CPU 사용률이 100%에 가까운지
  • 대부분의 시간(90% 이상)이 유저 공간에서 소비되는지
  • GC 로그가 쌓이고 있다면 현재 GC가 실행 중이라는 증거입니다.

할당#

할당률 분석은 튜닝 방법뿐만 아니라, 실제로 가비지 수집기를 튜닝하면 성능이 개선될지 여부를 판단하는데 꼭 필요한 과정입니다.

  • 한계치가 높을수록 진짜 장수한 객체를 더 많이 복사합니다.
  • 한계치가 넘 낮으면 단명 객체가 승격되어 테뉴어드에 메모리압이 가중됩니다.

중단 시간#

개발자는 중단 시간에 대한 인지 편향으로 종종 시달립니다. 대부분은 100밀리초 정도의 중단 시간은 무시할 만합니다. 그보다 큰 시간의 경우는 다음과 같이 3개의 대역으로 나누어 표현합니다.

  • 1초 이상 걸려도 괜찮은 경우
  • 1초 ~ 100 밀리초 정도는 괜찮은 경우
  • 100밀리초까지는 괜찮은 경우

image

수집기 스레드와 GC 루트#

GC 루트 탐색 시간은 다음의 요인 영향을 받습니다.

  • 애플리케이션 스레드 개수
  • 코드 캐시에 쌓인 컴파일드 코드량
  • 힙 크기

Parallel GC 튜닝#

목표

  • 풀 STW
  • GC 처리율이 높고 계산 비용이 쌉니다.
  • 부분 수집이 일어날 가능성은 없습니다.
  • 중단 시간은 힙 크기에 비례하여 늘어납니다.

CMS 튜닝#

CMS는 까다롭기로 소문난 수집기 입니다. 즉, 최상의 성능을 얻기 위해서는 여러 가지 복잡성과 트레이드 오프가 있습니다.

다음의 문제점이 발생할 수 있습니다.

  • 스위치 만지작거리기
  • 민간 튜닝
  • 숲을 못 보고 나무만 보는 경우

G1 튜닝#

엔드 유저가 최대 힙 크기와 최대 GC 중단 시간을 간단히 설정하면 나머지는 수집기가 알아서 처리하게 하는 것이 G1 튜닝의 목표입니다.


jHiccup#

JVM이 연속적으로 실행되지 못한 지점을 발견해줍니다. 깃허브에서 받을 수 있습니다.

Edit this page
Last updated on