Sunucuda 16 GB bellek var, uygulama 2 GB kullanıyor ve yine de "bellek yetersiz" hatası veriyor. Sistem belleği boş — sınır işletim sisteminde değil, uygulamanın çalışma zamanı ayarındadır.
Bu yazı, uygulama çalışma zamanının bellek yönetimini ele alıyor.
İki Farklı Sınır
| Sınır | Kim koyar |
|---|---|
| Sistem belleği | Donanım ve işletim sistemi |
| Süreç sınırı | Kaynak kısıtları |
| Çalışma zamanı sınırı | Uygulama yapılandırması |
Üçüncü satır çoğu kafa karışıklığının kaynağıdır: uygulama çalışma zamanları kendi bellek tavanını taşır ve sistemde 16 GB boş olsa bile o tavanı aşmaz — hata sistemden değil uygulamadan gelir.
Bu sınır genellikle güvenlik amaçlıdır; kaçak bir işlemin tüm sunucuyu tüketmesini engeller.
İkinci satır ise konteyner ortamlarında devreye girer ve sonraki bölümde ele alınıyor.
Konteyner Tuzağı
Konteynerde çalışan uygulamalarda klasik bir sorun vardır:
- Konteynere bellek sınırı verilir.
- Uygulama sistem belleğini okur.
- Ana makinenin belleğini görür.
- Kendine fazla bellek ayırır.
- Sınırı aşınca öldürülür.
Üçüncü adım sorunun tam kalbidir: eski çalışma zamanları konteyner sınırlarını göremez ve ana makinenin toplam belleğine göre hesap yapar — 64 GB'lık bir sunucudaki 512 MB'lık konteynerde uygulama kendine gigabaytlarca yer ayırmaya çalışır.
Sonuç, açıklanamayan ve sık tekrarlayan süreç sonlandırmalarıdır.
Modern sürümler bu sınırı algılar ama eski sürümlerde bellek tavanının elle belirtilmesi gerekir.
Çöp Toplamanın Maliyeti
Otomatik bellek yönetimi ücretsiz değildir:
- Kullanılmayan nesneler tespit edilir.
- Bellek geri kazanılır.
- Bu işlem işlemci tüketir.
- Bazı aşamalarda uygulama durur.
Dördüncü madde kullanıcı deneyimini doğrudan etkiler: çöp toplama sırasındaki duraklamalar, ortalama yanıt süresini değiştirmese bile en yavaş yüzde birlik dilimi belirgin biçimde kötüleştirir.
Bu nedenle yanıt süresi grafiklerinde düzenli aralıklarla görülen sivri uçlar genellikle çöp toplamadır.
Bellek tavanı çok yüksek tutulduğunda toplama seyrek ama uzun olur; çok düşük tutulduğunda sık ama kısa olur.
Doğru Tavanı Seçmek
| Yaklaşım | Sonuç |
|---|---|
| Çok düşük tavan | Sık toplama, hata riski |
| Çok yüksek tavan | Uzun duraklamalar, israf |
| Sistemin tamamı kadar | Takas kullanımı riski |
| Ölçülmüş kullanımın üstü | Doğru yaklaşım |
Üçüncü satır ciddi bir hatadır: bellek tavanını sistemin tamamına eşitlemek, işletim sistemine ve disk önbelleğine hiç pay bırakmaz ve sunucu takas alanına düşerek dramatik biçimde yavaşlar.
İşletim sistemi ve diğer servisler için mutlaka pay bırakılmalıdır.
Dördüncü satır ise yöntemi gösterir. Gerçek kullanımı bir süre ölçüp üzerine makul bir pay eklemek doğru sonucu verir.
Birinci satır ise başta anlatılan hatayı üretir; uygulama sistemde bellek varken hata verir.
Bellek Sızıntısı Teşhisi
Sürekli artan bellek kullanımı bir sızıntı işaretidir:
- Kullanımı zaman içinde izleyin.
- Yeniden başlatma sonrası davranışa bakın.
- Bellek anlık görüntüsü alın.
- Nesne türlerini karşılaştırın.
Dördüncü madde asıl teşhis aracıdır: iki farklı zamanda alınan bellek görüntülerini karşılaştırmak, hangi nesne türünün sürekli arttığını ve dolayısıyla sızıntının kaynağını doğrudan gösterir.
Tek bir görüntü yalnızca o anki durumu verir; karşılaştırma eğilimi verir.
İkinci madde ise sızıntıyı doğrular. Yeniden başlatma sonrası kullanım sıfırlanıp tekrar tırmanıyorsa, sızıntı kesindir.
Sık karşılaşılan kaynaklar şunlardır: sınırsız büyüyen önbellekler, kapatılmayan bağlantılar ve kaldırılmayan olay dinleyicileri.
İşçi Süreç Dengesi
Bellek ayarı işçi sayısıyla birlikte düşünülmelidir:
- Her işçi kendi belleğini kullanır.
- Toplam, sistem belleğini aşmamalıdır.
- Zirve kullanımı hesaba katılmalıdır.
Üçüncü madde en sık yapılan hesap hatasıdır: işçi sayısını ortalama bellek kullanımına göre hesaplamak, tüm işçiler aynı anda ağır bir istek işlediğinde sunucunun bellek tükenmesine yol açar.
Hesap zirve kullanıma göre yapılmalıdır.
Pratik bir yöntem, işçi başına en yüksek bellek kullanımını ölçüp işçi sayısıyla çarpmak ve sonuca işletim sistemi payını eklemektir.
Bu toplam, sistem belleğinin altında kalmalıdır.
Periyodik Yeniden Başlatma
| Yaklaşım | Değerlendirme |
|---|---|
| Belirli istek sayısından sonra | Yaygın ve etkili |
| Bellek eşiği aşılınca | Daha akıllı |
| Zamanlanmış olarak | Kaba ama işe yarar |
Bu yaklaşım tartışmalıdır ama pratiktir: işçi süreçlerini belirli aralıklarla yeniden başlatmak sızıntıyı çözmez, ama etkisini ortadan kaldırır ve üretimi ayakta tutar.
Bunu kalıcı bir çözüm olarak görmemek gerekir; asıl sızıntı yine de bulunmalıdır.
İkinci satır daha zariftir çünkü yalnızca gerektiğinde devreye girer ve gereksiz yeniden başlatma yapmaz.
Önemli bir koşul vardır: yeniden başlatma kademeli olmalıdır. Tüm işçiler aynı anda yeniden başlarsa site anlık olarak yanıt veremez.
İzlenecek Metrikler
- Yığın kullanımı. Zaman içinde eğilim.
- Çöp toplama sıklığı ve süresi.
- Duraklama süreleri.
- Süreç sonlandırma olayları.
İkinci madde en erken uyarıyı verir: çöp toplama sıklığındaki artış, bellek baskısının arttığını hata oluşmadan önce haber verir — bu sinyal, sonlandırma olayından günler önce görülebilir.
Dördüncü madde ise geç kalmış bir uyarıdır ama tekrarlayan bir desen varsa çok bilgi verir.
Birinci madde ise sızıntı tespiti için temel veridir ve uzun süreli grafiklerde bakılmalıdır.
Bellek yoğun uygulamalar için doğru kapasiteyi seçmek gerekir; sanal sunucu altyapı hizmeti paketlerinde bellek yükseltmesi ihtiyaca göre yapılabilir.
Sonuç
"Sistemde bellek var ama uygulama hata veriyor" tablosunun nedeni nettir: çalışma zamanları kendi bellek tavanını taşır ve sistemde boş yer olsa bile o tavanı aşmaz. Konteyner kullanıyorsanız ekstra dikkat gerekir — eski sürümler konteyner sınırını göremez ve ana makinenin belleğine göre hesap yapar. Tavanı ölçülmüş kullanımın üstüne ayarlayın; sistemin tamamına eşitlemek işletim sistemine pay bırakmaz ve sunucu takasa düşerek dramatik yavaşlar.
Sıkça Sorulan Sorular (SSS)
Sistemde bellek varken neden hata alıyorum?
Çünkü uygulama çalışma zamanının kendi bellek tavanı vardır ve sistemde 16 GB boş olsa bile o tavanı aşmaz. Bu sınır genellikle güvenlik amaçlıdır — kaçak bir işlemin tüm sunucuyu tüketmesini engeller. Hata sistemden değil uygulamadan gelir.
Konteynerde süreçlerim neden öldürülüyor?
Eski çalışma zamanları konteyner bellek sınırını göremez ve ana makinenin toplam belleğine göre hesap yapar. 64 GB'lık bir sunucudaki 512 MB'lık konteynerde uygulama kendine gigabaytlarca yer ayırmaya çalışır ve sınırı aşınca öldürülür. Bellek tavanını elle belirtin.
Tavanı ne kadar ayarlamalıyım?
Gerçek kullanımı bir süre ölçüp üzerine makul bir pay ekleyin. Sistemin tamamına eşitlemeyin — işletim sistemine ve disk önbelleğine pay bırakmaz, sunucu takas alanına düşer ve dramatik yavaşlar. Ayrıca işçi sayısını zirve kullanıma göre hesaplayın, ortalamaya göre değil.
Bellek sızıntısını nasıl bulurum?
İki farklı zamanda bellek anlık görüntüsü alıp karşılaştırın — hangi nesne türünün sürekli arttığı sızıntının kaynağını doğrudan gösterir. Tek görüntü yalnızca o anı verir, karşılaştırma eğilimi verir. Sık kaynaklar: sınırsız büyüyen önbellekler, kapatılmayan bağlantılar ve kaldırılmayan olay dinleyicileri.
