배경:
Java는 GC 중단 시간 A에 직면합니다. 너무 긴 병목 현상은 테라바이트 규모의 메모리를 효과적으로 활용할 수 없습니다. Go GC가 최적화되어 있기 때문에 사람들은 테라바이트급 메모리 환경에서 충분히 짧은 GC 중단 시간을 달성할 수 있는지 궁금해하지 않을 수 없습니다.
질문:
정답:
포인트:
세부정보:
Go 힙의 제한은 512GB이며 실제 테스트된 최대 힙 크기는 240GB입니다.
Go 1.5 GC는 GC 작업을 줄이는 것이 아니라 GC 중단 시간을 줄이기 위해 설계되었습니다. GC가 전역 변수의 스택과 포인터를 검색하는 동안 코드가 중단됩니다.
GopherCon 2015 강연의 차트에 따르면 1.5 GC는 다음과 같이 최대 18GB 힙의 GC 벤치마크에서 중단 시간이 더 짧습니다.
[차트: GC 중단 시간 힙과의 관계 크기, 버전 1.5에서 개선됨]
실제 애플리케이션에서 일부 원래 GC 중단 시간은 300ms의 프로세스 보고서는 4ms와 20ms로 떨어졌고, 다른 애플리케이션에서는 95번째 백분위수 GC 시간이 279ms에서 10ms로 보고되었습니다.
Go 1.6은 더욱 최적화되었으며 백그라운드에서 일부 작업을 수행합니다. 결과적으로 힙 크기가 200GB를 초과하더라도 테스트의 최대 인터럽트 시간은 다음 그림과 같이 여전히 20ms입니다.
[차트: 1.6 GC 시간은 힙 크기에 따라 변경되어 약 20ms에 도달합니다. 180GB]
버전 1.6에서는 힙 크기가 약 8GB이고 애플리케이션이 분당 약 150M을 할당합니다. 20ms가 3-4ms로 단축되었습니다.
Twitch는 Go를 사용하여 채팅 서비스를 실행하며 버전 1.7에서는 많은 수의 코루틴을 동시에 실행하면서 일시 중지 시간이 1ms로 단축되었다고 보고합니다.
1.8 스택 스캔을 stop-the-world 단계에서 벗어나 대규모 힙에서도 대부분의 인터럽트 시간을 1ms 미만으로 유지합니다. 초기 테스트 결과는 양호한 상태를 나타냅니다. 때로는 애플리케이션에 코루틴을 인터럽트하기 어렵게 만드는 코드 패턴이 여전히 있어 다른 모든 스레드의 인터럽트 시간을 효과적으로 연장하지만 일반적으로 GC의 전반적인 백그라운드 작업이 GC 인터럽트 시간보다 더 중요합니다.
일반 관찰:
즉, 애플리케이션이 많은 메모리에 액세스하더라도 포인터 수가 적으면(예: 상대적으로 적은 [] 바이트 버퍼) 및 할당 속도가 낮습니다(예를 들어 메모리 오버플로가 가장 발생하기 쉬운 시나리오에서 메모리를 재사용하기 위해 sync.Pool이 적용되기 때문에) GC 문제가 존재하지 않을 수 있습니다.
따라서 수백 GB의 힙이 있는 대형 컴퓨터를 고려하고 있고 본질적으로 GC에 적합하지 않은 경우 다음 옵션을 고려하는 것이 좋습니다.
위 내용은 Go 1.5의 Garbage Collector는 테라바이트 규모의 메모리 관리를 지원하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!