Sunucuda Swap Memory: Doğru ayarlarla performansı koruyun

Swap (takasa) memory, RAM dolduğunda verileri geçici olarak diske taşımak için kullanılan bir mekanizmadır. Yanlış swap ayarları ise “çalışıyor ama yavaş” durumuna, hatta bazı iş yüklerinde uygulama zaman aşımlarına yol açar. Bu rehberde Linux tabanlı VDS/VPS/dedicated sunucularda swap’in ne zaman gerekli olduğunu, doğru boyutu nasıl belirleyeceğinizi ve swappiness/I/O etkisini nasıl ölçüp ayarlayacağınızı adım adım anlatıyorum. Hedef: Sisteminizin çökmesini önlerken gereksiz swap kullanımını azaltmak ve performans regülasyonunu (tutarlı hız) sağlamak.

Swap memory neyi çözer, neyi bozar?

Swap, çekirdek (kernel) RAM yetersiz kaldığında kullanılmayan bellek sayfalarını diske yazar. Bu sayede out-of-memory (OOM) olaylarının sayısı azalır ve servisler bir süre daha yaşamaya devam eder. Ancak swap dosyası/partition diske yazma- okuma yaptığından şu bedelleri getirir:

• Disk I/O yükselir: Özellikle SSD/NVMe değilse veya aynı disk üzerinde yoğun log/DB yazımı varsa gecikme artar.
• CPU zamanlaması etkilenir: Sayfaların taşınması/geri çağrılması CPU ve kernel iş yükü oluşturur.
• Uygulama latansı artar: Swap’e giden iş yükü “hızlı RAM” yerine “daha yavaş depolama” bekler.

Bu nedenle swap’i “performans için” değil, istikrar sigortası olarak düşünmek gerekir. Performans hedefi; swap kullanımını minimumda tutmak ve RAM baskısını kalıcı çözümlerle azaltmaktır.

Swap ne zaman faydalıdır?

• RAM kısa süreli dalgalanıyorsa (ör. yük pikleri, derleme işleri)
• Uygulama kaynak tüketimi ölçülebilir şekilde dalgalanıyorsa
• RAM’i hemen artırmak yerine geçici bir koruma katmanı istiyorsanız

Swap ne zaman sorundur?

• Sunucu sürekli swap kullanıyorsa (saatlerce)
• Disk/RAID katmanı zaten yoğun I/O altındaysa
• Uygulama memory leak yapıyorsa (swap sadece semptomu yavaşlatır)

Swap ayarlarını belirlemenin doğru yolu: ölçüm + hedef

Swap boyutu tek başına “% şu kadar yap” diye sabitlenemez. En doğru yaklaşım, önce mevcut durumu ölçmek ve hedef davranışı tanımlamaktır.

Ölçüm metrikleri (anlık ve kalıcı)

Aşağıdaki metrikler swap’in sadece “var mı” değil “ne kadar ve ne zaman” kullanıldığını gösterir:

• Mevcut swap kullanımı: free -m (Swap total/used)
• Swap activity: vmstat 1 (si/so değerleri)
• IO ve gecikme: iostat -x 1 (await, svctm)
• Sistem genel memory baskısı: /proc/meminfo (MemAvailable, Slab)

Örnek hedef: - Swap’in pik anlarında birkaç dakika kullanılması kabul edilebilir. - Swap’in kalıcı ve sürekli kullanımı (ör. %30-60 üzerinde saatlerce) performans ve ölçek için risk işaretidir.

Swappiness (vm.swappiness) neyi etkiler?

vm.swappiness çekirdeğin swap’e ne kadar agresif gittiğini belirler. Mantık: değer yükseldikçe çekirdek daha erken swap’e yönelir. Tipik aralıklar: - Düşük değerler: 0-10 civarı, swap’e daha geç girer. - Orta değerler: 10-60, genel kullanım. - Yüksek değerler: 60+, daha agresif swap.

Net pratik: - Swap sürekli kullanılıyorsa swappiness’ı düşürmek genellikle daha az swap’e girmenizi sağlar. - Ama çok düşürmek OOM riskini artırabilir. Bu yüzden hedefe bağlı deneme gerekir.

Swap boyutu nasıl hesaplanır? RAM’e göre net senaryolar

Swap boyutu seçimi, disk performansı ve RAM kapasitesiyle doğrudan bağlantılıdır. Aşağıdaki yaklaşım, çoğu VDS/VPS senaryosunda gerçekçi bir başlangıç noktası sunar.

Senaryo 1: RAM 4-8 GB (genel web servisleri, hafif DB)

• Hedef: OOM’u önlemek, uzun süre swap’e düşmemek.
• Başlangıç önerisi: Swap boyutunu RAM’in yaklaşık 1x’i seviyesinde tutmayı düşünün.
• Örneğin 6 GB RAM için ~6 GB swap ile başlayabilirsiniz.

Senaryo 2: RAM 8-16 GB (WordPress + cache, orta trafik)

• Hedef: Dalgalanmalarda stabilite.
• Başlangıç önerisi: RAM’in 0.5x - 1x aralığı.
• 12 GB RAM için ~6-12 GB aralığı mantıklıdır.

Senaryo 3: RAM 16 GB+ (yüksek trafik, DB ağırlığı)

• Hedef: Swap’i “kurtarma halatı” gibi kullanmak.
• Başlangıç önerisi: RAM’in 0.25x - 0.5x aralığı.
• 32 GB RAM için ~8-16 GB swap çoğu iş yükünde yeterlidir.

Disk tipi şartı: swap aynı diskte mi, farklı mı?

Disk performansı swap’i dramatik biçimde etkiler. Swap için şu kontrol listesini uygulayın: - Swap’i kullandığınız cihaz NVMe SSD ise gecikme genellikle daha düşüktür. - Aynı disk üzerinde veritabanı (MySQL/PostgreSQL) ve swap varsa gecikme yarışına girersiniz. - Aynı mantıksal birim (volume) üzerinde yoğun write amplification varsa (ör. loglar) swap etkisi artar.

Net kural: - Eğer DB + swap aynı diskte yüksek I/O üretiyorsa, swap agresif boyutlandırmak yerine RAM artırma veya iş yükü ayrıştırma (DB ayrı volume) daha doğru olur.

Swap’i dosya olarak mı partition olarak mı? Pratik seçim

Linux’ta swap oluşturmanın iki yaygın yolu vardır: - Swap partition - Swap file (dosya)

Swap dosyası (swap file) ne zaman daha mantıklı?

• Cloud/VPS sistemlerinde disk bölümlendirme her zaman esnek değildir.
• Swap’i ölçeklemek/geri almak daha kolaydır.
• Otomasyon senaryoları (IaC) için daha pratik olur.

Swap partition ne zaman avantajlı?

• Performans açısından bazen daha deterministik olabilir.
• Ancak modern sistemlerde swap dosyası doğru ayarla genellikle yeterli performans verir.

Net tercih önerisi: - VDS/VPS’te çoğu kullanıcı için swap file daha pratik ve yeterlidir.

Swappiness ve kernel davranışı: performans için doğru ayar seti

Swap’in agresifliğini ayarlamak için en etkili parametre vm.swappiness’tır. Bunun yanında OOM davranışları ve kernel reclaim mantığı da devreye girer.

Başlangıç ayar önerileri (ölçüme göre)

Aşağıdaki ayar setini “başlangıç noktası” olarak düşünün: - Sürekli swap kullanımı (saatlerce) varsa: vm.swappiness = 10 veya vm.swappiness = 5 - Dalgalanma ama OOM yoksa: vm.swappiness = 30 - 40 - Yeni kurulum / belirsizlik varsa: varsayılan civarında kalın, sonra metrikle düzeltin.

Ayarı görme ve değiştirme

Mevcut swappiness: - cat /proc/sys/vm/swappiness

Kalıcı ayar için (örnek):

# /etc/sysctl.d/99-swap.conf dosyası oluşturun
vm.swappiness=10

# değişikliği uygula
sudo sysctl --system

Not: Bu değer sadece swap kullanımını değil, RAM reclaimed (geri kazanım) davranışlarını da etkiler. Bu yüzden 24 saat izleme yapın.

Swap performansını nasıl doğrularsınız? “Doğru çalışıyor” nasıl anlaşılır?

Ayar yaptığınızda hedef şu olmalı: 1) OOM olmadan servislerin çalışması 2) Swap kullanımının sadece gerekli anlarda oluşması 3) I/O gecikmelerinin kabul edilebilir seviyede kalması

Kontrol listesi (somut eşikler)

Aşağıdaki kontrolleri “tek tek” uygulayın:

1. Swap kullanımı - free -m ile swap used değerini izleyin. - Swap uzun süre %20+ bandında kalıyorsa (RAM kapasitenize göre) performans riski büyüktür.

2. Swap giriş/çıkışı - vmstat 1’de si/so sürekli pozitifse sistem swap’e gerçek yük taşıyor demektir.

3. Disk I/O gecikmesi - iostat -x 1 ile await değerini takip edin. - Disk gecikmesi yükselirken web/API latansı artıyorsa swap etkisi güçlenmiş demektir.

4. Uygulama katmanı - WordPress/PHP-FPM, Node, Java gibi servislerde response time ve error oranını izleyin. - Swap sonrası artan 504/timeout varsa öncelik swap değil, bellek profili olmalıdır.

Yaygın hatalar ve net düzeltmeler

Hata 1: Swap’i “RAM kadar” yapıp sürekli swap kullanmaya devam etmek

• Bu yaklaşım OOM’u geciktirebilir ama performansı öldürür.
• Düzeltme: Önce “neden swap’e düşüyor” sorusunu yanıtlayın (cache ayarları, uygulama memory limitleri, DB buffer, süreç sayısı).

Hata 2: Swappiness’i çok düşürmek (OOM artar)

• Düzeltme: vm.swappiness’i 10’dan başlayıp, swap kullanımı ve OOM olaylarını birlikte izleyin.

Hata 3: Swap ve logları aynı diskte yoğunlaştırmak

• Düzeltme: Log rotasyonu (ör. logrotate), gereksiz write’ları azaltma, mümkünse ayrı volume.

Hata 4: Ölçüm yapmadan ayar değiştirmek

• Düzeltme: free -m, vmstat 1, iostat -x 1 ile en az birkaç saat gözlem yapın.

Swap ayarlarını özetleyen net karar tablosu

Aşağıdaki tablo, ölçüme göre hangi aksiyonun daha doğru olacağını hızlıca görmenizi sağlar.

Sonuç: Swap’i ayarlayın, ama optimizasyonu merkeze alın

Swap memory, doğru kullanıldığında sistem stabilitesini artıran bir güvenlik katmanıdır; yanlış kullanıldığında ise performansı kalıcı biçimde bozar. Bugün yapmanız gereken net aksiyon planı şudur: Önce free, vmstat ve iostat ile mevcut swap davranışını ölçün; sonra metriklere göre vm.swappiness değerini 5-10 aralığı gibi kontrollü şekilde ayarlayın; swap’in saatlerce açık kalması durumunda boyutu artırmak yerine uygulama/DB bellek tüketimini azaltmaya ve gerekirse RAM/volume düzenine odaklanın. Bu yaklaşım, hem OOM riskini düşürür hem de sunucunuzun gerçek performansını korur.