7.6GB VPS’imde Swap Kullanımı Neden Fırladı?
Bu sabah sunucumdan bir uyarı geldi: Swap kullanımı anormal derecede yükselmiş. 7.6 GB RAM’e sahip bir VPS için bu beklenmedik bir durumdu. Normalde swap alanımı neredeyse hiç kullanmıyordum. Durumu anlamak için hemen sunucuya bağlandım ve htop komutuyla belleği kontrol ettim.
htop çıktısında, beklediğimden çok daha fazla swap alanı kullanıldığını gördüm. Bu durum, çalışan uygulamaların bellek ihtiyacının arttığını veya bir yerlerde bir bellek sızıntısı olduğunu gösteriyordu. İlk şüpheli olarak, yakın zamanda yaptığım bir kernel güncellemesini düşündüm.
Kernel Güncellemesi ve Swap Kullanımı
Birkaç gün önce, sunucumdaki Linux kernel’ini en son kararlı sürüme güncellemiştim. Bu güncellemeler genellikle güvenlik açıklarını kapatır ve performansı iyileştirir. Ancak bazen, beklenmedik yan etkilere de yol açabiliyorlar. Özellikle kernel modülleriyle ilgili yaşanan sorunlar, sistemin genel bellek yönetimi üzerinde ciddi etkiler bırakabiliyor.
Bu güncelleme sonrası swap kullanımının artması tesadüf olamazdı. Hemen sunucunun loglarını incelemeye başladım. Özellikle /var/log/syslog ve journalctl çıktılarına baktım. Bu loglarda, kernel’in bazı bellek tahsis etme işlemlerinde hata verdiğine dair ipuçları yakalamaya çalıştım.
Sorunun Kök Nedenini Bulmak: Debugging Süreci
Loglarda yaptığım incelemeler sonucunda, özellikle belirli bir kernel modülüyle ilgili hatalar dikkatimi çekti. Bu modül, ağ paketlerinin işlenmesiyle ilgiliydi ve yakın zamanda yamalanmış bir CVE (Common Vulnerabilities and Exposures) açığını kapatıyordu. Görünüşe göre, yama modülün bellek yönetiminde bir regresyona neden olmuştu.
Bu hatayı daha net anlamak için dmesg komutunu da kullandım. dmesg çıktısı, kernel’in bellek ayırma (allocation) ve serbest bırakma (deallocation) işlemlerinde sorunlar yaşadığını doğruluyordu. Bazı durumlarda, kernel’in tahsis ettiği bellek doğru şekilde serbest bırakılmıyordu ve bu da zamanla swap kullanımının artmasına yol açıyordu.
Hangi CVE ve Hangi Modül?
Araştırmalarım sonucunda, sorunun kaynağının algif_aead kernel modülündeki bir açıkla ilgili olduğunu tespit ettim. Bu modül, belirli şifreleme algoritmalarının donanım hızlandırmasını sağlıyordu. Yakın zamanda yayınlanan bir güvenlik yamasıyla bu açık kapatılmıştı, ancak yamanın kendisi bir bellek sızıntısına neden oluyordu. Bu durum, “fix”in “break”e dönüşmesinin klasik bir örneğiydi.
Bu noktada, bu sorunun sadece benim VPS’imle sınırlı kalmadığını, benzer sistemlerde de yaşanabileceğini fark ettim. Bu tür kernel düzeyindeki sorunlar, özellikle yüksek trafikli veya hassas uygulamalar barındıran sunucular için ciddi riskler oluşturabilir.
Geçici Çözüm: Swap Kullanımını Yönetmek
Sorunun kök nedeni kernel düzeyinde olduğu için, hızlı bir kalıcı çözüm bulmak zordu. Kernel geliştiricilerinin yeni bir yama yayınlamasını beklemek gerekiyordu. Bu süre zarfında, sunucunun kararlılığını sağlamak için geçici çözümler uygulamam gerekiyordu.
İlk olarak, sistemin swap kullanımını daha agresif bir şekilde yönetmesini sağlamak için swappiness değerini düşürdüm. swappiness, kernel’in RAM yerine swap alanını ne kadar kullanma eğiliminde olduğunu belirler. Değeri düşürmek, kernel’in RAM’i daha uzun süre kullanmasını teşvik eder.
Ayrıca, bazı bellek yoğun uygulamaların çalışma zamanlarını ayarlayarak veya daha az bellek tüketen alternatiflerini kullanarak genel bellek baskısını azaltmaya çalıştım. Bu, geçici bir önlem olsa da, swap kullanımının kontrol altına alınmasına yardımcı oldu.
sysctl Ayarlarıyla Swap Yönetimi
swappiness değerini ayarlamak için sysctl komutunu kullandım. Kalıcı olması için /etc/sysctl.conf dosyasına da gerekli ayarları ekledim.
# Mevcut swappiness değerini kontrol et
cat /proc/sys/vm/swappiness
# Swappiness değerini 10'a düşür (varsayılan genellikle 60'tır)
sudo sysctl vm.swappiness=10
# Kalıcı hale getirmek için /etc/sysctl.conf dosyasına ekle
# vm.swappiness=10Bu ayarlar, sunucunun swap alanını kullanma eğilimini azalttı. Ancak bu, sorunu kökten çözmedi, sadece semptomları hafifletti. Gerçek çözüm, yeni bir kernel yaması veya mevcut yamadaki hatanın düzeltilmesiyle gelecekti.
Kalıcı Çözüm: Yeni Kernel Yaması ve Sonrası
Birkaç gün sonra, kernel geliştiricileri algif_aead modülündeki bellek sızıntısını gideren yeni bir yama yayınladılar. Bu yamayı hemen sunucuma uyguladım ve sistemimi yeniden başlattım.
Yeni kernel sürümüyle birlikte, swap kullanımı normale döndü. htop çıktısında swap kullanımının neredeyse sıfıra indiğini görmek beni rahatlattı. Bu deneyim, kernel güncellemelerinin ne kadar kritik olduğunu ve bazen beklenmedik sorunlara yol açabileceğini bir kez daha gösterdi.
Dersler ve Geleceğe Yönelik Adımlar
Bu olaydan çıkardığım en önemli derslerden biri, üretim ortamlarında kernel güncellemelerini dikkatli bir şekilde yönetmek gerektiğidir. Yama uygulandıktan sonra sunucuyu bir süre yakından izlemek ve olası yan etkileri gözlemlemek önemlidir.
Ayrıca, sunucularımda otomatik bir izleme sistemi kurmanın ne kadar önemli olduğunu da anladım. Swap kullanımı gibi kritik metriklerde ani değişimler olduğunda otomatik uyarılar almak, sorunları erken tespit etmeme yardımcı olur.
Gelecekte, kernel güncellemelerini dağıtmadan önce bir staging ortamında test etmeyi planlıyorum. Bu, olası riskleri azaltacak ve üretim sunucularımda yaşanabilecek kesintileri önleyecektir. Bu küçük VPS’imdeki bu “swap yangını” olayı, bana sistem yönetimi konusundaki sürekli öğrenme ve adaptasyon gerekliliğini hatırlattı.