Swap Kullanımı: Ne Zaman Sorun Olur ve Nasıl Çözülür

Bir gece yarısı pagerinden gelen alarm sesi, sysadmin’lerin korkulu rüyasıdır. Ekrana bakıyorsunuz: sunucu cevap vermiyor, SSH bağlantısı 30 saniyede bir kopuyor ve top çıktısında swap kullanımı %95’te. İşte o anda “swap neden bu kadar dolu?” sorusu hayatınızın en önemli sorusu haline geliyor. Swap yönetimi, Linux performans optimizasyonunun en çok göz ardı edilen ama en kritik parçalarından biridir. Bu yazıda swap’ın ne zaman normal, ne zaman alarm verici olduğunu, ve sorun çıktığında ne yapmanız gerektiğini gerçek senaryolarla ele alacağız.

Swap Nedir ve Nasıl Çalışır?

Swap, RAM dolduğunda işletim sisteminin disk üzerinde kullandığı sanal bellek alanıdır. Linux, aktif kullanılmayan bellek sayfalarını swap’a taşır (bu işleme “swapping out” denir) ve böylece fiziksel RAM’i daha aktif süreçler için serbest bırakır. Kavramsal olarak güzel görünüyor, ancak pratikte swap kullanımı çoğu zaman bir semptomdur, sorunun kendisi değil.

Swap iki farklı şekilde yapılandırılabilir:

• Swap partition: Disk üzerinde ayrı bir bölüm olarak ayrılmış alan
• Swap file: Dosya sistemi üzerinde bir dosya olarak oluşturulmuş swap alanı

Modern sistemlerde swap file kullanımı çok daha yaygın hale geldi çünkü boyutunu dinamik olarak değiştirebiliyorsunuz.

Swap Kullanımını İzlemek

Önce mevcut durumu anlamak için doğru araçlara bakalım.

free Komutu ile Genel Bakış

free -h

Çıktı şuna benzer bir şey verecektir:

              total        used        free      shared  buff/cache   available
Mem:           15Gi       8.2Gi       1.1Gi       512Mi       6.1Gi       6.8Gi
Swap:           7Gi       4.2Gi       2.8Gi

Burada dikkat etmeniz gereken nokta şu: available kolonu, free kolonundan çok daha önemlidir. Available, mevcut uygulamalara sunulabilecek toplam belleği gösterir ve buff/cache’den geri alınabilecek alanı da içerir.

vmstat ile Gerçek Zamanlı İzleme

vmstat 2 10

Bu komut, 2 saniye aralıklarla 10 kez sistem istatistiklerini gösterir. Swap açısından şu kolonlara bakın:

• si (swap in): Diskten RAM’e okunan KB/saniye
• so (swap out): RAM’den diske yazılan KB/saniye

Eğer si ve so kolonlarında sürekli sıfır olmayan değerler görüyorsanız, sisteminiz aktif olarak swap kullanıyor demektir. Bu durum thrashing olarak adlandırılır ve ciddi performans sorununa işaret eder.

swapon ile Detaylı Swap Bilgisi

swapon --show

swapon -s

Bu komutlar swap alanlarınızın detaylı listesini, tipini, boyutunu ve kullanım yüzdesini gösterir.

/proc/meminfo ile Derin Analiz

cat /proc/meminfo | grep -E "Swap|Mem"

Bu dosya, swap ile ilgili çok daha granüler bilgi verir. SwapCached değeri özellikle önemlidir: swap’a taşınmış ama hâlâ RAM’de bir kopyası olan sayfaları gösterir.

Swappiness: Sistemin Swap’a Olan İştahı

Linux çekirdeğinin swap kullanma eğilimini kontrol eden parametre swappiness‘tir. 0 ile 100 arasında bir değer alır.

cat /proc/sys/vm/swappiness

Genellikle varsayılan değer 60’tır. Bu şu anlama gelir: sistem, RAM’in %40’ı dolduğunda swap kullanmaya başlamayı tercih eder. Ancak bu değer sezgisel bir anlam taşımaz, sadece çekirdeğin swap’ı tercih etme ağırlığını temsil eder.

Değerlerin yorumlanması:

• 0: Swap’tan mümkün olduğunca kaçın, sadece zorunlu olduğunda kullan
• 1-10: Swap kullanımını minimize et (veritabanı sunucuları için ideal)
• 60: Varsayılan, genel amaçlı kullanım
• 100: Agresif swap kullanımı, mümkün olan her şeyi swap’a taşı

Kalıcı olarak değiştirmek için:

echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p

Geçici olarak (reboot’a kadar) değiştirmek için:

sysctl vm.swappiness=10

Hangi Process Swap Kullanıyor?

Swap sorununun kaynağını bulmak için hangi süreçlerin swap kullandığını tespit etmek şarttır.

for file in /proc/*/status; do
  awk '/VmSwap|Name/{printf $2 " " $3 "n"}' $file
done 2>/dev/null | sort -k 2 -n -r | head -20

Bu script, sistemdeki tüm processlerin swap kullanımını bulup büyükten küçüğe sıralar. Çıktıda bir process diğerlerinden çok daha fazla swap kullanıyorsa, sorunun kaynağı muhtemelen odur.

Alternatif olarak smem kullanabilirsiniz (önce kurmanız gerekebilir):

smem -s swap -r | head -20

Gerçek Dünya Senaryoları

Senaryo 1: Java Uygulaması Gece Yarısı Swap Patlatıyor

Bir e-ticaret şirketinde Java tabanlı bir uygulama sunucusu yönetiyordunuz. Her gece saat 02:00’de çalışan batch işlemi başladığında sunucu ağır swap kullanımına giriyor ve sabah 08:00’de normal trafik başlayınca sistem neredeyse donuyordu.

Teşhis adımları:

# Her 5 saniyede swap kullanımını logla
while true; do
  echo "$(date): $(free -m | grep Swap)" >> /var/log/swap_monitor.log
  sleep 5
done

Bu basit script ile swap kullanımının zaman içindeki değişimini kayıt altına alabilirsiniz. Sabah log’lara baktığınızda tam olarak ne zaman swap’ın patladığını görebilirsiniz.

Çözüm bu vakada üç adımlıydı: JVM heap boyutunu batch işlemine uygun şekilde ayarlamak, batch işlemini off-peak saatte çalışmayı kısıtlamak (nice ile önceliğini düşürerek) ve swappiness değerini 60’tan 10’a indirmek.

Senaryo 2: PostgreSQL Performans Sorunu

Veritabanı sunucularında swap kullanımı özellikle kritiktir. PostgreSQL’in swap’a düştüğü anda sorgu süreleri saniyelerden dakikalara çıkabilir.

# PostgreSQL için önerilen sysctl ayarları
cat >> /etc/sysctl.conf << EOF
vm.swappiness=1
vm.dirty_ratio=10
vm.dirty_background_ratio=5
EOF

sysctl -p

PostgreSQL sunucularında swappiness’i 1 yapmanız önerilir. Neden 0 değil? Çünkü 0 değeri bazı kernel versiyonlarında OOM (Out of Memory) killer’ı çok agresif tetikleyebilir.

Senaryo 3: VPS’te Bellek Yetersizliği

Küçük bir 1GB RAM’li VPS’te bir web uygulaması çalıştırıyorsunuz ve swap sürekli dolup taşıyor. Swap file eklemek geçici bir çözüm sunabilir:

# 2GB swap file oluştur
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Kalıcı hale getir
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Ancak şunu unutmayın: bu çözüm performans sorununu ortadan kaldırmaz, sadece sistem çökmesini geciktirir. Asıl çözüm RAM’i artırmak veya uygulamayı optimize etmektir.

Swap Dolduğunda Ne Olur?

Swap tamamen dolduğunda Linux’ta üç senaryo gerçekleşebilir:

OOM Killer devreye girer: Kernel, bellek tüketen süreci tespit ederek öldürür. Hangi sürecin öldürüldüğünü görmek için:

dmesg | grep -i "oom|killed"

ya da:

journalctl -k | grep -E "oom|killed process"

Sistem tamamen donabilir: Tüm memory isteği reddedildiğinde, süreçler bellek beklerken sıkışabilir.

Kritik sistem süreçleri çöker: SSH daemon veya init sistemi bile etkilenebilir ve sunucuya erişim tamamen kesilir.

OOM Killer’ın belirli bir süreci öldürmesini önlemek için:

# Süreci OOM Killer'dan koru (-17 değeri)
echo -17 > /proc/$(pgrep sshd | head -1)/oom_adj

# Yeni kernel versiyonlarında
echo -1000 > /proc/$(pgrep sshd | head -1)/oom_score_adj

Swap Temizleme Yöntemleri

Acil bir durumda swap’ı temizlemek gerekiyorsa şu yöntemleri kullanabilirsiniz. Ancak dikkatli olun: bu işlem yeterli RAM yoksa sistemi dondurabilir.

# Mevcut bellek durumunu kontrol et
free -h

# Swap'ı geçici olarak kapat ve aç (swap'taki her şey RAM'e çekilir)
swapoff -a && swapon -a

Bu komutu çalıştırmadan önce mutlaka free -h ile RAM’de yeterli boş alan olduğundan emin olun. Örneğin 4GB swap doluysa ve RAM’de 1GB yer varsa bu komut sistemi kilitleyecektir.

Daha güvenli bir yaklaşım şu şekildedir:

# RAM ve swap durumunu kontrol et
echo "=== Mevcut Durum ==="
free -h
echo ""
echo "=== En Fazla Swap Kullanan Processler ==="
for file in /proc/*/status; do
  awk '/VmSwap|Name/{printf $2 " " $3 "n"}' $file
done 2>/dev/null | sort -k 2 -n -r | head -10

Kalıcı Çözümler ve Önleyici Tedbirler

Memory Limit ile Process İzolasyonu

systemd kullanan sistemlerde servis başına bellek limiti koyabilirsiniz:

# /etc/systemd/system/myapp.service dosyasına ekle
[Service]
MemoryMax=2G
MemorySwapMax=0

MemoryMax: Servisin kullanabileceği maksimum RAM MemorySwapMax=0: Bu servis için swap kullanımını tamamen engelle

Değişiklikleri uygulamak için:

systemctl daemon-reload
systemctl restart myapp

Zabbix veya Prometheus ile Swap Alertleri

İzleme sistemine swap alarmı eklemek kritik önem taşır. Bash ile basit bir monitoring scripti:

#!/bin/bash
# /usr/local/bin/check_swap.sh

THRESHOLD=80
SWAP_USED=$(free | grep Swap | awk '{if($2>0) print int($3/$2*100); else print 0}')

if [ "$SWAP_USED" -gt "$THRESHOLD" ]; then
    echo "CRITICAL: Swap kullanimi %${SWAP_USED} - Esik deger: %${THRESHOLD}"
    # Buraya email veya Slack notification eklenebilir
    exit 2
elif [ "$SWAP_USED" -gt "60" ]; then
    echo "WARNING: Swap kullanimi %${SWAP_USED}"
    exit 1
else
    echo "OK: Swap kullanimi %${SWAP_USED}"
    exit 0
fi

Bu scripti cron’a ekleyin:

*/5 * * * * /usr/local/bin/check_swap.sh >> /var/log/swap_check.log 2>&1

Huge Pages ile Bellek Optimizasyonu

Büyük veritabanı sunucularında Transparent Huge Pages (THP) bazen swap baskısını artırabilir. Özellikle MongoDB ve Redis belgeleri THP’yi kapatmanızı önerir:

# Mevcut THP durumunu kontrol et
cat /sys/kernel/mm/transparent_hugepage/enabled

# Devre dışı bırak
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Kalıcı hale getirmek için rc.local veya systemd unit kullan

Ne Zaman Swap Sorun Değildir?

Her swap kullanımı acil durum değildir. Şu durumlar normaldir:

• Sunucu uzun süredir çalışıyor ve bazı süreçlerin eski bellek sayfaları swap’ta bekliyor ama si/so değerleri sıfır
• Geceleri batch işlemi çalışırken kısa süreli swap artışı, gün içinde normale dönüyor
• Swappiness yüksek ayarlanmış ve kernel çeşitli sayfaları proaktif olarak swap’a taşıyor ama sistem yavaşlamıyor

Gerçek sorun şu koşullarda vardır:

• vmstat çıktısında si ve so kolonları sürekli sıfır olmayan değerler gösteriyor (aktif thrashing)
• Swap kullanımı giderek artıyor ve azalmıyor
• Uygulama yanıt süreleri belirgin şekilde uzuyor
• CPU wa (I/O wait) değeri yüksek seyrediyor

Disk I/O ve Swap İlişkisi

Swap yavaş bir diskte bulunuyorsa performans etkisi çok daha ağır olur. NVMe SSD üzerindeki swap, SATA HDD’ye göre çok daha az acı verir. Swap disk performansını ölçmek için:

# Swap partition veya dosyanın bulunduğu diski bul
swapon --show

# O diskin I/O istatistiklerini izle
iostat -x 2 5

Çıktıda %util değeri sürekli %80-90 üzerindeyse, disk swap yükünü taşımakta zorlanıyor demektir.

Sonuç

Swap yönetimi, tek bir kural veya tek bir çözümle özetlenemeyen bir konudur. Genel web sunucusu, veritabanı sunucusu, uygulama sunucusu ve geliştirme ortamı için optimal swap konfigürasyonu birbirinden farklıdır.

Akılda tutmanız gereken temel prensipler şunlardır: Swap kullanımı miktarından çok aktif swap hareketi önemlidir, vmstat‘taki si/so değerleri sıfırsa swap dolu olsa bile paniklemek gerekmez. Veritabanı sunucularında swappiness değerini mutlaka 1-10 arasına çekin çünkü her milisaniye önemlidir. OOM Killer loglarını düzenli takip edin; bazen bir sorun saatler önce zaten kendini belli etmiştir. Swap bir emniyet ağıdır, performans özelliği değil. Swap kullanımı artıyorsa asıl çözüm RAM eklemek veya uygulamayı optimize etmektir.

Son olarak: en iyi swap yönetimi, proaktif izleme ve kapasite planlamasıdır. Alarm geldiğinde değil, alarm gelmeden önce harekete geçin.