Sunucunuz sağlıklı çalışıyordu. Sonra bir rapor betiği başladı, tüm belleği yedi ve işletim sistemi en büyük süreci — veritabanınızı — kapattı. Site çöktü.
Bu senaryo, kaynak sınırı tanımlanmamış sistemlerde kaçınılmazdır. Bu yazı, sanal sunucunuzda süreçlere sınır koymayı anlatıyor.
Sınırsız Süreç Sorunu
Varsayılan olarak bir süreç, sistemde ne kadar kaynak varsa o kadarını kullanmaya çalışır. Sonuçları:
| Kaynak | Sınırsızken ne olur |
|---|---|
| Bellek | Sistem başka bir süreci kapatır |
| İşlemci | Diğer servisler yanıt veremez |
| Disk erişimi | Tüm sistem yavaşlar |
| Dosya tanıtıcı | Yeni bağlantı açılamaz |
| Süreç sayısı | Sisteme giriş bile yapılamaz |
İlk satır en yıkıcı olanıdır ve mekanizması sıkça yanlış anlaşılır: bellek tükendiğinde sistem, sorunu çıkaran süreci değil, en çok bellek kullanan süreci kapatır. Bu genellikle veritabanınızdır — yani suçlu betik hayatta kalırken asıl servisiniz düşer.
Son satır ise "çatal bombası" olarak bilinen durumdur: kendini sürekli kopyalayan bir süreç, süreç tablosunu doldurur ve sisteme yeni giriş yapılamaz hâle gelir.
Sınırlama Seviyeleri
Kullanıcı Bazlı Sınırlar
En temel ve en kolay uygulanan katmandır. Her kullanıcı için belirlenebilecekler:
- Açabileceği maksimum süreç sayısı
- Açabileceği maksimum dosya sayısı
- Kullanabileceği maksimum bellek
- Oluşturabileceği maksimum dosya boyutu
Bu sınırlar, özellikle çok kullanıcılı sunucularda bir kullanıcının diğerlerini etkilemesini önler. Süreç sayısı sınırı ise çatal bombasına karşı doğrudan koruma sağlar.
Servis Bazlı Sınırlar
Modern servis yöneticileri, her servis için kaynak sınırı tanımlamanıza izin verir. Bu, en pratik yöntemdir çünkü:
- Servis tanımının parçasıdır. Ayrı bir yapılandırma yönetmezsiniz.
- Servis yeniden başladığında korunur.
- Alt süreçleri de kapsar. Servisin başlattığı işlemler de sınırın içindedir.
Tanımlanabilecek başlıca sınırlar: bellek üst sınırı, işlemci payı ve disk erişim önceliği.
Uygulama Bazlı Sınırlar
Uygulamanın kendi yapılandırmasında da sınırlar vardır: web sunucusunun işçi süreç sayısı, veritabanının bellek havuzu, dil çalışma zamanının bellek limiti.
Bu katman sıkça atlanır ama kritiktir: web sunucusunun işçi sayısı × işçi başına bellek, toplam belleğinizi aşmamalıdır. Aşarsa, yoğun trafikte sistem belleği tükenir.
Basit Bir Hesap
Kaynak planlaması yaparken yapılacak temel hesap şudur:
- Toplam belleğinizden başlayın.
- İşletim sistemi için pay ayırın. Bu alan her zaman boş kalmalı.
- Veritabanı için sabit bir tahsis yapın. Bu, en öngörülebilir kalemdir.
- Kalan alanı web sunucusu ve arka plan işlerine bölün.
- İşçi sayısını bu paya göre belirleyin.
Beşinci adımdaki hesap belirleyicidir: kalan bellek payını, bir işçi sürecin ortalama bellek kullanımına bölün. Çıkan sayı, güvenle çalıştırabileceğiniz işçi sayısıdır.
Yaygın hata, işçi sayısını yüksek tutmaktır. Daha çok işçi, daha çok eşzamanlı istek demek değildir — bellek tükendiğinde hiç istek işlenemez. Az sayıda işçiyle sıraya girmek, çökmekten iyidir.
Öncelik Yönetimi
Sınırlamanın yanında, hangi işin öncelikli olduğunu belirlemek de mümkündür:
- İşlemci önceliği. Arka plan işleri, kullanıcı isteklerinden düşük öncelikte çalışsın.
- Disk erişim önceliği. Yedekleme işlemi, canlı sorguları yavaşlatmasın.
Bu iki ayar, gece yedekleme yapan sunucularda belirgin fark yaratır: yedekleme çalışırken site yavaşlıyorsa, çözüm genellikle yedekleme sürecinin önceliğini düşürmektir.
Bellek Tükenmesine Karşı Ek Önlemler
- Takas alanı tanımlayın. Bellek tükendiğinde sistemin tamamen kilitlenmesini önleyen bir tampon sağlar. Yavaştır ama çökmekten iyidir.
- Kritik servisleri koruyun. Sistem, bellek tükendiğinde hangi süreci kapatacağını bir puanlamayla belirler; bu puan ayarlanabilir.
- Bellek uyarısı kurun. Kullanım eşiği aşıldığında bildirim alın.
- Sızıntıları izleyin. Zamanla artan bellek kullanımı, düzeltilmesi gereken bir hatadır — sınırla gizlenmemelidir.
İkinci madde önemli bir ayardır: veritabanınızı koruma listesine alarak, bellek krizinde kapatılacak son süreç olmasını sağlayabilirsiniz.
Dördüncü madde ise bir uyarıdır: kaynak sınırı, kötü yazılmış bir uygulamanın çözümü değildir. Sınır sistemi korur ama sorunu ortadan kaldırmaz.
Sınırları Test Etmek
Tanımlanan sınırların gerçekten çalıştığını doğrulayın:
- Bilinçli olarak sınırı zorlayan bir test süreci çalıştırın
- Sürecin sınırda durdurulduğunu ve sistemin etkilenmediğini görün
- Loglarda olayın kaydedildiğini kontrol edin
- Uyarı bildiriminin geldiğini doğrulayın
Test edilmemiş bir sınır, gerçek kriz anında beklediğiniz gibi davranmayabilir. Kaynakları dar bir VDS paketinde bu testler özellikle değerlidir — sınırların doğru ayarlanması, kapasiteyi artırmadan kararlılık kazandırır.
Sonuç
Kaynak sınırı tanımlanmamış bir sunucuda tek bir kaçak süreç her şeyi durdurabilir — ve mekanizma sezgiye aykırıdır: bellek tükendiğinde sistem, suçlu süreci değil en çok bellek kullanan süreci kapatır, yani genellikle veritabanınızı. Sınırları üç katmanda kurun: kullanıcı, servis ve uygulama. En kritik hesap ise şudur: işçi sayısı × işçi başına bellek, toplam belleğinizi aşmamalıdır. Az işçiyle sıraya girmek, bellek tükenip hiç istek işlenememesinden iyidir.
Sıkça Sorulan Sorular (SSS)
Bellek tükenince neden veritabanım kapanıyor?
Sistem, bellek krizinde sorunu çıkaran süreci değil en çok bellek kullanan süreci kapatır — bu genellikle veritabanıdır. Kritik servisleri koruma listesine alarak bu davranışı değiştirebilir, ayrıca kaçak sürece bellek sınırı koyarak sorunu kaynağında çözebilirsiniz.
Web sunucusu işçi sayısını nasıl belirlemeliyim?
Sisteme ve veritabanına pay ayırdıktan sonra kalan belleği, bir işçi sürecin ortalama bellek kullanımına bölün. Yüksek işçi sayısı daha çok eşzamanlı istek demek değildir — bellek tükendiğinde hiç istek işlenemez.
Yedekleme çalışırken sitem yavaşlıyor, ne yapmalıyım?
Yedekleme sürecinin işlemci ve disk erişim önceliğini düşürün. Bu ayar, canlı isteklerin öncelikli işlenmesini sağlar ve gece yedekleme yapan sunucularda belirgin fark yaratır.
Kaynak sınırı, kötü kodun çözümü mü?
Hayır. Sınır sistemi korur ama sorunu ortadan kaldırmaz. Zamanla artan bellek kullanımı düzeltilmesi gereken bir hatadır; sınırla gizlenmemelidir. Sınırları bir güvenlik ağı olarak görün, çözüm olarak değil.
