Utilisation de la mémoire CEF/Chromium dans les applications longue durée

Pourquoi la mémoire reste élevée

Deux mécanismes distincts maintiennent la mémoire élevée après la fin d'un rendu.

Rétention de l'allocation native Chromium: Chromium utilise une grande quantité de mémoire non gérée qui vit en dehors du collecteur de déchets .NET. Lorsqu'un rendu est terminé, Chromium garde souvent cette mémoire native réservée pour une réutilisation plutôt que de la retourner immédiatement au système d'exploitation. Ainsi, vos objets PdfDocument peuvent être correctement supprimés, le runtime peut collecter les objets gérés, et la mémoire globale du processus ou du conteneur peut encore être élevée. C'est normal pour les moteurs basés sur Chromium.

Réutilisation des onglets BrowserPool: IronPDF peut garder les onglets de navigateur inactifs en vie après un rendu pour que le suivant démarre plus rapidement. Ces onglets conservent leurs sous-processus de rendu et état du DOM pendant un court instant, créant une ligne de base de mémoire visible même lorsque rien n'est en cours de rendu. Avec la mise en pool activée, vous verrez généralement la mémoire augmenter pendant le rendu, se maintenir à une ligne de base après la fin, puis diminuer par étapes à mesure que les onglets inactifs s'expirent et sont récoltés.

Paramètres par défaut de BrowserPool

IronPDF garde un petit nombre d'onglets chauds entre les rendus pour améliorer la performance. Les valeurs par défaut sont :

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

À cause de cela, même sans rendus actifs, le processus peut garder 1 à 4 onglets inactifs vivants pour un bref instant, chacun tenant mémoire native et ressources de sous-processus jusqu'à expiration du délai d'inactivité. Selon le contenu rendu et l'environnement, un onglet inactif peut retenir une quantité notable, environ 50 à 100 Mo dans certaines charges de travail. Cette base élevée peut persister environ 30 secondes après le dernier rendu avant de diminuer par étapes.

Solution

Si votre environnement est contraint en mémoire, les paramètres de BrowserPool sont la première chose à ajuster. Les valeurs par défaut ressemblent à ceci :

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

Stratégies pour les applications longue durée

Si votre application doit maintenir la mémoire constamment basse, suivez ces étapes dans l'ordre en commençant par l'ajustement de BrowserPool avant d'opter pour le recyclage des processus.

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

Quand cela peut être une fuite

Une élévation de mémoire après un rendu ne signifie pas automatiquement une fuite. Le rendu basé sur Chromium a deux types de réutilisation à comprendre : la réutilisation au niveau de l'allocation, où Chromium réserve des pages de mémoire native en interne (normal, non directement contrôlable), et la réutilisation au niveau des onglets, où BrowserPool garde les onglets intacts entre les rendus (configurable, et souvent le plus grand contributeur de ce que vous voyez dans les outils de surveillance).

Le schéma est généralement attendu lorsque la mémoire augmente pendant le rendu, se stabilise au lieu de croître indéfiniment, reste élevée brièvement après, puis baisse lorsque les onglets inactifs expirent ou restent disponibles pour le prochain rendu.

Investiguez davantage lorsque :

• la mémoire continue d'augmenter sans se stabiliser sous une charge de travail similaire
• la mémoire continue de croître même après avoir réduit la concurrence
• la mémoire continue de croître même après la désactivation de BrowserPool ou la définition de MaxIdleTabs = 0
• une reproduction minimale montre le même schéma dans le temps avec des données d'entrée contrôlées

Quand contacter le support

Contactez le support technique si vous pouvez reproduire toutes les conditions suivantes :

1. la mémoire continue de croître sans se stabiliser sous une charge de travail contrôlée
2. le problème persiste après avoir limité la concurrence
3. le problème persiste après la désactivation de BrowserPool ou la définition de MaxIdleTabs = 0
4. vous pouvez le reproduire avec un projet d'échantillon minimal

Lors de l'ouverture d'un ticket, incluez votre version d'IronPDF, le système d'exploitation et l'environnement d'hébergement, les détails Docker ou Kubernetes si applicable, le langage de programmation, la fréquence de rendu et le niveau de concurrence, les graphiques de mémoire ou les captures d'écran de surveillance, et un échantillon minimal reproductible.