Sunucunuzdaki bir servis, siz hiçbir şey yapmadan gecenin bir yarısı kapandı ve logda net bir hata yok. Bu tablo neredeyse her zaman aynı şeye işaret eder: bellek tükenmiştir ve işletim sistemi, sistemi ayakta tutmak için bir süreci sonlandırmıştır.
Bu rehber, kendi sanal sunucunuzda bellek davranışını doğru okumayı ve bu tür kapanmaları önlemeyi anlatıyor.
Önce Yaygın Bir Yanlış Okuma
Sunucuya bakıp "boş belleğim çok az, RAM eklemem lazım" sonucuna varmak, Linux'ta genellikle hatalıdır.
Linux, kullanılmayan belleği boş bırakmaz — disk önbelleği olarak kullanır. Bu, okunan dosyaları bellekte tutup tekrar okumaları hızlandıran istenen bir davranıştır. Uygulamalar belleğe ihtiyaç duyduğunda sistem bu önbelleği anında serbest bırakır.
Dolayısıyla "boş bellek" değeri düşük olabilir ve bu tamamen normaldir. Bakmanız gereken metrik kullanılabilir bellek ve takas (swap) kullanımıdır.
Takas Alanı: Yastık mı, Tuzak mı?
Takas alanı, bellek dolduğunda kullanılmayan bellek sayfalarının diske taşındığı alandır. Disk, bellekten kat kat yavaştır — dolayısıyla takas kullanımı başladığı anda performans belirgin biçimde düşer.
Buradan iki yanlış sonuç çıkarılır ve ikisi de hatalıdır:
- "Takas kötüdür, hiç olmasın." Takas alanı olmayan bir sunucuda bellek dolduğunda sistemin başka seçeneği kalmaz: bir süreci hemen sonlandırır. Takas alanı, bu ana kadar size bir tampon ve müdahale şansı verir.
- "Bol takas koyayım, bellek sorunu çözülür." Takas, bellek yerine geçmez. Sistem takasta çalışmaya başladığında hizmet pratikte kullanılamaz hâle gelir — teknik olarak ayakta ama işlevsel olarak çökmüş sayılır.
Doğru yaklaşım: makul bir takas alanı bulundurun ama kullanılmasını bir alarm olarak kabul edin. Kalıcı takas kullanımı, gerçek bellek yetersizliğinin kanıtıdır.
OOM Killer: Sessiz Kapanmanın Nedeni
Bellek tamamen tükendiğinde ve takas da yetmediğinde, işletim sistemi bir karar vermek zorundadır: ya tüm sistem kilitlenecek ya da bir süreç sonlandırılacak. İkinciyi seçer.
Sonlandırılacak süreci bir puanlama sistemiyle belirler ve bu puanlama, en çok bellek kullanan süreci hedefler. Sorun şudur: en çok bellek kullanan süreç genellikle en önemli olanıdır — veritabanı sunucunuz.
Bu yüzden tipik senaryo şöyledir: bir bellek sıçraması yaşanır, sistem veritabanını sonlandırır, siteniz çöker ve uygulama loglarında "veritabanına bağlanılamıyor" hatası görürsünüz. Asıl neden ise bellek tükenmesidir ve o, sistem loglarında kayıtlıdır.
Nasıl Doğrularsınız?
Bir servis açıklanamayan biçimde kapandıysa sistem loglarında bellek tükenmesi kayıtlarını arayın. Orada hangi sürecin, ne zaman ve hangi bellek durumunda sonlandırıldığı yazar. Bu kayıt varsa teşhis kesindir ve uygulama loglarında saatler harcamanıza gerek kalmaz.
Bellek Tükenmesinin Tipik Nedenleri
| Neden | Belirti | Çözüm |
|---|---|---|
| Fazla web sunucusu işçisi | Trafik sıçramasında çökme | İşçi sayısını belleğe göre hesapla |
| Veritabanı havuzu fazla ayarlanmış | Kalıcı takas kullanımı | Havuzu düşür, pay bırak |
| Tek istekte devasa veri | Belirli sayfada çökme | Sorguyu parçala, sayfalama ekle |
| Bellek sızıntısı | Zamanla artan tüketim | Süreçleri periyodik yenile |
| Zamanlanmış görev sıçraması | Hep aynı saatte çökme | Görevi parçala, saati kaydır |
| Üst üste binen görevler | Kademeli tükenme | Kilit mekanizması kur |
Beşinci satır özellikle tanıdıktır: "her gece saat üçte site çöküyor" şikayetinin nedeni neredeyse her zaman o saatte çalışan bir yedekleme veya toplu işlem görevidir.
İşçi Sayısı Hesabı
Web sunucusu işçi sayısı, bellek tükenmesinin en yaygın nedenidir ve doğru hesaplaması basittir:
- Tek bir işçinin ortalama bellek tüketimini ölçün.
- Sunucunun toplam belleğinden işletim sistemi, veritabanı ve diğer servisler için pay ayırın.
- Kalan belleği tek işçi tüketimine bölün.
- Çıkan sayının biraz altını üst sınır olarak belirleyin.
Varsayılan yapılandırmalar bu hesabı yapmaz — genel bir değer kullanır. Bu değer sunucunuz için fazlaysa, trafik sıçramasında sistem bellek tükenmesine gider.
Önleyici Ayarlar
- Kritik servisleri koruyun. Sistem, hangi süreçlerin sonlandırılmasının daha az tercih edilir olduğunu belirlemenize izin verir. Veritabanı sunucunuzu bu şekilde korumak, tipik çökme senaryosunu tersine çevirir.
- Servis yeniden başlatma politikası tanımlayın. Bir servis sonlandırılırsa otomatik olarak ayağa kalksın. Sorunu çözmez ama kesinti süresini dakikalardan saniyelere indirir.
- Uygulama seviyesinde bellek sınırı koyun. Tek bir kötü istek, tüm belleği tüketemesin.
- Süreçleri periyodik yenileyin. Bellek sızıntısı olan uygulamalarda, işçileri belirli sayıda istekten sonra yeniden başlatmak pratik bir çözümdür.
- Takas kullanımı için uyarı kurun. Takas kullanılmaya başladığı anda haber alın — bu, çökmeden önceki son uyarıdır.
Ne Zaman Gerçekten RAM Eklemeli?
Yukarıdaki ayarları yaptıktan sonra hâlâ takas kalıcı olarak kullanılıyorsa, artık gerçek bir bellek ihtiyacı var demektir. O noktada bellek eklemek doğru ve en doğrudan etki eden yükseltmedir.
Ancak sıralamayı bozmayın: ayar yapmadan bellek eklemek, yanlış yapılandırılmış bir sistemin daha büyük donanımda aynı hatayı tekrarlamasına yol açar — sorun büyümeyle birlikte geri gelir.
Sonuç
Bellek sorunlarında en önemli üç şey şudur: "boş bellek" değerine değil takas kullanımına bakmak, açıklanamayan servis kapanmalarında sistem loglarındaki bellek tükenmesi kayıtlarını kontrol etmek ve web sunucusu işçi sayısını sunucunuzun gerçek belleğine göre hesaplamak. Bu üçü, sessiz kapanmaların büyük bölümünü hem teşhis eder hem önler. Kaynakların size ayrıldığı bir VDS sunucu ortamında bu ayarların tamamı sizin kontrolünüzdedir.
Sıkça Sorulan Sorular (SSS)
Boş belleğim çok az, sorun mu?
Genellikle hayır. Linux kullanılmayan belleği disk önbelleği olarak kullanır ve ihtiyaç halinde serbest bırakır. Bakmanız gereken metrik kullanılabilir bellek ve takas kullanımıdır — takas boşsa bellek sıkıntınız yok demektir.
Ne kadar takas alanı ayırmalıyım?
Bellek sıçramalarında tampon görevi görecek kadar; bellek yerine geçecek kadar değil. Amaç, sistemin bir süreci hemen sonlandırmak yerine size müdahale şansı vermesidir. Kalıcı takas kullanımı ise çözüm değil, alarm sayılmalıdır.
Servisim kendiliğinden kapandı, nasıl doğrularım?
Sistem loglarında bellek tükenmesi kayıtlarını arayın. Orada hangi sürecin ne zaman sonlandırıldığı yazar. Bu kayıt varsa teşhis kesindir; uygulama loglarında görünen "bağlanılamıyor" hataları yalnızca sonuçtur.
RAM eklemek sorunu çözer mi?
Gerçek bellek yetersizliği varsa evet. Ancak sorun yanlış ayarlanmış işçi sayısı veya kontrolsüz bir zamanlanmış görevse, daha büyük bellek yalnızca çökme anını erteler. Önce ayarları düzeltin, sonra hâlâ gerekiyorsa bellek ekleyin.
