장기 실행 애플리케이션에서의 CEF/Chromium 메모리 사용

왜 메모리가 지속적으로 높게 유지되는가

렌더링이 완료된 후 메모리를 유지하는 두 가지 명확한 메커니즘이 있습니다.

Chromium 네이티브 할당자 유지: Chromium은 .NET 가비지 수집기 외부에서 관리되지 않는 메모리를 많이 사용합니다. 렌더링이 완료되면 Chromium은 종종 그 네이티브 메모리를 즉시 OS에 반환하지 않고 재사용을 위해 예약 상태로 유지합니다. 따라서 PdfDocument 객체는 올바르게 폐기될 수 있으며, 런타임은 관리 객체를 수집할 수 있고, 전체 프로세스 또는 컨테이너 메모리는 여전히 높게 읽힐 수 있습니다. Chromium 기반 엔진에 대해 정상적인 현상입니다.

BrowserPool 탭 재사용: IronPDF는 다음 렌더링이 더 빠르게 시작되도록 렌더링 후 유휴 브라우저 탭을 유지할 수 있습니다. 그 탭들은 렌더러 하위 프로세스와 DOM 상태를 짧은 시간 동안 유지하여 렌더링 중이 아닐 때도 눈에 띄는 메모리 기준선을 만듭니다. 풀링이 켜진 상태에서는 렌더링 중 메모리가 상승하고, 완료 후 기준치에 도달하며, 유휴 탭이 시간 초과되고 수집됨에 따라 단계적으로 감소하는 것이 일반적입니다.

BrowserPool 기본값

IronPDF는 성능 향상을 위해 렌더링 사이에 소수의 탭을 따뜻한 상태로 유지합니다. 기본값은 다음과 같습니다:

• BrowserPool.Enabled = true
• BrowserPool.MaxIdleTabs = min(max(ProcessorCount / 2, 1), 4)
• BrowserPool.IdleTimeoutSeconds = 30

이로 인해 활성 렌더링이 없더라도 프로세스는 1~4개의 유휴 탭을 잠시 동안 살아있게 유지하며, 이러한 탭은 유휴 시간 초과가 만료될 때까지 네이티브 메모리와 하위 프로세스 리소스를 보유합니다. 렌더링한 콘텐츠와 환경에 따라 유휴 탭은 상당량의 메모리를 유지할 수 있으며, 일부 작업에서는 대략 50~100MB에 이를 수 있습니다. 마지막 렌더링 후 약 30초간 그 상향된 기준선이 지속될 수 있으며 이후 단계적으로 감소합니다.

해결책

환경이 메모리 제약이 있다면 BrowserPool 설정을 첫 번째로 조정해야 합니다. 기본값은 다음과 같이 보입니다:

renderer.RenderingOptions.BrowserPool.Enabled = true; // default
renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 2; // default is CPU/2, clamped to 1-4
renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 30; // default

renderer.RenderingOptions.BrowserPool.Enabled = true; // default
renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 2; // default is CPU/2, clamped to 1-4
renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 30; // default

renderer.RenderingOptions.BrowserPool.Enabled = false;

renderer.RenderingOptions.BrowserPool.Enabled = false;

renderer.RenderingOptions.BrowserPool.Enabled = False

renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 0;

renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 0;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10

장기 실행 애플리케이션을 위한 전략

애플리케이션이 메모리를 지속적으로 낮게 유지해야 하는 경우, 프로세스 재활용에 도달하기 전에 BrowserPool 조정부터 시작하여 차례로 이 과정을 진행하십시오.

private static readonly SemaphoreSlim RenderSemaphore = new(2);
public async Task<t> RunRenderAsync<t>(Func<t> renderWork)
{
    await RenderSemaphore.WaitAsync();
    try
    {
        return renderWork();
    }
    finally
    {
        RenderSemaphore.Release();
    }
}

private static readonly SemaphoreSlim RenderSemaphore = new(2);
public async Task<t> RunRenderAsync<t>(Func<t> renderWork)
{
    await RenderSemaphore.WaitAsync();
    try
    {
        return renderWork();
    }
    finally
    {
        RenderSemaphore.Release();
    }
}

Imports System.Threading

Private Shared ReadOnly RenderSemaphore As New SemaphoreSlim(2)

Public Async Function RunRenderAsync(Of T)(renderWork As Func(Of T)) As Task(Of T)
    Await RenderSemaphore.WaitAsync()
    Try
        Return renderWork()
    Finally
        RenderSemaphore.Release()
    End Try
End Function

누수일 수 있는 경우

렌더링 후 메모리가 상승하는 것은 자동적으로 누수를 의미하지 않습니다. Chromium 기반 렌더링에는 이해해야 할 두 가지 종류의 재사용이 있습니다: 할당자 수준의 재사용, Chromium이 내부적으로 네이티브 메모리 페이지를 예약하는 경우(정상적이며 직접적인 제어가 불가능함), 탭 수준의 재사용, BrowserPool이 렌더 간 전체 탭을 살아 있게 유지하는 경우(구성 가능하며 대부분 모니터링 도구에서 보는 것의 큰 기여자임).

대부분의 경우 메모리가 렌더링 중 상승하고, 무한히 증가하지 않고 안정화되며, 이후 유휴 탭이 시간 초과되거나 다음 렌더를 위해 사용 가능한 상태로 유지되어야 하는 것이 예상됩니다.

다음과 같은 경우 추가 조사가 필요합니다:

• 유사한 작업 부하 하에서 메모리가 안정화되지 않고 계속 증가하는 경우
• 동시 실행을 줄인 후에도 메모리가 계속 증가하는 경우
• 기억은 브라우저 풀을 비활성화하거나 MaxIdleTabs = 0을 설정한 후에도 계속 증가합니다.
• 제어된 입력으로 오랜 시간 동안 동일한 패턴을 보여주는 최소 재현 사례인 경우

지원에 문의해야 할 때

다음을 모두 재현할 수 있는 경우 기술 지원에 문의하십시오:

1. 제어된 작업 부하 아래서 메모리가 안정화되지 않고 계속 증가하는 경우
2. 동시 실행을 제한한 후에도 문제가 지속되는 경우
3. 브라우저 풀을 비활성화하거나 MaxIdleTabs = 0을 설정한 후에도 문제가 지속됩니다.
4. 최소 샘플 프로젝트로 재현할 수 있는 경우

티켓을 개설할 때, IronPDF 버전, OS 및 호스팅 환경, Docker나 Kubernetes 세부사항이 적용될 경우, 사용 프로그래밍 언어, 렌더링 빈도 및 동시 실행 수준, 메모리 그래프나 모니터링 스크린샷, 최소 재현 가능 사례를 포함하십시오.