Kubernetes pod log’unda saatlerce sorunsuz çalışan Puppeteer scraper’ından sonra ‘OOMKilled’ diye haykıran mesajı görünce, Google’ın bu ‘headless Chrome’ oyuncakıyla ay vaat edip etmediğini sorgulamadın mı hiç?
Puppeteer bellek kullanımını profillemek akademik bir egzersiz değil. Node.js dünyasında hayatta kalmak için şart, RSS sinsi sinsi yükselip konteynerin patlayana dek.
Bak, Node daha toy bir başlangıççken V8 sızıntılarını kovalamaktan Stack Overflow gecelerine alışığım. Puppeteer? Aynı hikâye, parlak ambalajla. PR’lar ‘kolay tarayıcı otomasyonu’ diye övüyor – ama kazanan kim? Faturaların şişmesinden bankalara gülen bulut sağlayıcılar.
Puppeteer Neden Bellek Sızıntısı Yapıyor – Ve Makaleler Neden Bunu Atlıyor?
Çoğu rehber Node’un heapUsed’ine takılıyor. Yanlış.
İşte çoğu makalenin kaçırdığı nokta: Puppeteer’ın gerçek bellek kullanımı Chrome’un alt süreçlerinde, Node.js’te değil. Node süreci sadece referans tutuyor. ‘Küçük’ bir Node heap’i yanında 2 GB Chrome süreci varsa, sorun hâlâ 2 GB.
Bu alıntı tam oturuyor. Node’un process.memoryUsage() RSS, heapUsed, heapTotal, external veriyor. RSS toplam ayak izi – kod, stack, heap, buffer’lar. Ama Chrome’un renderer süreçleri? Dışarıda pusuda, sayfalar, ekran görüntüleri, fontlar için RAM yutuyor. ‘Hafif’ script’in? Bellek yutağı ailesi.
Ve benim orijinal kodlarımdaki sıcak yorumum: Bu PhantomJS günlerini hatırlatıyor. Hatırlıyor musun? Herkes ‘modern Chrome DevTools’ diye Puppeteer’a geçti. Beş yıl sonra – aynı şişkinlik, şimdi WebAssembly bahaneleriyle. Tahminim: 2026’ya kadar Playwright ya da Rust tabanlı bir tarayıcı koşucusu yerini alır, Google alt RAM’i zorla karantinaya almasa.
Basit başla. Belleği düzenli log’la.
function logMemory(label = '') {
const mem = process.memoryUsage();
const format = bytes => (bytes / 1024 / 1024).toFixed(1) + 'MB';
console.log(`[${label}] rss=${format(mem.rss)} heap=${format(mem.heapUsed)}/${format(mem.heapTotal)} external=${format(mem.external)}`);
}
Her yere koy. Ama zaman serisi yap. Tek snapshot? İşe yaramaz.
Gerçekten İşe Yarayan Puppeteer Bellek Takibi Nasıl Kurulur
Bir takipçi kur. Grafik için JSONL çıkışı – spreadsheet’ler ya da hızlı script’lerle creep’i gösteren chart’lara çevir.
const fs = require('fs');
class MemoryTracker {
// ... (orijinalden tam sınıf, ama birebir kopyalamadan uyarla)
}
Ben şöyle ayarlıyorum: Yük altında her 2-5 saniyede log’la. Her page.goto() ya da screenshot’a incrementRequests() bağla. Baseline için idle çalıştır: Başlatma öncesi (50-80MB RSS), sonrası (150-250MB), ısınma sayfası sonrası (160-270MB). Zaten uçuk? Suçlu başlatma argümanları – GPU’yu, uzantıları at, tam headless ‘new’ git.
Sonra stres testi. 3 concurrency, 200 URL. Batch’leri izle: Promise.all dilimlerde, finally{}’te sayfaları acımasızca kapat.
Ama baseline’ler Chrome parçalanmasında yalan söyler. heapTotal şişip heapUsed düşükse? V8 sıkıştırma sorunu. External patlarsa? Dev ekran görüntüleri ya da PDF blob’ları.
Puppeteer Sızıntıları İçin Heap Snapshot Almak Baş Ağrısına Değer mi?
Evet – benim gibi şüpheciysen.
Tahmin yürütmek başarısız olur. Snapshot’lar tutulan objeleri gösterir. Adımlar: chrome://flags/#enable-heap-snapshots, sonra –heap-profiler-allocations ya da clinic.js.
Baseline snap al. Yük testi yap. Farklarını incele. Pat – kopmuş DOM nod’ları, eski sevgili gibi yapışan event listener’lar, temizlenmemiş sayfalar.
Kovaladığım gerçek sızıntı: İşler arası browser tam kapanmıyordu. pages dizisi büyüyordu. Çözüm? browser.close()’u setTimeout’a koy, tek browser örneğini döngüye sok. Bellek düzleşti.
PR’lar ‘yeni browser başlat’ diyor. Sevimli – ölçek vurana dek.
Özel durum: Puppeteer Chrome’un renderer bellek tuhaflıklarına bağlı. Erken Chrome (2015 öncesi) sekmelerde sızdırıyordu; şimdi headless’te WebGL canvas’lar. PDF üretiminde? Denetlenmezse SVG’leri raster’lamak sayfa başına 500MB yiyor.
Puppeteer Belleğini Düzeltme: Yapışkan Acımasız Kesintiler
Sayfaları kapat. Her z
