# Uzun Süre Çalışan Uygulamalarda CEF/Chromium Bellek Kullanımı
IronPDF Chromium ile oluşturur, bu nedenle belgeler serbest bırakıldığında ve `GC.Collect()` çalıştığında bile PDF oluşturma işleminden sonra işlem belleği kısa bir süre yüksek kalabilir. İki kaynak etkili: Chromium'un yönetilmeyen yerleşik tahsisi ve IronPDF'nin tarayıcı sekmesi havuzu. Çoğu durumda bu beklendiği gibi olur ve otomatik olarak bir bellek sızıntısı anlamına gelmez.
Bu, IronPDF ve Windows ve Linux'ta `IronPdfEngine`, Docker, Kubernetes, VM ve sunucu barındırılan ortamlar genelinde ve Chromium tabanlı oluşturma kullanan .NET, Java ve her türlü uygulama için geçerlidir.
## Bellek Neden Yüksek Kalır
İşleme bitişinden sonra bellek yüksek tutan iki farklı mekanizma bulunmaktadır.
**Chromium yerel tahsis tutumu:** Chromium, .NET çöp toplayıcı dışında yaşayan büyük miktarda yönetilmeyen bellek kullanır. Bir işleme tamamlandığında, Chromium bu yerel belleği yeniden kullanım için genellikle OS'ye hemen geri vermez. Bu nedenle `PdfDocument` nesneleriniz düzgün şekilde serbest bırakılabilir, çalışma zamanı yönetilen nesneleri toplayabilir ve genel işlem veya konteyner belleği hâlâ yüksek okunabilir. Bu, Chromium tabanlı motorlar için normaldir.
**TarayıcıHavuzu sekme yeniden kullanımı:** IronPDF, bir işleme bittikten sonra yeni bir işleme daha hızlı başlamak için boşta tarayıcı sekmelerini canlı tutabilir. Bu sekmeler, kendi işleme alt süreçlerini ve DOM durumlarını kısa bir süre tutar, bu da hiçbir şey işlenmiyorken bile görülebilir bir bellek taban çizgisi oluşturur. Havuzlama açıldığında, genellikle belleğin işleme sırasında yükseldiğini, işleme bittikten sonra bir taban çizgisinde tutulduğunu ve daha sonra boşta kalan sekmeler zaman aşımına uğradıkça ve toplanana kadar aşamalar halinde düştüğünü göreceksiniz.
### `GC.Collect()` Neden Yardımcı Olmaz
`GC.Collect()` yalnızca yönetilen .NET belleğini geri kazanır. Chromium'un yerel belleği OS'ye geri vermesini zorlamaz ve bilerek canlı tutulan sıcak TarayıcıHavuzu sekmelerini yıkmaz. Doğru şekilde serbest bırakma ve zorunlu bir toplama ile bile, Görev Yöneticisi, Docker, Kubernetes veya New Relic gibi araçlarla gösterilen rakamlar hemen düşmeyebilir.
Etkisi en çok uzun süre çalışan uygulamalarda, paylaşılan hizmet ortamlarında ve Docker veya Kubernetes dağıtımlarında görülür. Java entegrasyonları için `IronPdfEngine` kullanılırken, baskı genellikle JVM yığını yerine motor işleminde veya konteynırda ortaya çıkar.
## TarayıcıHavuzu Varsayılanları
IronPDF, performansı arttırmak için işleme arasındaki bir küçük sayıda sekmeyi sıcak tutar. Varsayılanlar şunlardır:
- `BrowserPool.Enabled = true`
- `BrowserPool.MaxIdleTabs = min(max(ProcessorCount / 2, 1), 4)`
- `BrowserPool.IdleTimeoutSeconds = 30`
Bu yüzden, aktif işleme olmadan bile süreç, yaklaşık 30 saniye boyunca son işleme sonrası aşamalar halinde düşmeden önce 1 ila 4 boşta kalan sekmeyi bir süre sıcak tutabilir, her biri yerel bellek ve alt süreç kaynaklarını boşta kalma zaman aşım süresi dolana kadar tutar. İşlenen içeriğe ve ortama bağlı olarak, bir boşta kalan sekme, bazı iş yüklerinde yaklaşık 50 ila 100 MB arasında fark edilebilir bir miktar tutabilir. Bu yükseltilmiş tabana çizgisi, yaklaşık 30 saniye son işleme bittikten sonra adım adım düşmeden önce kalıcı olabilir.
## Çözüm
Ortamınız bellek kısıtlıysa, TarayıcıHavuzu ayarları ilk ayarlanacak şeydir. Varsayılanlar bu şekilde görünür:
```csharp
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
```
### Seçenek 1: Sekme Havuzlamayı Tamamen Devre Dışı Bırakma
Her bir işleme sonrasında en belirleyici temizliği istediğinizde ulaşın.
```csharp
renderer.RenderingOptions.BrowserPool.Enabled = false;
```
### Seçenek 2: Boşta Kalan Sekmeleri Tutmadan TarayıcıHavuzunu Etkinleştirme
Özelliği açık bırakır, ancak işleme arasındaki sıcak sekmeleri tutmaktan kaçınır ve her işleme için belirleyici bir temizlik sağlar.
```csharp
renderer.RenderingOptions.BrowserPool.MaxIdleTabs = 0;
```
### Seçenek 3: Boşta Kalma Zaman Aşımını Azaltma
Orta bir yol: bir miktar yeniden kullanma avantajı sağlar, ancak bellek daha önce patlak trafik sonrasında azalmaya bırakılır.
```csharp
renderer.RenderingOptions.BrowserPool.IdleTimeoutSeconds = 10;
```
**Aralarından nasıl seçim yapılır:**
- **`Enabled = false`:** bellek kararlılığı, sıcak başlangıç performansından daha önemlidir.
- **`MaxIdleTabs = 0`:** özelliği tamamen devre dışı bırakmadan belirleyici her oluşturma sonrası temizlik istiyorsunuz.
- **Alt `IdleTimeoutSeconds`:** iş yükünüz patlamalar halinde gelir ve her birinden sonra belleğin daha hızlı geri kazanılmasını istiyorsunuz.
## Uzun Süreli Uygulamalar için Stratejiler
Uygulamanızın belleği tutarlı olarak düşük tutması gerekiyorsa, işlem yenilemeye gitmeden önce yukarıdaki sırasında başlayarak, TarayıcıHavuzu ayarlarıyla başlar.
### 1. Eşzamanlı İşlemleri Sınırlandırma
Birden fazla Chromium işleme işi bir anda çalıştırmak, yerel bellek baskısını keskin bir şekilde artırır. Paralel işliyorsanız, kaç tanesinin eşzamanlı olarak çalıştığını bir semaforla sınırlayın:
```csharp
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();
}
}
```
IronPDF işleme çağrınızı kısıtlanmış bölümün içine sarın, böylece aynı anda yalnızca sabit sayıda iş çalışır.
### 2. TarayıcıHavuzunu Ayarlayın veya Devre Dışı Bırakın
Birçok bellek hassas dağıtımı için bu en etkili ilk adımdır. BrowserPool'u tamamen devre dışı bırakın, `MaxIdleTabs = 0` belirleyin veya patlamalı iş yükleri için `IdleTimeoutSeconds` azaltın. Bunlardan herhangi biri, tam bir yeniden başlatma stratejisi olmadan kalıcı post-işleme taban çizgisini küçültebilir.
### 3. İşlemeyi Ayrı Bir İşçiye İzole Etme
Üretim sistemleri için PDF işlemesini ana uygulamadan çıkarma güçlü bir patern. Ana uygulama stabil kalır, işleme işçisi kendi başına yeniden başlatılabilir ve işçi çıktığında yerel Chromium belleği tamamen serbest bırakılır. Geri dönüşümü kullanmadan önce, BrowserPool'u devre dışı bırakmanın veya `MaxIdleTabs = 0` belirlemenin zaten belirleyici her oluşturmada temizlik sağladığından emin olun. İzolasyon yaklaşımı, Docker veya Kubernetes ortamlarında, arka plan iş sistemlerinde ve daha sıkı bellek izolasyonuna ihtiyaç duyan API platformlarında en iyi sonucu verir.
### 4. İşçiyi Yalnızca Gerekli Olduğunda Yeniden Başlatma
Katı bir bellek sınırı olduğunda ve TarayıcıHavuzu ayarlamaları hala yetersiz kalıyorsa, belirli bir iş sayısından sonra işleme süreci veya işçi konteynerini yeniden başlatın. Bu, sabit bir iş yığınından sonra özel bir işçiyi yeniden başlatmak, Kubernetes'te motor konteynerlerini döndürmek veya bir hizmete işleme izole etmeyi ve bağımsız olarak yeniden başlatılabilir hale getirmeyi gerektirebilir. Bunu bir gecikmiş adım olarak düşünün, ilk hareketiniz değil.
## Bir Sızıntı Olabileceği Zamanlar
İşleme sonrası yükseltilmiş bellek, otomatik olarak bir sızıntı anlamına gelmez. Chromium tabanlı işleme, iki tür yeniden kullanım içerir: **tahsis edici seviyede yeniden kullanım**, burada Chromium dahili olarak yerel bellek sayfalarını rezerve eder (normal, doğrudan denetlenemez) ve **sekme seviyesinde yeniden kullanım**, burada TarayıcıHavuzu, işlemler arasında tam sekmeler canlı tutar (yapılandırılabilir ve genellikle izleme araçlarında gördüğünüz en büyük katkıcı).
Desen, genellikle işleme sırasında bellek yükselirse, sınır büyümeksizin stabilize olursa, kısa bir süre yüksek kalırsa ve daha sonra boşta kalan sekmeler zaman aşımına uğradığında veya bir sonraki işleme için kullanılabilir kaldığında düşmesi beklenir.
Daha fazla araştırın:
- bellek, benzer bir iş yükü altında stabil olmaksızın sürekli artıyorsa
- eşzamanlılığı azaltmasına rağmen bellek büyümeye devam ediyorsa
- BrowserPool devre dışı bırakıldıktan veya `MaxIdleTabs = 0` ayarlandıktan sonra bile bellek büyümeye devam ediyor
- kontrollü bir giriş ile aynı deseni zamanla gösteren minimal bir üretim gösteriyorsa
## Destekle Ne Zaman İrtibata Geçilmeli
Tüm aşağıdakileri tekrar üretebiliyorsanız, [teknik destek](/troubleshooting/engineering-support-for-ironpdf/) ile iletişime geçin:
1. bellek, kontrollü bir iş yükü altında stabil olmaksızın büyümeye devam ediyorsa
2. eşzamanlılığı sınırladıktan sonra sorun devam ediyorsa
3. sorun, BrowserPool devre dışı bırakıldıktan veya `MaxIdleTabs = 0` ayarlandıktan sonra devam ediyor
4. Minimal bir örnek proje ile tekrarlayabiliyorsanız.
Bir bilet açarken, IronPDF sürümünüzü, işletim sistemi ve barındırma ortamınızı, Docker veya Kubernetes ayrıntılarını (varsa), programlama dilinizi, işleme sıklığı ve eşzamanlılık seviyenizi, bellek grafiklerinizi veya izleme ekran görüntülerini ve minimal yeniden üretilebilir bir örnek dosyayı ekleyin.
IronPDF Chromium ile oluşturur, bu nedenle belgeler serbest bırakıldığında ve GC.Collect() çalıştığında bile PDF oluşturma işleminden sonra işlem belleği kısa bir süre yüksek kalabilir. İki kaynak etkili: Chromium'un yönetilmeyen yerleşik tahsisi ve IronPDF'nin tarayıcı sekmesi havuzu. Çoğu durumda bu beklendiği gibi olur ve otomatik olarak bir bellek sızıntısı anlamına gelmez.
Bu, IronPDF ve Windows ve Linux'ta IronPdfEngine, Docker, Kubernetes, VM ve sunucu barındırılan ortamlar genelinde ve Chromium tabanlı oluşturma kullanan .NET, Java ve her türlü uygulama için geçerlidir.
Bellek Neden Yüksek Kalır
İşleme bitişinden sonra bellek yüksek tutan iki farklı mekanizma bulunmaktadır.
Chromium yerel tahsis tutumu: Chromium, .NET çöp toplayıcı dışında yaşayan büyük miktarda yönetilmeyen bellek kullanır. Bir işleme tamamlandığında, Chromium bu yerel belleği yeniden kullanım için genellikle OS'ye hemen geri vermez. Bu nedenle PdfDocument nesneleriniz düzgün şekilde serbest bırakılabilir, çalışma zamanı yönetilen nesneleri toplayabilir ve genel işlem veya konteyner belleği hâlâ yüksek okunabilir. Bu, Chromium tabanlı motorlar için normaldir.
TarayıcıHavuzu sekme yeniden kullanımı: IronPDF, bir işleme bittikten sonra yeni bir işleme daha hızlı başlamak için boşta tarayıcı sekmelerini canlı tutabilir. Bu sekmeler, kendi işleme alt süreçlerini ve DOM durumlarını kısa bir süre tutar, bu da hiçbir şey işlenmiyorken bile görülebilir bir bellek taban çizgisi oluşturur. Havuzlama açıldığında, genellikle belleğin işleme sırasında yükseldiğini, işleme bittikten sonra bir taban çizgisinde tutulduğunu ve daha sonra boşta kalan sekmeler zaman aşımına uğradıkça ve toplanana kadar aşamalar halinde düştüğünü göreceksiniz.
GC.Collect() Neden Yardımcı Olmaz
GC.Collect() yalnızca yönetilen .NET belleğini geri kazanır. Chromium'un yerel belleği OS'ye geri vermesini zorlamaz ve bilerek canlı tutulan sıcak TarayıcıHavuzu sekmelerini yıkmaz. Doğru şekilde serbest bırakma ve zorunlu bir toplama ile bile, Görev Yöneticisi, Docker, Kubernetes veya New Relic gibi araçlarla gösterilen rakamlar hemen düşmeyebilir.
Etkisi en çok uzun süre çalışan uygulamalarda, paylaşılan hizmet ortamlarında ve Docker veya Kubernetes dağıtımlarında görülür. Java entegrasyonları için IronPdfEngine kullanılırken, baskı genellikle JVM yığını yerine motor işleminde veya konteynırda ortaya çıkar.
TarayıcıHavuzu Varsayılanları
IronPDF, performansı arttırmak için işleme arasındaki bir küçük sayıda sekmeyi sıcak tutar. Varsayılanlar şunlardır:
Bu yüzden, aktif işleme olmadan bile süreç, yaklaşık 30 saniye boyunca son işleme sonrası aşamalar halinde düşmeden önce 1 ila 4 boşta kalan sekmeyi bir süre sıcak tutabilir, her biri yerel bellek ve alt süreç kaynaklarını boşta kalma zaman aşım süresi dolana kadar tutar. İşlenen içeriğe ve ortama bağlı olarak, bir boşta kalan sekme, bazı iş yüklerinde yaklaşık 50 ila 100 MB arasında fark edilebilir bir miktar tutabilir. Bu yükseltilmiş tabana çizgisi, yaklaşık 30 saniye son işleme bittikten sonra adım adım düşmeden önce kalıcı olabilir.
Çözüm
Ortamınız bellek kısıtlıysa, TarayıcıHavuzu ayarları ilk ayarlanacak şeydir. Varsayılanlar bu şekilde görünür:
renderer.RenderingOptions.BrowserPool.Enabled = true; // defaultrenderer.RenderingOptions.BrowserPool.MaxIdleTabs = 2; // default is CPU/2, clamped to 1-4renderer.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
C#
Seçenek 1: Sekme Havuzlamayı Tamamen Devre Dışı Bırakma
Her bir işleme sonrasında en belirleyici temizliği istediğinizde ulaşın.
Enabled = false: bellek kararlılığı, sıcak başlangıç performansından daha önemlidir.
MaxIdleTabs = 0: özelliği tamamen devre dışı bırakmadan belirleyici her oluşturma sonrası temizlik istiyorsunuz.
Alt IdleTimeoutSeconds: iş yükünüz patlamalar halinde gelir ve her birinden sonra belleğin daha hızlı geri kazanılmasını istiyorsunuz.
Uzun Süreli Uygulamalar için Stratejiler
Uygulamanızın belleği tutarlı olarak düşük tutması gerekiyorsa, işlem yenilemeye gitmeden önce yukarıdaki sırasında başlayarak, TarayıcıHavuzu ayarlarıyla başlar.
1. Eşzamanlı İşlemleri Sınırlandırma
Birden fazla Chromium işleme işi bir anda çalıştırmak, yerel bellek baskısını keskin bir şekilde artırır. Paralel işliyorsanız, kaç tanesinin eşzamanlı olarak çalıştığını bir semaforla sınırlayın:
IronPDF işleme çağrınızı kısıtlanmış bölümün içine sarın, böylece aynı anda yalnızca sabit sayıda iş çalışır.
2. TarayıcıHavuzunu Ayarlayın veya Devre Dışı Bırakın
Birçok bellek hassas dağıtımı için bu en etkili ilk adımdır. BrowserPool'u tamamen devre dışı bırakın, MaxIdleTabs = 0 belirleyin veya patlamalı iş yükleri için IdleTimeoutSeconds azaltın. Bunlardan herhangi biri, tam bir yeniden başlatma stratejisi olmadan kalıcı post-işleme taban çizgisini küçültebilir.
3. İşlemeyi Ayrı Bir İşçiye İzole Etme
Üretim sistemleri için PDF işlemesini ana uygulamadan çıkarma güçlü bir patern. Ana uygulama stabil kalır, işleme işçisi kendi başına yeniden başlatılabilir ve işçi çıktığında yerel Chromium belleği tamamen serbest bırakılır. Geri dönüşümü kullanmadan önce, BrowserPool'u devre dışı bırakmanın veya MaxIdleTabs = 0 belirlemenin zaten belirleyici her oluşturmada temizlik sağladığından emin olun. İzolasyon yaklaşımı, Docker veya Kubernetes ortamlarında, arka plan iş sistemlerinde ve daha sıkı bellek izolasyonuna ihtiyaç duyan API platformlarında en iyi sonucu verir.
4. İşçiyi Yalnızca Gerekli Olduğunda Yeniden Başlatma
Katı bir bellek sınırı olduğunda ve TarayıcıHavuzu ayarlamaları hala yetersiz kalıyorsa, belirli bir iş sayısından sonra işleme süreci veya işçi konteynerini yeniden başlatın. Bu, sabit bir iş yığınından sonra özel bir işçiyi yeniden başlatmak, Kubernetes'te motor konteynerlerini döndürmek veya bir hizmete işleme izole etmeyi ve bağımsız olarak yeniden başlatılabilir hale getirmeyi gerektirebilir. Bunu bir gecikmiş adım olarak düşünün, ilk hareketiniz değil.
Bir Sızıntı Olabileceği Zamanlar
İşleme sonrası yükseltilmiş bellek, otomatik olarak bir sızıntı anlamına gelmez. Chromium tabanlı işleme, iki tür yeniden kullanım içerir: tahsis edici seviyede yeniden kullanım, burada Chromium dahili olarak yerel bellek sayfalarını rezerve eder (normal, doğrudan denetlenemez) ve sekme seviyesinde yeniden kullanım, burada TarayıcıHavuzu, işlemler arasında tam sekmeler canlı tutar (yapılandırılabilir ve genellikle izleme araçlarında gördüğünüz en büyük katkıcı).
Desen, genellikle işleme sırasında bellek yükselirse, sınır büyümeksizin stabilize olursa, kısa bir süre yüksek kalırsa ve daha sonra boşta kalan sekmeler zaman aşımına uğradığında veya bir sonraki işleme için kullanılabilir kaldığında düşmesi beklenir.
Daha fazla araştırın:
bellek, benzer bir iş yükü altında stabil olmaksızın sürekli artıyorsa
eşzamanlılığı azaltmasına rağmen bellek büyümeye devam ediyorsa
BrowserPool devre dışı bırakıldıktan veya MaxIdleTabs = 0 ayarlandıktan sonra bile bellek büyümeye devam ediyor
kontrollü bir giriş ile aynı deseni zamanla gösteren minimal bir üretim gösteriyorsa
Destekle Ne Zaman İrtibata Geçilmeli
Tüm aşağıdakileri tekrar üretebiliyorsanız, teknik destek ile iletişime geçin:
bellek, kontrollü bir iş yükü altında stabil olmaksızın büyümeye devam ediyorsa
eşzamanlılığı sınırladıktan sonra sorun devam ediyorsa
sorun, BrowserPool devre dışı bırakıldıktan veya MaxIdleTabs = 0 ayarlandıktan sonra devam ediyor
Minimal bir örnek proje ile tekrarlayabiliyorsanız.
Bir bilet açarken, IronPDF sürümünüzü, işletim sistemi ve barındırma ortamınızı, Docker veya Kubernetes ayrıntılarını (varsa), programlama dilinizi, işleme sıklığı ve eşzamanlılık seviyenizi, bellek grafiklerinizi veya izleme ekran görüntülerini ve minimal yeniden üretilebilir bir örnek dosyayı ekleyin.
Curtis Chau, Bilgisayar Bilimleri alanında Lisans Derecesine (Carleton Üniversitesi) sahip ve Node.js, TypeScript, JavaScript ve React konularında uzmanlaşmış ön uç geliştirmeyle ilgileniyor. Sezgisel ve estetik açıdan hoş kullanıcı arayüzleri oluşturma tutkunu, Curtis modern çerçevelerle çalışmayı ve iyi yapılandırılmış, görsel olarak çekici kılavuzlar oluşturmayı seviyor.
