Uso de Memória CEF/Chromium em Aplicações de Longa Duração

Por Que a Memória Permanece Elevada

Dois mecanismos distintos mantêm a memória alta após a conclusão de uma renderização.

Retenção do alocador nativo do Chromium: O Chromium usa uma grande quantidade de memória não gerenciada que vive fora do coletor de lixo do .NET. Quando uma renderização é concluída, o Chromium frequentemente mantém essa memória nativa reservada para reutilização em vez de devolvê-la ao sistema operacional imediatamente. Portanto, seus objetos PdfDocument podem ser descartados corretamente, o runtime pode coletar objetos gerenciados, e o processo ou container global ainda pode ler uma memória alta. Isso é normal para motores baseados no Chromium.

Reuso de abas do BrowserPool: O IronPDF pode manter abas do navegador ociosas ativas após uma renderização para que a próxima comece mais rápido. Essas abas mantêm seus subprocessos de renderizadores e estado de DOM por um curto período, criando um nível de memória visível, mesmo quando nada está sendo renderizado. Com o agrupamento ativado, você geralmente verá a memória aumentar durante a renderização, manter-se em um nível básico após a conclusão, e então cair em etapas à medida que as abas ociosas expiram e são removidas.

Padrões do BrowserPool

O IronPDF mantém um pequeno número de abas aquecidas entre renderizações para melhorar o desempenho. Os padrões são:

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

Por causa disso, mesmo sem renderizações ativas, o processo pode manter de 1 a 4 abas ociosas vivas brevemente, cada uma retendo memória nativa e recursos subprocesso até o tempo limite ocioso expirar. Dependendo do conteúdo renderizado e do ambiente, uma aba ociosa pode reter uma quantidade notável, cerca de 50 a 100 MB em algumas cargas de trabalho. Essa linha de base elevada pode persistir por cerca de 30 segundos após a última renderização antes de cair em etapas.

Solução

Se o seu ambiente possui restrições de memória, as configurações do BrowserPool são a primeira coisa a ajustar. Os padrões são assim:

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

Estratégias para Aplicações de Longa Duração

Se a sua aplicação deve manter a memória consistentemente baixa, trabalhe com estas estratégias na ordem, começando com o ajuste do BrowserPool antes de recorrer à reciclagem de processo.

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

Quando Pode Ser um Vazamento

Memória elevada após a renderização não significa automaticamente um vazamento. A renderização baseada no Chromium tem dois tipos de reutilização a serem compreendidos: reutilização no nível do alocador, onde o Chromium reserva internamente páginas de memória nativas (normal, não diretamente controlável), e reutilização no nível da aba, onde o BrowserPool mantém abas inteiras vivas entre as renderizações (configurável, e frequentemente o maior contribuidor do que você vê nas ferramentas de monitoramento).

O padrão é normalmente esperado quando a memória sobe durante a renderização, estabiliza em vez de crescer sem limite, permanece elevada brevemente em seguida e depois cai enquanto as abas ociosas expiram ou permanece disponível para a próxima renderização.

Investigue mais a fundo quando:

• a memória continua aumentando sem estabilizar sob uma carga de trabalho semelhante
• a memória continua crescendo mesmo após reduzir a concorrência
• a memória continua crescendo mesmo após desabilitar o BrowserPool ou definir MaxIdleTabs = 0
• uma reprodução mínima mostra o mesmo padrão ao longo do tempo com entrada controlada

Quando Contatar o Suporte

Entre em contato com o suporte técnico se você conseguir reproduzir todos os seguintes:

1. memória continua crescendo sem estabilizar sob uma carga de trabalho controlada
2. o problema persiste após limitar a concorrência
3. o problema persiste após desabilitar o BrowserPool ou definir MaxIdleTabs = 0
4. você pode reproduzi-lo com um projeto de amostra mínima

Ao abrir um tíquete, inclua sua versão do IronPDF, sistema operacional e ambiente de hospedagem, detalhes do Docker ou Kubernetes, se aplicável, linguagem de programação, frequência de renderização e nível de concorrência, gráficos de memória ou capturas de tela de monitoramento e um exemplo de amostra mínima reproduzível.