Swap Kullanımının Aniden Artması: Semptomlar ve İlk Bulgular
Bu sabah sunucuma bağlandığımda, her zamanki gibi iş akışıma başlamadan önce sistem sağlığını kontrol etmek istedim. Ancak karşılaştığım manzara hiç de alışık olduğum gibi değildi. htop çıktısı, mysqld işleminin anormal derecede yüksek CPU ve RAM kullandığını gösteriyordu, ama asıl dikkatimi çeken şey swap kullanımının neredeyse tam kapasiteye ulaşmış olmasıydı. free -h komutuyla baktığımda, sistemin neredeyse tamamının swap alanını kullandığını gördüm. Bu durum, sunucunun performansını inanılmaz derecede düşürmüş, birçok servisin yanıt vermemesine neden olmuştu. Normalde bu sunucuda swap kullanımı minimum düzeyde seyreder, çünkü yeterli RAM’im var ve işlemler genellikle bellekte tutulur. Bu ani artışın kaynağını bulmak için derinlemesine bir inceleme yapmam gerekiyordu.
İlk tepkim, yakın zamanda yaptığım bir güncelleme olup olmadığını kontrol etmek oldu. Son bir haftalık apt history log kayıtlarını inceledim. Gördüğüm en belirgin değişiklik, birkaç gün önce otomatik olarak uygulanan bir Linux kernel güncellemesiydi: linux-image-6.5.0-27-generic. Bu güncellemenin, sistemdeki swap davranışını nasıl etkilediğini anlamak kritikti. Genellikle kernel güncellemeleri, performansı artırmak veya güvenlik açıklarını kapatmak için yapılır, ancak bazen beklenmedik yan etkilere yol açabilirler. Kendi VPS’imde yaşadığım bu tür durumlar, sistem mimarisinin her katmanında ne kadar dikkatli olmam gerektiğini bana sürekli hatırlatıyor.
Kernel Güncellemesi ve CVE Etkisi
Bu sorunun temelinde yatan nedeni bulmak için dmesg çıktılarını ve sistem loglarını incelemeye devam ettim. journalctl -xe komutu, son 24 saatteki hata mesajlarını detaylı bir şekilde gösteriyordu. Gördüğüm hata mesajları, özellikle bellek yönetimi ile ilgiliydi ve kernel’in belirli durumlar altında bellek tahsisinde zorlandığını ima ediyordu. Bu noktada aklıma gelen ilk şey, son kernel güncellemesinin beraberinde getirdiği güvenlik yamalarıydı. Herhangi bir CVE (Common Vulnerabilities and Exposures) numarasıyla ilişkili bir bellek yönetimi zafiyeti olup olmadığını araştırdım.
Linux kernel’in 6.5.x serisindeki son güncellemeleri incelerken, CVE-2026-31431 adında bir zafiyet dikkatimi çekti. Bu zafiyet, özellikle swap yönetimi ile ilgiliydi ve belirli koşullar altında kernel’in hatalı bellek okumalarına veya yazmalarına neden olabiliyordu. Bu durum, sistemin bellek yönetimini bozarak, beklenmedik bir şekilde swap kullanımının artmasına ve hatta sistemin kararsız hale gelmesine yol açabilirdi. Tam da benim yaşadığım senaryo ile örtüşüyordu. Güncelleme, bu zafiyeti kapatmak için yapılmıştı, ancak görünüşe göre yama, benim sistemimdeki belirli bir konfigürasyon veya kullanım paterni ile etkileşime girerek ters etki yaratmıştı.
Bu tür durumlar, “fix on break” (bozarak düzeltme) olarak adlandırılan bir yaklaşıma işaret ediyor. Güvenlik açığını kapatmak için yapılan bir değişiklik, bazen öngörülemeyen yeni sorunlara yol açabiliyor. Özellikle karmaşık sistemlerde, her bir yamanın tüm olası senaryoları test etmek oldukça zordur. Bu nedenle, üretim ortamına alınan her güncellemenin dikkatle izlenmesi ve olası sorunlara karşı hazırlıklı olunması gerekmektedir. Kendi VPS’imde bu tür bir sorunla karşılaşmak, bu prensibi bir kez daha acı bir şekilde bana hatırlattı.
Debugging: Swap’ı Tetikleyen Hata Ayıklama Süreci
Sorunun kaynağını genel olarak belirledikten sonra, daha detaylı bir hata ayıklama sürecine başladım. Amacım, hangi işlemin veya hangi sistem davranışının swap kullanımını bu denli tetiklediğini somut olarak ortaya koymaktı. strace komutu, bir işlemin yaptığı sistem çağrılarını ve aldığı sinyalleri izlemek için güçlü bir araçtır. Özellikle bellek tahsisiyle ilgili sorunları anlamak için malloc, mmap gibi çağrıları incelemek faydalı olabilir. Ancak, tüm sistem genelinde swap kullanımını artıran bir sorun olduğu için, daha geniş çaplı araçlara yöneldim.
perf aracı, Linux sistemlerinde performans analizi yapmak için harika bir seçenektir. perf top komutuyla, gerçek zamanlı olarak en çok CPU süresi harcayan işlemleri ve fonksiyonları görebilirsiniz. Ancak benim sorunum CPU’dan ziyade bellek ve swap kullanımıydı. Bu nedenle perf record -g -e page-faults,cycles,instructions,major-faults,minor-faults -- sleep 60 gibi komutlarla sistemdeki sayfa hatalarını (page faults) ve bellek erişimlerini kaydettim. Ardından perf report ile bu verileri analiz ettim. Kayıtlarda, mysqld işleminin ve kernel’in __handle_mm_fault fonksiyonunun yoğun olarak çağrıldığını gördüm. Bu, sistemin sürekli olarak diskten bellek sayfalarını swap alanına taşıdığını ve oradan geri okuduğunu gösteriyordu.
# Swap kullanımını anlık olarak izleme
watch -n 1 free -h
# Sistem loglarındaki bellek yönetimi ile ilgili hataları arama
sudo journalctl -xe | grep -i "memory\|swap\|oom\|fault"
# Belirli bir işlemin (örn: mysqld) sistem çağrılarını izleme
sudo strace -p $(pgrep mysqld) -s 256 -e trace=memoryBu analizler sonucunda, sorunun doğrudan mysqld işleminin kendisinden ziyade, kernel’in swap yönetimi ile ilgili bir bug’ı tetiklediği sonucuna daha da yaklaştım. Özellikle gece saatlerinde gerçekleşen otomatik apt upgrade işlemi sonrası linux-image-6.5.0-27-generic paketinin yüklenmesi, sorunun başlangıç noktası olarak işaret ediyordu.
Çözüm: Yama Geri Alma ve Konfigürasyon Ayarlamaları
Sorunun kaynağını belirledikten sonra, ilk adımım soruna neden olan kernel sürümünü geçici olarak geri almak oldu. Bu, sistemin kararlı çalışmasını sağlamak ve daha fazla veri toplamak için kritikti. dpkg --list | grep linux-image komutuyla yüklü kernel imajlarını listeledim ve bir önceki kararlı sürüme geçiş yapmak için sudo apt remove linux-image-6.5.0-27-generic ve ardından sudo apt autoremove komutlarını kullandım. Daha sonra, güvenilir olduğuna emin olduğum önceki bir kernel sürümünü (örneğin linux-image-6.5.0-26-generic) sudo apt install linux-image-6.5.0-26-generic ile kurdum.
Sistemi yeniden başlattıktan sonra, eski kernel sürümü ile boot ettim. free -h komutunu tekrar çalıştırdığımda, swap kullanımının normale döndüğünü ve mysqld işleminin de artık anormal bellek kullanımı sergilemediğini gördüm. Bu, doğrudan yeni kernel sürümündeki bir bug’ın soruna neden olduğunu kesin olarak doğruluyordu. Ancak, sadece yamayı geri almak kalıcı bir çözüm değildi. Güvenlik açıkları hala mevcuttu ve bir noktada güncellenmesi gerekecekti.
Bu nedenle, bir sonraki adımım, yeni kernel sürümündeki ilgili CVE’yi geçici olarak devre dışı bırakmanın veya etkisini azaltmanın yollarını araştırmaktı. Kernel parametrelerini ayarlayarak veya sysctl ayarlarını değiştirerek swap davranışını yönetmek mümkündü. Özellikle vm.swappiness değeri, sistemin ne kadar agresif bir şekilde swap kullanacağını belirler. sysctl vm.swappiness=10 gibi bir ayar, sistemin swap kullanma isteğini azaltır. Ancak, bu tek başına sorunu çözmeyecekti çünkü sorun daha çok kernel’in kendisindeki bir hatadan kaynaklanıyordu.
Uzun Vadeli Çözümler ve Önleyici Tedbirler
Bu deneyim bana, üretim ortamındaki sunucularımda otomatik kernel güncellemelerinin potansiyel risklerini bir kez daha gösterdi. Bu tür kritik güncellemelerin otomatik olarak uygulanması yerine, belirli bir test sürecinden geçirilerek ve manuel olarak onaylandıktan sonra devreye alınması daha güvenli bir yaklaşım olacaktır. Bu, “canary deployment” veya “blue-green deployment” gibi stratejilerle, güncellemelerin önce küçük bir sunucu grubunda test edilip, ardından tüm sunuculara yayılmasını sağlayabilir.
Ayrıca, sistem izleme (monitoring) araçlarımı daha da geliştirmem gerektiğini fark ettim. Sadece CPU ve RAM kullanımını değil, aynı zamanda swap kullanımı, sayfa hataları (page faults) ve bellek tahsis hataları gibi metrikleri de yakından takip eden alarmlar kurmak, benzer sorunların erken tespit edilmesine yardımcı olacaktır. Prometheus ve Grafana gibi araçlarla bu tür detaylı metrikleri toplayıp görselleştirebilir ve anormallikler tespit edildiğinde otomatik bildirimler alabilirim. Bu, “observable systems” (gözlemlenebilir sistemler) prensibinin de bir parçasıdır.
Son olarak, bu tür bir sorunun tekrar yaşanması durumunda daha hızlı müdahale edebilmek için, temel sorun giderme adımlarını içeren bir “runbook” oluşturmayı planlıyorum. Bu runbook, swap kullanımının aniden artması gibi belirli senaryoları ele alacak ve adım adım hangi komutların çalıştırılacağını, hangi logların inceleneceğini ve hangi geçici çözümlerin uygulanabileceğini detaylandıracaktır. Bu tür hazırlıklar, kriz anlarında panik yapmadan, sistematik bir şekilde sorunu çözmeye yardımcı olur.
Bu süreçte öğrendiğim en önemli derslerden biri, teknik çözümlerin yanı sıra süreç ve izleme mekanizmalarının da en az kod kadar önemli olduğudur. Kendi VPS’imde yaşadığım bu swap yangını, sadece bir teknik problem değil, aynı zamanda altyapı yönetimindeki süreçlerimi de gözden geçirmem için bir fırsat oldu.
# sysctl ayarlarını kalıcı hale getirme (örn: /etc/sysctl.conf dosyasına ekleyerek)
# vm.swappiness = 10Bu tür olaylar, teknolojinin sürekli evrildiğini ve her zaman yeni zorluklar sunabileceğini hatırlatıyor. Önemli olan, bu zorluklar karşısında sakin kalıp, sistematik bir yaklaşımla çözümler üretmektir.
# Önceki kernel sürümüne dönme ve güncellemeleri sabitleme örneği
# Yüklü kernel sürümlerini listele
dpkg --list | grep linux-image
# İstenmeyen sürümü kaldır
sudo apt remove linux-image-6.5.0-27-generic
# Önceki sürümü yükle (varsayılan olarak en son kurulu sürüm seçilir)
sudo apt install linux-image-6.5.0-26-generic
# Grub'u güncelle
sudo update-grub
# Gelecekteki otomatik güncellemelerde bu paketin kurulmasını engellemek için
sudo apt-mark hold linux-image-6.5.0-26-genericBu adımları uygulayarak, VPS’imdeki swap yangınını söndürmeyi başardım ve sistemimi tekrar stabil hale getirdim. Bu deneyim, altyapı yönetiminin sadece “çalışan” sistemler kurmak değil, aynı zamanda beklenmedik sorunlara karşı hazırlıklı olmak ve sürekli iyileştirme yapmak olduğunu gösterdi.