자바 쓰레기 회수 정수-Part 4

자바 쓰레기 수 거 정 수 는 4 개 부분 으로 나 뉘 는데,이 편 은 4 부 다.4 부 에 서 는 G1 수집 기,기타 동시 다발 수집 기,쓰레기 수집 모니터링 과 튜 닝 을 소개 했다.
Garbage First(G1)수집 기
G1(-XX:+UseG1GC)수집 기 는 새로운 수집 기 입 니 다.G1 은 자바 6 발표 와 함께 자바 7U4 에서 공식 지원 을 받 았 다.이 는 일부 동시 다발 적 인 수집 알고리즘 으로 전체 일시 정 지 를 소량 늘 리 는 방식 으로 오래된 지역 을 압축 하여 FullGC 를 최소 화 합 니 다.파편 으로 인 한 풀 GC 가 CMS 의 골칫거리 다.G1 도 세대 별 수집 기 이지 만 다른 수집 기와 다른 조직 방식 을 사용한다.G1 은 용도 에 따라 더 미 를 같은 용도 의 더미 가 아 닌 많은(약 2 천 개)고정 크기 의 구역 으로 나 누 었 다.
G1 동시 표시 영역 은 영역 간 인용 을 추적 하 는 동시에 수집 영역 에서 가장 큰 여유 공간 에 주목 합 니 다.이 구역 들 은 점차 증가 하 는 전역 일시 정지 에서 수집 되 고 생존 대상 은 빈 구역 으로 잘 려 서 전체 과정 이 압축 된다.같은 주기 에 수 집 된 구역 을 Collection Set 라 고 합 니 다.
번역:G1 은 각 지역 에 쌓 인 쓰레기 의 가치 크기,회수 후 얻 은 공간 크기 와 회수 에 소요 되 는 시간 을 추적 하여 배경 에서 우선 목록 을 유지 합 니 다.매번 허용 되 는 수집 시간 에 따라 가장 가치 가 큰 구역,즉 Garbage-First 명칭 을 우선 회수 하 는 이유 다.
지역 크기 의 50%를 초과 한 대상 은 큰 지역 에서 분 배 됩 니 다.그 크기 는 현재 지역 크기 의 몇 배 에 달 할 수 있 습 니 다.G1 수집 과 분배 대상 조작의 비용 은 매우 크 고,더욱 비극 적 인 것 은 아직 최적화 조치 가 없다 는 것 이다.
모든 압축 수집 기 가 직면 하 는 도전 은 대상 을 이동 하 는 것 이 아니 라 대상 의 인용 을 업데이트 하 는 것 이다.한 대상 이 여러 지역 에서 인용 된다 면 이 인용 을 업데이트 하 는 데 는 이동 대상 보다 시간 이 더 걸 릴 것 입 니 다.G1 은'기록 집합(Remembered Sets)'을 통 해 다른 영역 에서 인 용 된 대상 들 을 추적 합 니 다.메모리 집합 은 일부 카드 의 집합 으로 이 카드 들 에는 업데이트 정보 가 표시 되 어 있다.기억 집합 이 커지 면 G1 은 눈 에 띄 게 느 려 진다.한 지역 에서 대상 을 다른 지역 으로 옮 길 때 이 로 인해 발생 하 는 전체 일시 정지 시간 은 인용 구역 을 스 캔 하고 업데이트 해 야 하 는 수량 과 정비례 한다.
유지 보수 기록 집 회 는 부차적인 회수 비용 을 증가 시 켰 고,그 결과 고생대 수집 기와 CMS 수집 기 중 부차적인 회수 일시 정 지 를 병행 하 는 것 보다 시간 이 더 오래 걸 렸 다.
G1 은 대상 이 구동 하 는 것 으로"–XX:MaxGCpause Millis="을 통 해 지연 시간 을 설정 할 수 있 습 니 다.기본 값 은 200 ms 입 니 다.이 매개 변 수 는 가능 한 한 모든 주기의 작업량 에 영향 을 줄 수 있 지만 최종 효 과 는 보장 되 지 않 습 니 다.수 십 밀리초 로 설정 하 는 것 은 대부분 헛 된 것 이 고 수 십 밀리초 도 G1 이 주목 하 는 목표 가 아니다.
만약 당신 의 프로그램 이 0.5-1.0 초의 증 량 압축 시간 을 멈 추 는 것 을 용인 할 수 있 고,이 프로그램 은 점차 파편 화 될 더 미 를 가지 고 있다 면,G1 는 일반적인 수집 기의 좋 은 선택 이 될 것 입 니 다.최 악의 경 우 는 조각 으로 인 한 일시 정지 입 니 다.우 리 는 전에 CMS 에서 도 본 적 이 있 습 니 다.G1 는 이러한 일시 정지 빈 도 를 줄 이 는 경향 이 있다.왜냐하면 그것 은 추가 적 인 부차적인 회수 와 늙 은 세대 에 대한 증 량 압축 을 소비 하기 때문이다.대부분의 일시 정 지 는 전체 더미 의 압축 이 아니 라 지역 차원 으로 제한 된다.
CMS 와 마찬가지 로 G1 도 승 진률 을 담보 하지 못 해 실패 하고 결국 전역 이 일시 중 단 된 풀 GC 에 도움 을 청 할 것 으로 보인다.CMS 에'병발 모드 실패'가 있 었 듯 이 G1 도 이동 에 실 패 했 을 수 있 으 며 로그 에서'도착 공간 넘 침(to-space overflow)'을 볼 수 있 습 니 다.대상 을 옮 길 수 있 는 공간 이 없 는 것 은 승진 실패 와 유사 하 다.만약 이런 상황 이 발생 한다 면 더 큰 더미,더 많은 태그 라인 을 사용 해 보 세 요.그러나 어떤 경우 에는 분배 비율 을 줄 이기 위해 프로그램 이 바 뀌 어야 합 니 다.
G1 의 도 전적인 문 제 는 높 은 관심 사 대상 과 지역 을 어떻게 잘 처리 하 느 냐 하 는 것 이다.지역 의 생존 대상 이 다른 지역 에 대량으로 인용 되 지 않 았 을 때 증 가 된 전역 을 일시 정지 하고 압축 하면 효율 적 입 니 다.한 대상 이나 지역 이 대량으로 인용 되면 기록 집 은 상응 하 게 커지 고 G1 은 이러한 대상 을 수집 하 는 것 을 피 할 것 이다.결국 어 쩔 수 없 이 중간 길이 의 일시 정지 시간 을 자주 사용 해 쌓 인 크기 를 압축 할 수 밖 에 없 었 다.
기타 병렬 수집 기
CMS 와 G1 은 통상 적 으로 동시성 이 가장 좋 은 수집 기로 불 린 다.그러나 전체 업무 과정 을 살 펴 보면 신세대,승진,심지어 대부분 늙 은 세대 의 업무 가 병행 되 지 않 는 다 는 것 이 분명 하 다.CMS 는 노후 세대 에 게 동시성 이 가장 좋 은 알고리즘 으로,G1 은 전역 적 으로 일시 정 지 된 증분 수집 기 에 가깝다.CMS 와 G1 는 모두 규칙 적 인 전체 일시 정지 발생 을 뚜렷하게 가지 고 있 으 며 최 악의 상황 에서 그들 은 엄격 한 저 지연 응용,예 를 들 어 금융 거래 나 사용자 의 상호작용 인터페이스 에 적합 하지 않다.
다른 사용 가능 한 수집 기 는 Oracle Jrockit Real Time,IBM WebSphere Real Time,Azul Zing 도 있다.Jrockit 과 Websphere 수집 기 는 대부분 지연 상 CMS 나 G1 보다 잘 제어 되 지만,대부분의 경우 스루풋 제한 이 있 고,뚜렷 한 전역 정지 가 있 을 수 있 습 니 다.징 은 모든 세대 에 대해 진정 으로 수집 과 압축 을 병행 할 수 있 고 높 은 삼투 율 을 유지 할 수 있 는 자바 수집 기 라 는 것 을 소설가 가 알 고 있다.Zing 은 확실히 아 밀리초 단위 의 전역 일시 정지 가 있 지만,이것 은 생존 대상 집합 크기 와 무관 한 수집 주기 에서 이 루어 집 니 다.
재 락 킷 리 얼 타임 은 쌓 기 크기 가 적당 할 때 일시 정지 시간 을 수 십 밀리초 로 조절 할 수 있 지만,가끔 은 완전 압축 일시 정지 로 전환 하 는 데 실패 하기 도 한다.WebSphere RealTime 은 분배 율 과 생존 집합의 크기 를 제약 함으로써 일시 정지 시간 을 몇 밀리초 로 조절 할 수 있다.Zing 은 모든 단계 에서 높 은 분배 율 을 확보 하기 위해 밀리초 단위 의 일시 정 지 를 실현 하고 부차적인 수집 단 계 를 포함한다.징 은 쌓 인 크기 와 상 관 없 이 행동 의 일치 성 을 유지 할 수 있다.프로그램의 스루풋 을 확보 하거나 대상 모델 상 태 를 제어 해 야 한다 면 사용 자 는 일시 정지 시간 을 늘 릴 걱정 없 이 더 큰 더 미 를 추가 할 수 있 습 니 다.
모든 병렬 수집 기 에 있어 서 지연 에 관심 이 있다 면 스루풋 을 희생 하여 공간 을 바 꿔 야 한다.동시 다발 수집 기의 효율 에 따라 약간의 스루풋 을 포기 할 수 있 지만 공간 을 현저히 늘 릴 수 있다.실제 병발 이 이 루어 지면 전체 일시 정지 가 발생 하지 않 지만 병발 작업 과 스루풋 유 지 를 지원 하기 위해 서 는 더 많은 CPU 커 널 이 필요 합 니 다.
주의:분 배 된 공간 이 충분 할 때 모든 병렬 수집 기 는 더욱 효율 적 으로 운행 하 는 경향 이 있 습 니 다.첫 번 째 경험 은 최소한 두 세 배의 생존 집합 크기 를 예산 해 효율 적 인 조작 을 확보 해 야 한다.그러나 대량의 병행 작업 에 필요 한 공간 은 응용 프로그램의 물동량 과 이와 관련 된 대상 의 분배 와 승 진률 이 증가 함 에 따라 증가한다.따라서 높 은 스루풋 의 응용 에 대해 서 는 높 은 생존 집합 을 유지 하 는 퇴적 크기 비율 이 필요 하 다.오늘 서버 가 엄 청 난 메모리 공간 을 가지 고 있다 는 점 을 감안 하면 문제 가 되 지 않 습 니 다.
쓰레기 수집 감시 와 변조
응용 프로그램 과 쓰레기 수집 기 가 어떻게 작 동 하 는 지 이해 하려 면 JVM 을 시작 할 때 다음 과 같은 인 자 를 추가 해 야 합 니 다.
1
2
3
4
5
6
7 -verbose:gc -Xloggc: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime
그리고 Chewiebug 같은 도구 로 로 로 그 를 불 러 와 분석 합 니 다.
GC 가 동적 으로 실행 되 는 것 을 보기 위해 서 는 JVisualVM 을 시작 하고 Visual GC 플러그 인 을 설치 하 십시오.다음은 응용 프로그램의 GC 를 볼 수 있 습 니 다.행동 은 다음 과 같 습 니 다.
GC 를 응용 하 는 요 구 를 이해 하려 면 대표 적 이 고 반복 적 으로 실행 할 수 있 는 부하 테스트 가 필요 하 다.모든 수집 기 가 어떻게 작 동 하 는 지 이해 함 에 따라 서로 다른 설정 을 통 해 부하 테스트 를 실행 하여 원 하 는 스루풋 과 지연 에 이 를 때 까지 합 니 다.최종 사용자 의 시각 에서 볼 때 측정 지연 이 가장 중요 하 다.모든 테스트 요청 의 응답 시간 을 포착 하여 직사 도 에 기록 할 수 있 습 니 다.예 를 들 어HdrHistogram또는Disruptor Histogram를 통 해 더 많은 것 을 분석 할 수 있 습 니 다.지연 피크 가 수용 가능 한 범 위 를 넘 으 면 GC 로그 와 관련 하여 문제 가 있 는 지 판단 해 볼 수 있 습 니 다.다른 문제 로 인 한 지연 의 절정 일 수도 있다.또 다른 고려 해 야 할 도 구 는jHiccupJVM 의 일시 정 지 를 추적 할 수 있 고 시스템 과 하나 가 될 수 있다 는 것 이다.jHiccup을 사용 하여 몇 시간 동안 빈 시스템 을 측정 하면 보통 놀 라 운 결 과 를 얻 을 수 있다.
지연 피크 가 GC 로 인 한 것 이 라면 CMS 나 G1 이 지연 목 표를 만족 시 킬 수 있 는 지 살 펴 볼 수 있다.높 은 분배 율 과 승진 율 이 낮은 지연 요구 와 충돌 하기 때문이다.GC 조 우 는 높 은 기교 성 을 가 진 운동 으로 대상 의 분배 율 이나 대상 의 생명 주 기 를 줄 이기 위해 프로그램 을 수정 해 야 한다.시간,GC 자원 최적화 와 응용 프로그램의 수정 및 정통 성 을 저울질 해 야 한다 면 Jrockit Real Time 과 Azul Zing 같은 상업 적 인 동시 압축 JVM 을 구 매해 야 할 수도 있다.
원본 링크:  mechanical-sympathy  번역:  ImportNew.com  -  형 민 아.번역문 링크:  http://www.importnew.com/8352.html