Speichernutzung von CEF/Chromium in langlaufenden Anwendungen

Warum bleibt der Speicher hoch

Zwei unterschiedliche Mechanismen halten den Speicher hoch, nachdem ein Render abgeschlossen ist.

Chromium-nativer Allokator-Retention: Chromium verwendet eine große Menge an nicht verwaltetem Speicher, der außerhalb des .NET Garbage Collectors liegt. Wenn ein Render abgeschlossen ist, behält Chromium oft diesen nativen Speicher zur Wiederverwendung, anstatt ihn sofort an das Betriebssystem zurückzugeben. Damit Ihre PdfDocument Objekte korrekt verworfen werden können, damit die Laufzeit verwaltete Objekte sammeln kann, und der Gesamtprozess oder Container-Arbeitsspeicher kann dennoch hochbleiben. Dies ist normal für Chromium-basierte Engines.

BrowserPool-Tab-Wiederverwendung: IronPDF kann inaktive Browser-Tabs nach einem Render erhalten, sodass der nächste schneller startet. Diese Tabs halten ihre Renderer-Unterprozesse und den DOM-Zustand für kurze Zeit aufrecht und erstellen eine sichtbare Speicherbasislinie, auch wenn nichts gerendert wird. Mit aktivem Pooling sehen Sie in der Regel, dass der Speicher während des Renderings ansteigt, nach Abschluss bei einer Basislinie bleibt und dann in Schritten abnimmt, wenn inaktive Tabs auslaufen und abgeerntet werden.

BrowserPool-Standardeinstellungen

IronPDF hält eine kleine Anzahl von Tabs zwischen den Rendern warm, um die Leistung zu verbessern. Die Standardeinstellungen sind:

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

Aufgrund dessen kann der Prozess auch ohne aktive Renderings 1 bis 4 inaktive Tabs kurzzeitig am Leben halten, wobei jeder nativen Speicher und Unterprozessressourcen hält, bis das Timeout verstreicht. Je nach dem gerenderten Inhalt und der Umgebung kann ein inaktiver Tab eine bemerkenswerte Menge behalten, etwa 50 bis 100 MB bei einigen Arbeitslasten. Diese erhöhte Basislinie kann etwa 30 Sekunden nach dem letzten Render bestehen bleiben, bevor sie stufenweise abfällt.

Lösung

Wenn Ihre Umgebung speicherbeschränkt ist, sind die BrowserPool-Einstellungen das Erste, was Sie anpassen sollten. Die Standardwerte sehen so aus:

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

Strategien für lang laufende Anwendungen

Wenn Ihre Anwendung den Speicher konstant niedrig halten muss, arbeiten Sie diese Punkte in der Reihenfolge ab, beginnend mit dem Tuning von BrowserPool, bevor Sie zum Prozess-Recycling übergehen.

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

Wann es sich um ein Leck handeln könnte

Erhöhter Speicher nach dem Rendern bedeutet nicht automatisch ein Leck. Chromium-basiertes Rendering hat zwei Arten von Wiederverwendung, die man verstehen muss: Allocator-Ebene Wiederverwendung, bei der Chromium intern native Speicherseiten reserviert (normal, nicht direkt steuerbar), und Tab-Ebene Wiederverwendung, bei der BrowserPool volle Tabs zwischen den Renderings am Leben hält (konfigurierbar, und oft der größere Beitrag zu dem, was man in Überwachungstools sieht).

Das Muster ist normalerweise erwartet, wenn der Speicher während des Renderings steigt, stabilisiert sich anstatt unbegrenzt zu wachsen, bleibt kurz danach erhöht und fällt später, wenn inaktive Tabs auslaufen oder für das nächste Rendering verfügbar bleiben.

Untersuchen Sie weiter, wenn:

• Speicher wächst weiter, ohne sich unter einer ähnlichen Arbeitslast zu stabilisieren
• Speicher wächst weiter, selbst nachdem die Parallelität reduziert wurde
• Arbeitsspeicher wächst weiter, selbst nach dem Deaktivieren von BrowserPool oder dem Setzen von MaxIdleTabs = 0
• Eine minimale Reproduktion zeigt das gleiche Muster über die Zeit mit kontrollierten Eingabedaten

Wann Sie den Support kontaktieren sollten

Wenden Sie sich an den technischen Support, wenn Sie alle folgenden Punkte reproduzieren können:

1. Speicher wächst weiter, ohne sich unter einer kontrollierten Arbeitslast zu stabilisieren
2. Das Problem bleibt nach Begrenzung der Parallelität bestehen
3. Das Problem besteht fort, nachdem BrowserPool deaktiviert oder MaxIdleTabs = 0 gesetzt wurde
4. Sie können es mit einem minimalen Beispielprojekt reproduzieren

Beim Öffnen eines Tickets sollten Sie Ihre IronPDF-Version, OS und Hosting-Umgebung, Docker- oder Kubernetes-Details, falls zutreffend, Programmiersprache, Renderfrequenz und Parallelitätsstufe, Speicherdiagramme oder Überwachungs-Screenshots und ein minimal reproduzierbares Beispiel einschließen.