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

Updated: 2026년 9월 17일

IronPDF는 Chromium과 함께 렌더링되므로, 문서가 폐기되고 GC.Collect()이 실행되더라도 PDF 생성 후에 프로세스 메모리가 짧은 시간 동안 높게 유지될 수 있습니다. 두 가지 소스가 동시에 작용합니다: Chromium의 관리되지 않는 네이티브 할당자와 IronPDF의 브라우저 탭 풀링. 대부분의 경우 이것은 예상되는 사항이며 자동으로 메모리 누수를 의미하지 않습니다.

이는 IronPDF와 IronPdfEngine에 적용되며, Windows와 Linux, Docker, Kubernetes, VM 및 서버 호스팅 환경 전반에 걸쳐, Chromium 기반 렌더링을 사용하는 .NET, Java 및 기타 애플리케이션에 적용됩니다.

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

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

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

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

`GC.Collect()`가 도움이 되지 않는 이유

GC.Collect()은 관리되는 .NET 메모리만 회수합니다. Chromium이 네이티브 메모리를 OS에 반환하도록 강제하지 않으며, 재사용을 위해 의도적으로 살아 있게 유지되는 따뜻한 BrowserPool 탭을 제거하지 않습니다. 정확한 폐기와 강제 수집이 있더라도 작업 관리자, Docker, Kubernetes 또는 New Relic과 같은 도구에서 표시하는 수치는 즉시 감소하지 않을 수 있습니다.

이 효과는 장기 실행 애플리케이션, 공유 서비스 환경 및 Docker나 Kubernetes 배포에서 가장 두드러집니다. Java 통합에서 IronPdfEngine를 사용하는 경우, 압력은 보통 JVM 힙보다는 엔진 프로세스나 컨테이너에 나타납니다.

BrowserPool 기본값

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

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

이로 인해 활성 렌더링이 없더라도 프로세스는 14개의 유휴 탭을 잠시 동안 살아있게 유지하며, 이러한 탭은 유휴 시간 초과가 만료될 때까지 네이티브 메모리와 하위 프로세스 리소스를 보유합니다. 렌더링한 콘텐츠와 환경에 따라 유휴 탭은 상당량의 메모리를 유지할 수 있으며, 일부 작업에서는 대략 50100MB에 이를 수 있습니다. 마지막 렌더링 후 약 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

옵션 1: 탭 풀링을 완전히 비활성화하기

각 렌더링 후에 가장 결정적인 정리를 원할 때 이 옵션을 선택하십시오.

renderer.RenderingOptions.BrowserPool.Enabled = false;

renderer.RenderingOptions.BrowserPool.Enabled = false;

옵션 2: BrowserPool을 활성화 상태로 유지하면서 유휴 탭을 보유하지 않기

기능을 유지하되 렌더링 간 따뜻한 탭을 유지하는 것을 피하여 렌더링 별 결정적인 정리를 제공합니다.

renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 0;

renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 0;

옵션 3: 유휴 시간 초과 줄이기

중간 길: 일부 재사용 혜택을 유지하되 버스트 트래픽 후 메모리를 더 빨리 떨어뜨립니다.

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

선택하는 기준:

Enabled = false: 메모리 안정성이 빠른 시작 성능보다 더 중요합니다.
MaxIdleTabs = 0: 기능을 완전히 비활성화하지 않고도 결정론적인 렌더당 정리가 필요합니다.
더 낮은 IdleTimeoutSeconds: 작업 부하는 버스트로 도착하며, 각 처리 후 메모리가 더 빨리 회수되기를 원합니다.

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

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

1. 동시 렌더링 제한하기

여러 Chromium 렌더 작업이 동시에 실행되면 네이티브 메모리 압력이 급격히 증가합니다. 병렬로 렌더링하는 경우, 세마포를 사용하여 동시에 실행되는 최대 수를 제한하십시오:

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();
    }
}

정해진 수의 작업만 실행되도록 철저한 섹션 내에서 IronPDF 렌더 호출을 감쌉니다.

2. BrowserPool 조정하거나 비활성화하기

많은 메모리 민감 배포에 대해 이것은 가장 효과적인 첫 번째 단계입니다. BrowserPool을 완전히 비활성화하거나, MaxIdleTabs = 0을 설정하거나, 버스트 작업 부하에 대해 IdleTimeoutSeconds을 낮추세요. 이들 중 어느 것을 사용하든 전체 재시작 전략 없이 지속 가능한 포스트 렌더 기준선을 줄일 수 있습니다.

3. 별도의 작업자에서 렌더링 격리하기

PDF 렌더링을 메인 애플리케이션 외부로 이동하는 것은 생산 시스템에서 강력한 패턴입니다. 메인 앱은 안정적이며, 렌더링 작업자는 자체적으로 재시작할 수 있으며, 해당 작업자가 종료되면 네이티브 Chromium 메모리가 완전히 해제됩니다. 재활용에 의존하기 전에, 브라우저 풀을 비활성화하거나 MaxIdleTabs = 0을 설정하는 것이 이미 예측 가능한 렌더당 정리를 제공하는지 확인하세요. 격리 접근 방식은 Docker나 Kubernetes 환경, 백그라운드 작업 시스템, 더 엄격한 메모리 격리가 필요한 API 플랫폼에서 가장 효과적입니다.

4. 작업자를 필요한 경우에만 재활용하기

하드 메모리 상한이 있고 BrowserPool 조정이 여전히 부족하다면, 설정된 작업 수 후에 렌더링 프로세스나 작업자 컨테이너를 재활용하십시오. 이는 고정 배치 크기 후에 전용 작업자를 재시작하거나, Kubernetes에서 엔진 컨테이너를 순환하거나, 독립적으로 재시작할 수 있는 서비스로 렌더링을 격리하는 것을 의미할 수 있습니다. 첫 번째 조치가 아닌 나중의 단계로 취급하십시오.

누수일 수 있는 경우

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

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

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

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

지원에 문의해야 할 때

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

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

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

Curtis Chau

지금 바로 엔지니어링 팀과 채팅하세요

기술 문서 작성자

커티스 차우는 칼턴 대학교에서 컴퓨터 과학 학사 학위를 취득했으며, Node.js, TypeScript, JavaScript, React를 전문으로 하는 프론트엔드 개발자입니다. 직관적이고 미적으로 뛰어난 사용자 인터페이스를 만드는 데 열정을 가진 그는 최신 프레임워크를 활용하고, 잘 구성되고 시각적으로 매력적인 매뉴얼을 제작하는 것을 즐깁니다.

...

더 읽어보기