[java] 프로덕션에서 Java G1 가비지 수집

프로덕션에서 G1을 테스트하지는 않았지만 GC가 “엄청난”힙이없는 케이스에 대해 이미 문제가 있다고 생각했습니다. 특히 2 또는 4 기가 만있는 서비스는 GC에 의해 심각한 영향을받을 수 있습니다. 젊은 세대의 GC는 일반적으로 한 자릿수 밀리 초 (또는 최대 두 자릿수)로 끝나므로 문제가되지 않습니다. 그러나 구세대 컬렉션은 1 기가 이상의 구세대 크기로 몇 초가 걸리기 때문에 훨씬 더 문제가 많습니다.

이제 : 이론상 CMS는 대부분의 작업을 동시에 실행할 수 있으므로 많은 도움이 될 수 있습니다. 그러나 시간이 지남에 따라이를 수행 할 수없고 “세상을 중지”컬렉션으로 돌아 가야하는 경우가 있습니다. 그리고 그 일이 발생하면 (예를 들어, 1 시간 후-자주는 아니지만 너무 자주), 글쎄, 당신의 빌어 먹을 모자를 붙잡 으십시오. 1 분 이상 걸릴 수 있습니다. 이는 최대 대기 시간을 제한하려는 서비스에서 특히 문제가됩니다. 요청을 처리하는 데 25 밀리 초가 걸리는 대신 이제 10 초 이상이 걸립니다. 모욕에 상처를 입히기 위해 클라이언트는 종종 요청 시간을 초과하고 재 시도하여 추가 문제 (일명 “똥 폭풍”)로 이어집니다.

이것은 G1이 많은 도움을 주길 바랬던 영역입니다. 저는 스토리지 및 메시지 발송을위한 클라우드 서비스를 제공하는 대기업에서 일했습니다. 그리고 우리는 CMS를 사용할 수 없었습니다. 대부분의 경우 병렬 품종보다 더 잘 작동했지만 이러한 붕괴가 있었기 때문입니다. 그래서 약 한 시간 동안 일이 좋았습니다. 그런 다음 물건이 팬에 부딪 혔습니다. 서비스가 클러스터를 기반으로했기 때문에 한 노드가 문제가 발생했을 때 다른 노드가 일반적으로 뒤따 랐습니다 (GC로 인한 시간 초과로 인해 다른 노드가 노드가 충돌 한 것으로 믿고 경로를 다시 지정하기 때문입니다).

나는 GC가 앱의 문제라고 생각하지 않으며 클러스터되지 않은 서비스조차도 영향을 덜받는다고 생각합니다. 그러나 점점 더 많은 시스템이 클러스터링되고 (특히 NoSQL 데이터 저장소 덕분에) 힙 크기가 증가하고 있습니다. OldGen GC는 힙 크기와 매우 선형 적으로 관련되어 있습니다 (즉, 힙 크기를 두 배 이상 늘리면 GC 시간이 두 배가되고 라이브 데이터 세트의 크기도 두 배가된다고 가정).