운영 중인 Java G1 가비지 컬렉션

운영 중인 Java G1 가비지 컬렉션

Java 7은 기본적으로 새로운 G1 가비지 컬렉션을 사용하기 때문에 Java는 GC 포즈 시간을 "파괴"하지 않고 훨씬 더 큰 힙을 처리할 수 있습니까?실제 G1을 실전 가동에 실장해 본 사람이 있습니까, 어떤 경험이 있습니까?

공정하게 말하자면, 제가 본 유일한 GC 일시정지 시간은 워크스테이션보다 훨씬 더 큰 무더기 위에 있는 것입니다.질문을 명확히 하자면, G1은 수백 GB에 달하는 방대한 양의 게이트웨이를 열 것인가? TB?

60~70GB를 힙에 할당하고 언제든지 20~50GB를 사용하는 고부하 어플리케이션으로 테스트하고 있습니다.이런 종류의 어플리케이션에서는 마일리지가 다를 수 있다고 말하는 것은 절제된 표현입니다.Linux에서 JDK 1.6_22를 실행하고 있습니다.마이너 버전이 중요합니다.약 1.6_20 이전 G1에서는 랜덤 Null Pointer의 원인이 되는 버그가 있었습니다.예외입니다.

나는 그것이 당신이 대부분의 시간에 주는 일시정지 목표물 안에 잘 있다는 것을 알게 되었다.기본값은 100ms(0.1초)의 일시 중지이며, 그 절반(-XX:MaxGCPauseMillis=50)을 수행하도록 지시했습니다.그러나 메모리가 부족하면 패닉 상태에 빠지고 완전히 가비지 수집을 수행합니다.65GB의 경우 30초에서 2분 정도 걸립니다.(CPU의 개수는 큰 차이가 없을 것입니다.버스 속도에 의해 제한될 수 있습니다.)

CMS(기본 서버 GC는 아니지만 웹 서버 및 기타 실시간 애플리케이션용이어야 함)에 비해 일반적인 일시정지는 예측이 훨씬 쉽고 훨씬 짧습니다.지금까지는 CMS를 사용하는 것이 더 좋았습니다만, 24시간마다 몇 번밖에 볼 수 없기 때문에 랜덤일지도 모릅니다.현시점에서는 어느 쪽이 제 실가동 환경에 더 적합한지 잘 모르겠습니다만, 아마 G1이 될 것입니다.Oracle이 계속 조정한다면 G1이 최종적으로는 확실한 승자가 될 것이라고 생각합니다.

기존 가비지 컬렉터에 문제가 없다면 지금 당장 G1을 고려할 필요가 없습니다.GUI 애플리케이션 등 지연 시간이 짧은 애플리케이션을 실행하는 경우 MaxGCPauseMillis가 매우 낮게 설정되어 있는 G1이 가장 적합합니다.배치 모드 애플리케이션을 실행하고 있는 경우, G1에서는 아무것도 얻을 수 없습니다.

G1의 포인트는 최대 포즈 시간 목표를 지정할 수 있는 시점에서도 포즈 시간을 단축하는 것입니다.

쓰레기 수집은 단순히 "이봐, 꽉 찼어. 모든 것을 한 번에 옮기고 다시 시작하자"는 문제가 아닙니다. 더 이상 복잡한 다단계 백그라운드 스레드 시스템입니다.백그라운드에서 유지보수의 대부분을 일시정지 없이 수행할 수 있습니다.또, 대부분의 오브젝트가 생성된 직후에 정지한다고 가정하는 등, 시스템의 실행시에 예상되는 패턴에 대한 지식을 사용합니다.

GC의 포즈 시간은 향후 릴리즈에 따라 악화되지 않고 계속 개선될 것입니다.

편집:

재독해 보니, Java를 매일 사용하고 있다는 생각이 들었습니다.Eclipse, Azureus, 그리고 제가 개발한 앱은 오랜만의 일시정지입니다.큰 휴식은 아니지만, 전혀 휴식은 없어요.

Windows 탐색기를 마우스 오른쪽 버튼으로 클릭하거나 (가끔) 특정 USB 하드웨어를 연결할 때 일시 중지되는 경우가 있지만 Java에서는 전혀 없습니다.

GC는 아직 누구에게 문제가 있습니까?

저는 G1을 생산 테스트한 적은 없지만, GC는 "거대한" 무더기가 없는 케이스에 대해서는 이미 문제가 있다고 생각합니다.특히 GC에 의해 예를 들어 2GB 또는 4GB의 서비스만 있으면 심각한 영향을 받을 수 있습니다.젊은 세대의 GC는 보통 1자리 밀리초(또는 최대 2자리)로 끝나기 때문에 문제가 없습니다.그러나 구세대 컬렉션은 1GB 이상의 구세대 사이즈에서 몇 초가 걸리기 때문에 훨씬 더 문제가 있습니다.

이론적으로 CMS는 대부분의 작업을 동시에 실행할 수 있기 때문에 많은 도움이 됩니다.하지만, 시간이 지나면, 이것을 할 수 없게 되어, 「세상을 멈추기 위해서」라고 하는 형태로 되돌아가는 경우가 생길 것입니다.그리고 그런 일이 일어났을 때(예를 들어, 1시간 후, 자주는 아니지만, 너무 자주)에는, 음, 여러분의 f***** 모자를 꼭 잡으세요.1분 또는 그 이상 걸릴 수 있습니다.이는 최대 지연 시간을 제한하려는 서비스의 경우 특히 문제가 됩니다.예를 들어 요청을 처리하는 데 25밀리초가 걸리는 대신 10초 이상이 소요됩니다.클라이언트에 대한 모욕으로 인해 추가 피해를 입히면 요청 시간이 초과되고 재시도되는 경우가 많아 더 많은 문제(일명 '똥 폭풍')가 발생합니다.

이것은 G1이 많은 도움을 주길 바랐던 한 분야이다.저는 스토리지와 메시지 디스패치용 클라우드 서비스를 제공하는 대기업에서 근무했습니다.CMS는 병렬 변종보다 더 잘 작동했지만 CMS는 거의 사용되지 않았습니다.그래서 한 시간 정도는 괜찮았는데, 그리고 나서 팬에 부딪혔어.또한 서비스가 클러스터에 기반했기 때문에 한 노드에 문제가 발생했을 때 다른 노드가 그 뒤를 따랐습니다(GC에 의한 타임아웃이 다른 노드로 이어지면서 노드가 크래쉬하여 재루팅이 이루어지기 때문입니다).

GC는 앱에 큰 문제가 되지 않으며, 비클러스터 서비스도 영향을 덜 받을 수 있습니다.그러나 점점 더 많은 시스템이 클러스터화되고(특히 NoSQL 데이터스토어 덕분에) 힙 크기가 커지고 있습니다.OldGen GC는 히프사이즈와 초선형적으로 관련되어 있습니다(라이브 데이터 세트의 사이즈도 2배로 증가한다고 가정하면 히프사이즈가 2배로 증가한다는 것을 의미합니다).

Azul의 CTO인 Gil Tene는 "Java Garbage Collection에 대하여"와 "What You Can Do about It"의 프레젠테이션에서 가비지 컬렉션과 관련된 문제에 대한 개요와 다양한 솔루션에 대한 리뷰를 소개하고 있습니다.이 기사에는 자세한 내용이 기재되어 있습니다.http://www.infoq.com/articles/azul_gc_in_detail

Zing JVM에 탑재된 Azul의 C4 가비지 컬렉터는 병렬 및 동시이며, 신세대와 구세대 모두에서 동일한 GC 메커니즘을 사용하여 동시에 작동하고 압축됩니다.가장 중요한 것은, C4에는 지구에서의 폴백이 없다는 것입니다.모든 압축은 실행 중인 애플리케이션과 동시에 수행됩니다.고객님은 매우 큰 (수백 GB의) GC 포즈 시간을 10 밀리초 미만으로 하여 어플리케이션에 따라서는 1 ~2 밀리초 미만인 경우가 많습니다.

CMS와 G1의 문제는 어느 시점에서 Java 힙메모리를 압축해야 하며, 이러한 가비지 컬렉터는 모두 압축을 수행하기 위해 월드/STW를 중지합니다(즉, 애플리케이션을 일시 중지합니다).따라서 CMS와 G1은 STW의 일시 정지를 밀어낼 수 있지만 이를 제거하지는 않습니다.그러나 Azul의 C4는 STW의 일시정지를 완전히 없애기 때문에 Zing은 거대한 힙 사이즈에서도 GC의 일시정지가 매우 낮은 것입니다.

또한 이전 답변의 내용을 수정하기 위해 Zing은 운영체제를 변경할 필요가 없습니다.수정되지 않은 Linux Distros에서 다른 JVM과 동일하게 실행됩니다.

우리는 이미 G1GC를 거의 2년 전부터 사용하고 있다.델의 미션 크리티컬 트랜잭션 처리 시스템에서 뛰어난 성능을 발휘하여 높은 throughput, 낮은 일시정지, 동시성 및 최적화된 대용량 메모리 관리 기능을 갖춘 뛰어난 지원임이 입증되었습니다.

다음 JVM 설정을 사용하고 있습니다.

-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

갱신필

-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000

G1 컬렉터는 풀 컬렉션의 영향을 줄입니다.이미 풀 컬렉션의 필요성을 줄인 어플리케이션이 있는 경우 Concurrent map sweep 컬렉터도 마찬가지로 좋고 내 경험상 마이너 수집 시간도 짧습니다.

나는 최근에 이사했다.

4G 히프와 8코어 프로세서를 탑재한 CMS에서 G1GC로의 이행(JDK 1.7.45 탑재 서버).

(JDK 1.8.x G1GC는 1.7보다 권장되지만 몇 가지 제한으로 인해 1.7.45 버전을 유지해야 합니다.)

키 파라미터보다 낮게 설정하고 다른 파라미터는 모두 디폴트값으로 유지하고 있습니다.

-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n apart from -Xms and -Xmx

이러한 파라미터를 미세 조정하려면 이 Oracle 문서를 참조하십시오.

주요 관찰 사항:

1. 메모리 사용량은 G1GC와 일관성이 있으며 CMS의 고저와 달리
2. CMS에 비해 최대 GC 일시정지 시간이 짧다
3. G1GC에서는 CMS에 비해 가비지 컬렉션에 소비하는 시간이 약간 길다.
4. 주요 컬렉션의 수는 CMS에 비해 거의 무시할 수 있습니다.
5. 마이너 컬렉션의 수는 CMS에 비해 높은 편이다.

그러나 Max GC pause time이 CMS보다 적어서 다행입니다. Max GC pause time을 1.5초로 설정했고 이 값은 아직 초과되지 않았습니다.

관련 SE 질문:

G1에서의 Java 7(JDK 7) 가비지 수집 및 문서

JDK7u4 를 기동하는 G1 이 정식으로 서포트되고 있는 것 같습니다.RN for JDK7u4 http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html 를 참조해 주세요.

대규모 JVM에 대한 테스트에서는 조정된 CMS가 G1보다 더 잘 작동하지만 더 잘 성장할 것으로 예상됩니다.

CMS는 테넌트 개체를 누적하지 않고 실행 중인 경우에도 성능이 느리게 저하될 수 있습니다.이것은, G1이 회피하고 있다고 생각되는 메모리 플래그멘테이션에 의한 것입니다.

유상 지원이 있어야만 가능한 G1에 대한 속설은 그저 신화일 뿐이다.Sun과 현재 Oracle은 JDK 페이지에서 이를 명확히 하고 있습니다.

G1 GC가 더 잘 작동해야 합니다.그러나 -XX:MaxGCPauseMillis를 너무 적극적으로 설정하면 가비지 수집 속도가 너무 느려집니다.그래서 데이비드 레픽의 예에서 풀 GC가 트리거된 것입니다.

저는 방금 테라코타 빅 메모리 프로젝트에서 G1 가비지 컬렉터를 구현했습니다.G1은 다양한 유형의 수집기를 작업하면서 600ms 미만의 응답 시간으로 최고의 결과를 얻었습니다.

테스트 결과(총 26개)는 여기에서 확인할 수 있습니다.

도움이 됐으면 좋겠다.

최근 Twicsy의 일부를 128GB RAM을 탑재한 새로운 서버로 이행하여 1.7을 사용하기로 결정했습니다.처음에 1.6에서 사용한 것과 동일한 메모리 설정(500MB의 히프를 최대 15GB까지 실행하는 여러 인스턴스가 있고 현재 40GB의 새로운 인스턴스가 실행 중)을 사용했지만 전혀 잘 되지 않았습니다. 1.7은 1.6보다 더 많은 히프를 사용하는 것 같았고 처음 며칠 동안 많은 문제를 경험했습니다.다행히 작업할 수 있는 RAM이 많아서 대부분의 프로세스에서 RAM을 증설했지만 여전히 문제가 있었습니다.통상적인 MO는 16m의 매우 작은 최소 힙사이즈를 사용하여 최대 힙을 수 기가바이트까지 사용하다가 증분 GC를 켜는 것이었습니다.이것에 의해, 일시 정지를 최소한으로 억제할 수 있었습니다.하지만 지금은 이 기능이 작동하지 않고 최소 크기를 평균 힙에서 사용할 수 있는 크기로 늘려야 했습니다. 이 기능은 매우 잘 작동했습니다.증분 GC는 아직 켜져 있지만 사용하지 않고 시도합니다.지금은 조금도 멈추지 않고, 일이 매우 빠르게 진행되는 것 같다.그래서 이 이야기의 교훈은 기억 설정이 1.6에서 1.7로 완벽하게 번역되기를 기대하지 않는 것이라고 생각합니다.

G1은 애플리케이션의 민첩성을 크게 향상시킵니다. 즉, 애플리케이션의 지연이 높아집니다. 즉, 애플리케이션의 이름은 "소프트 리얼 타임"으로 지정될 수 있습니다.이는 2종류의 GC 실행(작은 GC 실행과 큰 Gen 실행)을 동일한 크기의 작은 GC 실행으로 대체함으로써 이루어집니다.

상세한 것에 대하여는, http://geekroom.de/java/java-expertise-g1-fur-java-7/ 를 참조해 주세요.

저는 Java를 사용하여 소규모 및 대규모 힙에 대해 작업하고 있습니다.GC와 Full GC에 대한 질문은 매일 표시됩니다.특정 환경에서는 0.1초의 Scavenger GC 또는 Full GC를 사용하는 것이 중요합니다(CMS, iCMS 등).목표는 거의 실시간 처리로 가능한 최고의 응답 시간을 가지기 위해 여기에 있습니다(여기서 실시간 처리 시간은 종종 25 ms입니다). 그래서 기본적으로 GC 인체공학 및 휴리스틱의 개선은 환영입니다!

Java 8과 Groovy(Java 8도)에서 G1GC를 사용하고 있으며, 다양한 종류의 워크로드를 수행하고 있으며, 전체적으로 G1GC는 다음과 같이 동작합니다.

• 메모리 사용량이 매우 적습니다(기본 Java 설정에 비해 500MB가 아닌 100MB 등).

• 응답 시간이 일정하고 매우 짧습니다.

• G1GC를 최악의 경우(튜닝 없이 싱글 스레드 애플리케이션 사용) 디폴트 설정과 G1GC 사이의 퍼포먼스는 20% 저하됩니다.응답 시간이 좋고 메모리 사용량이 적은 것을 고려하면 그다지 큰 문제는 아닙니다.

• 멀티 스레드인 Tomcat에서 실행하면 전체 성능이 30% 향상되고 메모리 사용률이 크게 낮아지며 응답 시간도 크게 단축됩니다.

따라서 전반적으로 다양한 워크로드를 사용하는 경우 G1GC는 멀티스레드 애플리케이션용 Java 8에 매우 적합합니다.또한 싱글스레드 애플리케이션에도 몇 가지 이점이 있습니다.

핫스팟과 같은 JVM을 사용한 부동소수점 계산에는 java8 w/G1GC를 사용하지 않는 것이 좋습니다.애플리케이션의 정합성과 정확성에 위험합니다.

https://bugs.openjdk.java.net/browse/JDK-8148175

JDK-8165766

JDK-8186112

언급URL : https://stackoverflow.com/questions/2254041/java-g1-garbage-collection-in-production