长时间运行应用程序中的CEF/Chromium内存使用

为什么内存保持高位

在渲染完成后，有两种不同的机制保持内存高位。

Chromium本地分配器保留： Chromium使用大量非托管内存，这些内存驻留在.NET垃圾收集器之外。 当渲染完成后，Chromium通常会保留那些本机内存以供重用，而不是立即将其返回给操作系统。 因此，您的PdfDocument对象可以被正确处理，运行时可以收集托管对象，但整体进程或容器内存仍然可能显示高位。 对此基于Chromium的引擎来说是正常的。

BrowserPool标签重用： IronPDF可以在渲染后保持空闲浏览器标签活着，以便下一个渲染更快。 这些标签在短时间内保存它们的渲染子进程和DOM状态，即使在没有渲染时也会创建一个可见的内存基线。 当启用池时，您通常会看到内存在渲染期间上升，在完成后保持基线，然后随着空闲标签超时和被回收而逐步下降。

BrowserPool默认值

IronPDF在渲染之间保持少量标签温暖以提高性能。 默认值是：

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

因此，即便没有活动的渲染，进程可能会在短时间内保持1到4个空闲标签活着，每个标签持有本机内存和子进程资源，直到空闲超时到期。 根据渲染的内容和环境，空闲标签可以保留相当显著的量，在某些工作负载中大约是50到100 MB。 在最后一次渲染后，提升的基线可能会持续约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保持完整的标签在渲染之间活着（可配置，通常是您在监视工具中看到更大贡献者）。

当在渲染期间内存上升，稳定而不是无限制增长，保持短暂高位，而后随着空闲标签超时或为下一次渲染保持可用时，这样的模式通常是可预期的。

当进一步调查以下情况时：

• 即使在相似工作负载下，内存仍持续增加而不稳定
• 即使在减少并发性后，内存仍持续增长
• 即使在禁用BrowserPool或设定MaxIdleTabs = 0后，内存仍持续增长
• 最小化复现显示相同的时间模式，并具有受控输入

什么时候联系支持

如果您可以重现以下所有情况，请联系技术支持：

1. 在受控工作负载下，内存持续增长而不稳定
2. 限制并发后问题仍然存在
3. 在禁用BrowserPool或设定MaxIdleTabs = 0后，问题仍然存在
4. 您可以使用一个最小的示例项目重现问题

开票时，请包括您的IronPDF版本、操作系统和托管环境、Docker或Kubernetes详细信息（如果适用）、编程语言、渲染频率和并发级别、内存图表或监控屏幕截图，以及一个最小可重现的示例。