Kaynak Sinirlama: Bir Uygulamanin Tum Sunucuyu Bogmasini Onlemek

Kaynak Sınırlama: Bir Uygulamanın Tüm Sunucuyu Boğmasını Önlemek

Gece çalışan bir rapor betiği kontrolden çıktı, belleği doldurdu ve işletim sistemi rastgele süreçleri sonlandırmaya başladı. Sabah baktığınızda veritabanı kapalı, web sunucusu yarı çalışır durumda. Suçlu tek bir işti ama bedeli tüm sunucuya çıktı.

Bu yazı, süreç başına kaynak sınırlamayı ele alıyor.

Sınır Neden Gerekir

İkinci satır en can alıcı farktır: bellek tükendiğinde işletim sistemi hangi süreci sonlandıracağına kendi ölçütüne göre karar verir ve bu ölçüt çoğu zaman en çok bellek kullanan süreci seçer — yani sorunu çıkaran betik değil, veritabanınız kapanabilir.

Bu davranış yönetici için tamamen sürpriz olur.

Üçüncü satır ise yalıtımın asıl faydasını gösterir.

Sınırlı çalışan bir iş, kendi sınırına çarpar ve durur.

Sınırlanabilen Kaynaklar

• Bellek üst sınırı.
• İşlemci payı.
• Disk okuma ve yazma hızı.
• Süreç sayısı.

Üçüncü madde en çok gözden kaçan ve en etkili olanıdır: bir yedekleme işi disk bant genişliğinin tamamını kullandığında veritabanı sorguları saniyelerce bekler — işlemci ve bellek boşta görünürken sistem tıkanmış olur.

Disk sınırlaması bu tıkanmayı önler.

Dördüncü madde ise kontrolsüz süreç üretimini engeller.

Hatalı bir betik saniyede yüzlerce süreç açabilir.

Bellek Sınırı Davranışı

1. Yumuşak sınır uyarı niteliğindedir.
2. Sert sınır aşılamaz.
3. Aşan süreç sonlandırılır.

Birinci ve ikinci maddeler birlikte kullanıldığında en iyi sonucu verir: yumuşak sınır aşıldığında sistem o gruptan bellek geri almaya çalışır ama süreci öldürmez — sert sınır ise mutlak tavandır ve aşılırsa süreç sonlandırılır.

Yumuşak sınır, geçici yük artışlarına esneklik tanır.

Sert sınır ise sunucuyu korur.

İkisinin arasında makul bir fark bırakmak doğru yaklaşımdır.

İşlemci Payı

İlk iki satır arasındaki fark, seçimi belirler: ağırlık yöntemi yalnızca rekabet varken devreye girer ve sunucu boştayken işin hızlanmasına izin verir; kota yöntemi ise sunucu tamamen boş olsa bile sınırı aşmaz.

Arka plan işleri için ağırlık genellikle daha verimlidir.

Öngörülebilirlik gerektiğinde kota tercih edilir.

Üçüncü satır ise çok soketli sistemlerde bellek yerelliği için kullanılır.

Servis Bazlı Uygulama

• Sınırlar servis tanımına yazılır.
• Yeniden başlatmada korunur.
• Her servis ayrı ayarlanır.

Birinci madde uygulamanın en temiz yoludur: sınırı servis tanımına yazmak, o servisin tüm alt süreçlerini de kapsar — betiğin açtığı yardımcı süreçler de aynı sınıra tabi olur ve kaçak kalmaz.

Elle başlatılan komutlarda bu kapsama sağlanamaz.

Üçüncü madde ise farklı önem düzeylerini yansıtır.

Veritabanına geniş, rapor betiğine dar sınır verilir.

Sınır Değerini Belirlemek

1. Önce normal kullanımı ölçün.
2. Tepe değerin üstüne pay bırakın.
3. İzleyip ayarlayın.

İkinci madde dengeyi kurar: sınırı normal kullanımın hemen üstüne koymak, olağan bir yük artışında servisin gereksiz yere durmasına yol açar — makul bir pay bırakmak, koruma ile kararlılık arasındaki dengeyi sağlar.

Çok geniş sınır ise koruma sağlamaz.

Birinci madde tahmin yerine ölçüme dayanmayı zorunlu kılar.

Üçüncü madde ise sınırların zamanla güncellenmesini sağlar.

Sınıra Çarpmayı Fark Etmek

Birinci satır sık yanlış yorumlanır: bellek sınırına çarpıp sonlandırılan bir servis, uygulama hatası varmış gibi görünür — oysa günlüklerde uygulamanın kendi hatası değil, sistemin sonlandırma kaydı vardır.

Bu ayrımı bilmek saatlerce zaman kazandırır.

Sınır kayıtları, hangi grubun sınıra çarptığını açıkça gösterir.

Bu sayaçlar düzenli izlenmelidir.

Nerelerde Kullanılır

• Arka plan iş süreçleri.
• Yedekleme ve arşiv görevleri.
• Çok kiracılı ortamlar.

İkinci madde en yüksek getiriyi sağlar: yedekleme işine disk hızı sınırı koymak, yedek biraz daha uzun sürer ama çalışma saatlerinde sitenin yavaşlamasını tamamen önler — bu takas neredeyse her zaman doğru taraftadır.

Üçüncü madde ise müşteriler arası adaleti sağlar.

Bir müşterinin yükü diğerlerini etkilememelidir.

Birinci madde ise kontrolsüz büyüyen işleri sınırlar.

Kaynak gruplarını tanımlayabilmek çekirdek düzeyinde yetki gerektirir; dedicated sunucu hizmeti ile kaynak yönetimini tamamen kendi denetiminizde tutabilirsiniz.

Sonuç

Sınırsız çalışan tek bir iş tüm sunucuyu düşürebilir çünkü bellek tükendiğinde işletim sistemi en çok bellek kullanan süreci seçer — yani sorunu çıkaran betik değil, veritabanınız kapanır. Sınırları servis tanımına yazın, ölçüme dayalı değer belirleyin ve disk hızı sınırını unutmayın: bir yedekleme işi disk bant genişliğini tükettiğinde işlemci boşken bile sistem tıkanır.

Sıkça Sorulan Sorular (SSS)

Neden yanlış servis kapanıyor?

Bellek tükendiğinde işletim sistemi hangi süreci sonlandıracağına kendi ölçütüne göre karar verir ve genellikle en çok bellek kullanan süreci seçer. Yani sorunu çıkaran rapor betiği değil, veritabanınız kapanabilir. Sınır koymak bu davranışı önler.

Sadece bellek ve işlemci mi sınırlanır?

Hayır, disk okuma ve yazma hızı da sınırlanabilir ve bu en çok gözden kaçan sınırdır. Bir yedekleme işi disk bant genişliğinin tamamını kullandığında veritabanı sorguları saniyelerce bekler; işlemci ve bellek boşta görünürken sistem tıkanmış olur.

Sınır değerini nasıl belirlemeliyim?

Önce normal kullanımı ölçün, tepe değerin üstüne makul bir pay bırakın ve izleyip ayarlayın. Sınırı normal kullanımın hemen üstüne koymak, olağan bir yük artışında servisin gereksiz durmasına yol açar; çok geniş sınır ise koruma sağlamaz.

Servisim düzenli yeniden başlıyor?

Bellek sınırına çarpıyor olabilir. Bu durum uygulama hatası varmış gibi görünür ama günlüklerde uygulamanın kendi hatası değil, sistemin sonlandırma kaydı vardır. Sınır sayaçları hangi grubun sınıra çarptığını açıkça gösterir.