Uso de memoria CEF/Chromium en aplicaciones de larga ejecución

Por qué la memoria permanece alta

Dos mecanismos distintos mantienen la memoria alta después de que un renderizado termina.

Retención del asignador nativo de Chromium: Chromium usa una gran cantidad de memoria no administrada que vive fuera del recolector de basura de .NET. Cuando un renderizado se completa, Chromium a menudo mantiene esa memoria nativa reservada para reutilización en lugar de devolverla al sistema operativo inmediatamente. Así, tus objetos PdfDocument pueden ser eliminados correctamente, el tiempo de ejecución puede recolectar objetos administrados, y el proceso o la memoria del contenedor en general aún puede leer alto. Esto es normal para motores basados en Chromium.

Reutilización de pestañas en el BrowserPool: IronPDF puede mantener pestañas del navegador inactivas vivas después de un renderizado para que el próximo comience más rápido. Esas pestañas mantienen sus subprocesos de renderizado y el estado del DOM por un corto tiempo, creando un nivel de memoria visible incluso cuando no se está renderizando nada. Con el agrupamiento activado, típicamente verás que la memoria aumenta durante el renderizado, se mantiene en un nivel base después de que se completa, luego cae en pasos a medida que las pestañas inactivas se agotan y se recolectan.

Configuraciones predeterminadas de BrowserPool

IronPDF mantiene un pequeño número de pestañas calientes entre renderizados para mejorar el rendimiento. Los valores predeterminados son:

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

Debido a esto, incluso sin renderizados activos, el proceso puede mantener de 1 a 4 pestañas inactivas vivas brevemente, cada una sosteniendo memoria nativa y recursos de subprocesos hasta que el tiempo de espera inactivo expire. Dependiendo del contenido renderizado y el entorno, una pestaña inactiva puede retener una cantidad notable, aproximadamente de 50 a 100 MB en algunas cargas de trabajo. Ese nivel elevado puede persistir durante unos 30 segundos después del último renderizado antes de caer en pasos.

Solución

Si tu entorno tiene restricciones de memoria, las configuraciones de BrowserPool son lo primero que debes ajustar. Los valores predeterminados se ven así:

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

Estrategias para aplicaciones de larga duración

Si tu aplicación debe mantener la memoria consistentemente baja, trabaja a través de estas en orden, comenzando con el ajuste de BrowserPool antes de recurrir al reciclaje de procesos.

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

Cuándo podría ser una fuga

La memoria elevada después del renderizado no significa automáticamente que haya una fuga. La renderización basada en Chromium tiene dos tipos de reutilización para entender: reutilización a nivel del asignador, donde Chromium reserva páginas de memoria nativa internamente (normal, no directamente controlable), y reutilización a nivel de pestaña, donde BrowserPool mantiene pestañas completas vivas entre renderizados (configurable y a menudo el mayor contribuyente a lo que ves en las herramientas de monitoreo).

El patrón suele ser esperado cuando la memoria aumenta durante el renderizado, se estabiliza en lugar de crecer sin límite, permanece elevada brevemente después, y luego cae a medida que las pestañas inactivas caducan o se mantienen disponibles para el próximo renderizado.

Investiga más cuando:

• la memoria sigue aumentando sin estabilizarse bajo una carga de trabajo similar
• la memoria sigue creciendo incluso después de reducir la concurrencia
• la memoria sigue creciendo incluso después de deshabilitar BrowserPool o establecer MaxIdleTabs = 0
• una reproducción mínima muestra el mismo patrón con el tiempo con una entrada controlada

Cuándo contactar con el soporte

Comunícate con soporte técnico si puedes reproducir todos los siguientes problemas:

1. la memoria sigue creciendo sin estabilizarse bajo una carga de trabajo controlada
2. el problema persiste después de limitar la concurrencia
3. el problema persiste después de deshabilitar BrowserPool o establecer MaxIdleTabs = 0
4. puedes reproducirlo con un proyecto de muestra mínimo

Al abrir un ticket, incluye tu versión de IronPDF, sistema operativo y entorno de alojamiento, detalles de Docker o Kubernetes si es aplicable, lenguaje de programación, frecuencia de renderizado y nivel de concurrencia, gráficos de memoria o capturas de pantalla de monitoreo, y un ejemplo mínimo reproducible.