CEF/Chromium Memory Usage in Long-Running Applications

Why Memory Stays Elevated

Two distinct mechanisms keep memory up after a render finishes.

Chromium native allocator retention: Chromium uses a large amount of unmanaged memory that lives outside the .NET garbage collector. When a render completes, Chromium often keeps that native memory reserved for reuse rather than returning it to the OS immediately. So your PdfDocument objects can be disposed correctly, the runtime can collect managed objects, and the overall process or container memory can still read high. This is normal for Chromium-based engines.

BrowserPool tab reuse: IronPDF can keep idle browser tabs alive after a render so the next one starts faster. Those tabs hold their renderer subprocesses and DOM state for a short time, creating a visible memory baseline even when nothing is rendering. With pooling on, you will typically see memory rise during rendering, hold at a baseline after it completes, then drop in steps as idle tabs time out and are reaped.

BrowserPool Defaults

IronPDF keeps a small number of tabs warm between renders to improve performance. The defaults are:

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

Because of this, even with no active renders the process may keep 1 to 4 idle tabs alive briefly, each holding native memory and subprocess resources until the idle timeout expires. Depending on the rendered content and environment, an idle tab can retain a noticeable amount, roughly 50 to 100 MB in some workloads. That elevated baseline can persist for about 30 seconds after the last render before dropping in steps.

Solution

If your environment is memory-constrained, BrowserPool settings are the first thing to tune. The defaults look like this:

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

net

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;

net

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;

renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10

Strategies for Long-Running Applications

If your application must hold memory consistently low, work through these in order, starting with BrowserPool tuning before reaching for process recycling.

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

When It Might Be a Leak

Elevated memory after rendering does not automatically mean a leak. Chromium-based rendering has two kinds of reuse to understand: allocator-level reuse, where Chromium reserves native memory pages internally (normal, not directly controllable), and tab-level reuse, where BrowserPool keeps full tabs alive between renders (configurable, and often the bigger contributor to what you see in monitoring tools).

The pattern is usually expected when memory rises during rendering, stabilizes instead of growing without limit, stays elevated briefly afterward, and later drops as idle tabs time out or remains available for the next render.

Investigate further when:

• memory keeps increasing without stabilizing under a similar workload
• memory keeps growing even after reducing concurrency
• memory keeps growing even after disabling BrowserPool or setting MaxIdleTabs = 0
• a minimal reproduction shows the same pattern over time with controlled input

When to Contact Support

Reach out to technical support if you can reproduce all of the following:

1. memory continues growing without stabilizing under a controlled workload
2. the issue persists after limiting concurrency
3. the issue persists after disabling BrowserPool or setting MaxIdleTabs = 0
4. you can reproduce it with a minimal sample project

When opening a ticket, include your IronPDF version, OS and hosting environment, Docker or Kubernetes details if applicable, programming language, render frequency and concurrency level, memory graphs or monitoring screenshots, and a minimal reproducible sample.