Bellek Sızıntısı Avı: Süreç Neden Sürekli Şişiyor?
Servisi yeniden başlattığınızda 200 megabayt bellek kullanıyor. Bir hafta sonra 3 gigabayt. Trafik artmadı, veri büyümedi, kod değişmedi. Bu tür kademeli büyüme, klasik bir bellek sızıntısının imzasıdır — ve bulunması sanıldığı kadar zor değildir.
Bu yazı, sızıntı teşhisini adım adım ele alıyor.
Sızıntı mı, Normal mi
| Desen | Yorum |
|---|---|
| Yüksele düşe seyreder | Normal |
| Bir noktada durulur | Normal, havuz doldu |
| Sürekli artar, hiç düşmez | Sızıntı |
| Yeniden başlatınca sıfırlanır | Sızıntı belirtisi |
İkinci satır çok sık yanlış teşhis edilir: bellek kullanımının artıp sonra sabitlenmesi sızıntı değildir — çalışma zamanı işletim sisteminden aldığı belleği genellikle geri vermez ve tepe kullanımda kalır.
Bu, çöp toplayıcılı dillerde normaldir.
Ayırt edici işaret, artışın hiç durmamasıdır.
Bu nedenle en az bir hafta gözlem gerekir.
Doğru Ölçüm
- Süreç bazında ölçün.
- Uzun süre kaydedin.
- Yeniden başlatmaları işaretleyin.
Üçüncü madde grafiği okunabilir kılar: bellek grafiğine dağıtım ve yeniden başlatma anlarını işaretlemek, testere dişi deseni ortaya çıkarır — her yeniden başlatmada sıfırlanıp yeniden tırmanan bir çizgi sızıntının kesin göstergesidir.
Bu desen tek bakışta anlaşılır.
İkinci madde ise yavaş sızıntılar için gereklidir.
Günde birkaç megabaytlık sızıntı ancak haftalarda görünür.
Yaygın Nedenler
- Büyüyen bellek içi listeler.
- Kapanmayan kaynaklar.
- Sınırsız önbellekler.
- Kaldırılmayan olay dinleyicileri.
Üçüncü madde en sık rastlanan gerçek nedendir: boyut sınırı olmayan bir uygulama içi önbellek, zamanla tüm belleği tüketir — çünkü hiçbir şey silinmez ve her yeni anahtar kalıcı olarak eklenir.
Bu tür önbellekler genellikle basit bir eşleme yapısıdır.
Geliştirme sırasında sorun çıkarmaz.
Uzun çalışan üretim süreçlerinde ise sızıntıya dönüşür.
Önbelleğe Sınır Koymak
| Kural | Etkisi |
|---|---|
| Girdi sayısı sınırı | Bellek tavanı belirlenir |
| Süre sınırı | Eski veriler düşer |
| En az kullanılanı at | Faydalılar kalır |
Birinci satır zorunlu bir kuraldır: bellek içi her önbelleğin bir üst sınırı olmalıdır — sınırsız bir önbellek, önbellek değil yavaş çalışan bir bellek sızıntısıdır.
Sınır, tahmini girdi boyutuna göre belirlenir.
Üçüncü satır ise sınıra ulaşıldığında ne atılacağını belirler.
Bu strateji isabet oranını korur.
Kapanmayan Kaynaklar
- Dosya tanıtıcıları.
- Veritabanı bağlantıları.
- Ağ soketleri.
Bu üçü bellek dışında da sorun üretir: kapatılmayan kaynaklar yalnızca bellek tüketmez, sistem sınırlarına da çarpar — bir süre sonra uygulama yeni dosya açamaz veya yeni bağlantı kuramaz hâle gelir.
Bu ikinci belirti genellikle daha erken fark edilir.
Açık tanıtıcı sayısı da izlenmelidir.
Sürekli artan bir sayaç, sızıntının kanıtıdır.
Profil Almak
- Bellek anlık görüntüsü alınır.
- Bir süre sonra tekrar alınır.
- Fark incelenir.
Üçüncü adım suçluyu doğrudan gösterir: iki anlık görüntü arasındaki farka bakmak, hangi tür nesnenin sayısının sürekli arttığını ortaya koyar — sızıntının kaynağı neredeyse her zaman bu listenin en üstündedir.
Çoğu çalışma zamanı bu aracı yerleşik sunar.
Görüntü almak geçici bir yavaşlama üretir.
Bu nedenle düşük trafikli saatlerde yapılmalıdır.
Geçici Önlem
| Önlem | Değerlendirme |
|---|---|
| Düzenli yeniden başlatma | Semptomu gizler |
| Bellek sınırı koymak | Sunucuyu korur |
| İşçi süreç yenilemek | Kesintisiz çözüm |
Üçüncü satır pratik bir ara çözümdür: belirli sayıda istek işleyen işçi süreçleri otomatik yenilemek, sızıntıyı kesinti yaşamadan sıfırlar — çünkü diğer işçiler istekleri karşılamaya devam eder.
Bu, birçok uygulama sunucusunun yerleşik özelliğidir.
Ama kalıcı çözüm değildir.
Birinci satır ise sorunu görünmez kılar ve araştırmayı erteler.
Kendi Kodunuz Olmayabilir
- Kütüphaneler de sızdırabilir.
- Sürüm notları kontrol edilmeli.
- Güncelleme çözebilir.
İkinci madde saatler kazandırabilir: kullandığınız kütüphanenin sürüm notlarında düzeltilmiş bir bellek sızıntısı kaydı varsa, kendi kodunuzu incelemeden önce güncellemeyi denemek en hızlı yoldur.
Bu, özellikle yaygın kütüphanelerde geçerlidir.
Sorun genellikle başkaları tarafından da yaşanmıştır.
Hata takip sistemlerinde arama yapmak yararlıdır.
Uzun çalışan süreçleri izleyebilmek ve profil alabilmek tam sunucu erişimi gerektirir; sanal sunucu sistem paketleri ile teşhis araçlarınızı sınırsız kullanabilirsiniz.
Sonuç
Her bellek artışı sızıntı değildir: bellek kullanımının artıp sonra sabitlenmesi normaldir, çünkü çalışma zamanı aldığı belleği genellikle geri vermez. Ayırt edici işaret, artışın hiç durmaması ve yeniden başlatmada sıfırlanmasıdır. En sık neden sınırsız önbelleklerdir — sınırsız bir önbellek, önbellek değil yavaş çalışan bir bellek sızıntısıdır. İki anlık görüntünün farkı suçluyu gösterir.
Sıkça Sorulan Sorular (SSS)
Bellek artışı her zaman sızıntı mıdır?
Hayır. Artıp sonra sabitlenen kullanım normaldir; çalışma zamanı işletim sisteminden aldığı belleği genellikle geri vermez ve tepe kullanımda kalır. Ayırt edici işaret, artışın hiç durmaması ve her yeniden başlatmada sıfırlanıp yeniden tırmanmasıdır.
En sık sızıntı nedeni ne?
Boyut sınırı olmayan uygulama içi önbellekler. Hiçbir şey silinmediği ve her yeni anahtar kalıcı eklendiği için zamanla tüm belleği tüketir. Geliştirme sırasında sorun çıkarmaz, uzun çalışan üretim süreçlerinde sızıntıya dönüşür.
Sızıntının kaynağını nasıl bulurum?
Bellek anlık görüntüsünü belirli aralıklarla iki kez alıp farkı inceleyin. Hangi tür nesnenin sayısının sürekli arttığı ortaya çıkar ve kaynak neredeyse her zaman bu listenin en üstündedir. Görüntü almak geçici yavaşlama ürettiği için düşük trafikli saatlerde yapın.
Düzenli yeniden başlatma çözüm mü?
Semptomu gizler, çözmez. Daha iyi bir ara çözüm, belirli sayıda istek işleyen işçi süreçleri otomatik yenilemektir; diğer işçiler istekleri karşılamaya devam ettiği için kesinti olmaz. Yine de kalıcı çözüm sızıntıyı bulmaktır.
