워크스테이션 및 서버 가비지 수집

가비지 수집기는 자체 튜닝이며 다양한 시나리오에서 작동할 수 있습니다. 그러나 워크로드의 특성에 따라 가비지 수집 유형을 설정할 수 있습니다. CLR은 다음과 같은 유형의 가비지 수집을 제공합니다.

클라이언트 앱을 위해 설계된 워크스테이션 가비지 수집(GC)입니다. 독립 실행형 앱의 기본 GC 버전입니다. 호스트된 앱(예: ASP.NET 호스트된 앱)의 경우 호스트는 기본 GC 버전을 결정합니다.

워크스테이션 가비지 수집은 동시 또는 비동기일 수 있습니다. 동시(또는 백그라운드) 가비지 수집을 사용하면 관리되는 스레드가 가비지 수집 중에 작업을 계속할 수 있습니다. 백그라운드 가비지 수집 은 .NET Framework 4 이상 버전에서 동시 가비지 수집 을 대체합니다.
높은 처리량과 확장성이 필요한 서버 애플리케이션을 위한 서버 가비지 수집입니다.
- .NET Core에서 서버 가비지 수집은 비동기 또는 백그라운드일 수 있습니다.
- .NET Framework 4.5 이상 버전에서 서버 가비지 수집은 비동기 또는 백그라운드일 수 있습니다. .NET Framework 4 및 이전 버전에서는 서버 가비지 수집이 동시적이지 않습니다.

다음 그림에서는 서버에서 가비지 수집을 수행하는 전용 스레드를 보여 줍니다.

서버 쓰레기 수집 스레드

성능 고려 사항

다음은 워크스테이션 가비지 수집에 대한 스레드 및 성능 고려 사항입니다.

컬렉션은 가비지 수집을 트리거한 사용자 스레드에서 발생하며 동일한 우선 순위로 유지됩니다. 사용자 스레드는 일반적으로 정상 우선 순위로 실행되므로 가비지 수집기(일반 우선 순위 스레드에서 실행)는 CPU 시간 동안 다른 스레드와 경쟁해야 합니다. (네이티브 코드를 실행하는 스레드는 서버 또는 워크스테이션 가비지 수집에서 일시 중단되지 않습니다.)
워크스테이션 가비지 수집은 구성 설정에 관계없이 논리 CPU가 하나만 있는 컴퓨터에서 항상 사용됩니다.

다음은 서버 가비지 수집에 대한 스레딩 및 성능 고려 사항입니다.

컬렉션은 여러 전용 스레드에서 발생합니다. Windows에서 이러한 스레드는 우선 순위 수준에서 실행됩니다 THREAD_PRIORITY_HIGHEST .
각 논리 CPU에 대해 가비지 수집을 수행하는 전용 스레드와 수집 대상 힙이 제공되며, 모든 힙은 동시에 수집됩니다. 각 힙에는 작은 개체 힙과 큰 개체 힙이 포함되며 모든 힙은 사용자 코드로 액세스할 수 있습니다. 다른 힙에 있는 객체는 서로 참조 가능하다.
여러 가비지 수집 스레드가 함께 작동하므로 서버 가비지 수집은 동일한 크기 힙의 워크스테이션 가비지 수집보다 빠릅니다.
서버 가비지 컬렉션은 종종 더 큰 크기의 세그먼트를 포함합니다. 그러나 이는 일반화일 뿐입니다. 세그먼트 크기는 구현에 따라 달라지고 변경될 수 있습니다. 앱을 튜닝할 때 가비지 수집기가 할당한 세그먼트의 크기를 가정하지 마세요.
서버 가비지 수집은 리소스를 많이 사용할 수 있습니다. 예를 들어 4개의 논리 CPU가 있는 컴퓨터에서 실행되는 서버 GC를 사용하는 프로세스가 12개 있다고 상상해 보세요. 모든 프로세스가 동시에 가비지를 수집하는 경우 동일한 논리 CPU에 예약된 12개의 스레드가 있기 때문에 서로 간섭합니다. 프로세스가 활성 상태인 경우 모두 서버 GC를 사용하도록 하는 것은 좋지 않습니다.

수백 개의 애플리케이션 인스턴스를 실행하는 경우 동시 가비지 수집을 사용하지 않도록 설정한 상태에서 워크스테이션 가비지 수집을 사용하는 것이 좋습니다. 이로 인해 컨텍스트 전환이 줄어들어 성능이 향상될 수 있습니다.