Zużycie pamięci CEF/Chromium w długodziałających aplikacjach

Dlaczego pamięć pozostaje podwyższona

Dwa różne mechanizmy utrzymują pamięć po zakończeniu renderowania.

Zatrzymywanie alokatora natywnego Chromium: Chromium używa dużej ilości niezrządzanej pamięci, która istnieje poza kolektorem śmieci .NET. Gdy renderowanie się kończy, Chromium często utrzymuje tę natywną pamięć zarezerwowaną do ponownego użycia zamiast natychmiastowego zwracania jej do systemu operacyjnego. PdfDocument obiekty mogą być poprawnie zakończone, środowisko może zbierać zarządzane obiekty, a całkowita pamięć procesu lub kontenera nadal może być wysoka. Jest to normalne dla silników opartych na Chromium.

Reuse kart przeglądarki w BrowserPool: IronPDF może utrzymywać niewykorzystane karty przeglądarki przy życiu po renderze, aby następny mógł uruchomić się szybciej. Te karty utrzymują swoje podprocesy renderujące i stan DOM przez krótki czas, tworząc widoczny bazowy poziom pamięci, nawet gdy nic nie jest renderowane. Gdy pooling jest włączony, zazwyczaj obserwujesz wzrost pamięci podczas renderowania, utrzymanie na poziomie bazowym po jego zakończeniu, a następnie spadek w krokach gdy bezczynne karty kończą się i są zbierane.

Domyślne ustawienia BrowserPool

IronPDF utrzymuje niewielką liczbę kart przeglądarki w stanie gotowości między renderowaniami, aby poprawić wydajność. Domyślne ustawienia to:

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

Z tego powodu, nawet bez aktywnych renderów proces może utrzymywać 1 do 4 bezczynnych kart przy życiu przez krótko, każda trzymająca natywną pamięć i zasoby podprocesów aż do wygaśnięcia czasu bezczynności. W zależności od renderowanej zawartości i środowiska, bezczynna karta może utrzymać zauważalną ilość, około 50 do 100 MB w niektórych obciążeniach. Ten podwyższony poziom bazowy może utrzymywać się przez około 30 sekund po ostatnim renderowaniu zanim spadnie w krokach.

Rozwiązanie

Jeśli twoje środowisko ma ograniczoną pamięć, pierwszą rzeczą do dostrojenia są ustawienia BrowserPool. Domyślne wygląda to tak:

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

Strategie dla długodziałających aplikacji

Jeśli twoja aplikacja musi utrzymywać pamięć na stałym niskim poziomie, przeanalizuj te kroki, zaczynając od dostrojenia BrowserPool zanim sięgniesz po recykling procesów.

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

Gdy może to być wyciek

Podwyższona pamięć po renderowaniu nie oznacza automatycznie wycieku. Renderowanie oparte na Chromium ma dwa rodzaje ponownego użycia do zrozumienia: ponowne użycie na poziomie alokatora, gdzie Chromium rezerwuje natywne strony pamięci wewnętrznie (normalne, nie bezpośrednio kontrolowalne), i ponowne użycie na poziomie karty, gdzie BrowserPool utrzymuje pełne karty przy życiu między renderowaniami (konfigurowalne, i często większy współuczestnik tego co widzisz w narzędziach monitorujących).

Wzorzec jest zazwyczaj oczekiwany, gdy pamięć rośnie podczas renderowania, stabilizuje się zamiast rosnąć bez ograniczenia, pozostaje podwyższona przez krótko potem i później spada, gdy bezczynne karty kończą się lub pozostają dostępne do następnego renderu.

Badaj dalej gdy:

• pamięć wciąż rośnie bez stabilizacji przy takim samym obciążeniu
• pamięć utrzymuje się nawet po redukcji równoczesności
• pamięć utrzymuje się nawet po wyłączeniu BrowserPool lub ustawieniu MaxIdleTabs = 0
• minimalna reprodukcja pokazuje ten sam wzorzec z upływem czasu przy kontrolowanym wejściu

Kiedy skontaktować się z wsparciem

Skontaktuj się z wsparciem technicznym jeżeli możesz odtworzyć wszystkie poniższe:

1. pamięć nadal rośnie bez stabilizacji przy kontrolowanym obciążeniu
2. problem utrzymuje się po ograniczeniu równoczesności
3. problem utrzymuje się po wyłączeniu BrowserPool lub ustawieniu MaxIdleTabs = 0
4. możesz go odtworzyć przy użyciu minimalnego projektu próbki

Podczas otwierania zgłoszenia, dołącz swoją wersję IronPDF, system operacyjny i środowisko hostingowe, szczegóły Docker lub Kubernetes jeśli dotyczy, język programowania, częstotliwość renderowania i poziom równoczesności, grafy pamięci lub zrzuty ekranu z monitorowania i minimalną próbkę odtwarzania.