>백엔드 개발 >Golang >Go 1.5의 Garbage Collector는 테라바이트 규모의 메모리 관리를 지원하나요?

Go 1.5의 Garbage Collector는 테라바이트 규모의 메모리 관리를 지원하나요?

DDD
DDD원래의
2024-11-30 14:26:12431검색

Is Go 1.5's Garbage Collector Ready for Terabyte-Scale Memory Management?

테라바이트 RAM을 탑재한 Go 1.5 GC는 얼마나 빠릅니까?

배경:

Java는 GC 중단 시간 A에 직면합니다. 너무 긴 병목 현상은 테라바이트 규모의 메모리를 효과적으로 활용할 수 없습니다. Go GC가 최적화되어 있기 때문에 사람들은 테라바이트급 메모리 환경에서 충분히 짧은 GC 중단 시간을 달성할 수 있는지 궁금해하지 않을 수 없습니다.

질문:

  • Go 1.5 GC가 테라바이트급 메모리를 처리할 준비가 되었나요?
  • 관련 벤치마크가 있나요?
  • 이렇게 큰 메모리를 관리하기 위해 GC에 언어를 사용할 수 있나요?

정답:

포인트:

  • 현재 단일 Go 프로세스는 테라바이트 단위의 용량을 사용할 수 없습니다. 메모리 . Linux의 최대 제한은 512GB이지만 실제 테스트에서 기록된 최고치는 240GB에 불과합니다.
  • 현재 백그라운드 GC 모드에서는 GC 작업 부하가 GC 중단 시간보다 더 중요한 경우가 많습니다.
  • 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 인터럽트 시간보다 더 중요합니다.

일반 관찰:

  • GC의 수집 빈도는 메모리 사용 속도에 따라 다릅니다.
  • 각 GC 컬렉션이 수행하는 작업량은 부분적으로 사용 중인 포인터 수에 따라 달라집니다. (슬라이스, 인터페이스 값, 문자열 등의 포인터 포함)

즉, 애플리케이션이 많은 메모리에 액세스하더라도 포인터 수가 적으면(예: 상대적으로 적은 [] 바이트 버퍼) 및 할당 속도가 낮습니다(예를 들어 메모리 오버플로가 가장 발생하기 쉬운 시나리오에서 메모리를 재사용하기 위해 sync.Pool이 적용되기 때문에) GC 문제가 존재하지 않을 수 있습니다.

따라서 수백 GB의 힙이 있는 대형 컴퓨터를 고려하고 있고 본질적으로 GC에 적합하지 않은 경우 다음 옵션을 고려하는 것이 좋습니다.

  1. C 또는 이와 유사한 것을 사용하세요. 언어 쓰기
  2. 는 예를 들어 내장된 데이터베이스로 관리하기 위해 객체 그래프 밖으로 많은 양의 데이터를 이동합니다. Bolt)를 외부 데이터베이스 서비스에 추가하거나 데이터베이스보다 더 많은 캐싱 기능이 필요한 경우 groupcache 또는 memcache와 같은 캐싱 도구를 사용할 수 있습니다.
  3. 하나의 큰 프로세스 대신 작은 힙을 사용하는 일련의 프로세스를 실행합니다.
  4. 메모리 문제를 방지하기 위해 신중하게 프로토타입을 제작하고 테스트하고 최적화했습니다.

위 내용은 Go 1.5의 Garbage Collector는 테라바이트 규모의 메모리 관리를 지원하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.