Sunucuda Swap Memory Ayarları: Performans Etkisi ve Doğru Kurulum

Sunucuda swap memory (takas) ayarları, “RAM yetmiyor” durumlarında sistemi ayakta tutar; ancak yanlış yapılandırma disk I/O’yu yükselterek performansı düşürür. Bu rehberde Linux tabanlı sunucularda swap’in ne zaman devreye girdiğini, swappiness ve priority gibi parametrelerin gecikmeye etkisini ve pratikte nasıl doğru kurulum yapılacağını net biçimde anlatıyorum. Ayrıca swap performansını ölçmek için kullanacağınız komutları ve hedef değerleri adım adım vereceğim.

Swap ne zaman performansı artırır, ne zaman düşürür?

Swap, RAM dolduğunda sayfaların (memory pages) disk üzerinde ayrılan alana taşınmasıdır. Disk yerine RAM kullanıldığı için swap’in devreye girmesi gecikmeyi artırır. Fakat doğru tasarımda swap; uygulamayı anlık çökertmek yerine geçici yükte “kilitlenmeyi” engelleyebilir.

Aşağıdaki iki senaryo kritik ayrımı gösterir:

• Kısa süreli ve seyrek swap kullanımı: RAM baskısı geçicidir. Swap devreye girer ama sistem “ısınma” (thrashing) seviyesine gelmez. Toparlanma hızlı olur.
• Sürekli swap kullanımı (thrashing): Swap devreye giriyor ve RAM sayfaları sürekli diskle yer değiştiriyor. Bu durumda disk I/O şişer, uygulama yanıt süreleri artar ve CPU “bekleme” durumlarına düşer.

Thrashing’i şu şekilde anlarsınız: Sürekli yüksek disk kullanımına ek olarak si/so (swap in/out) değerleri artar ve istek gecikmeleri büyür.

Thrashing sinyali: tek komutla kontrol

Sunucuda anlık durum kontrolü için şu komutu kullanın:

• vmstat 1

Ekranda swap satırında si (swap in) ve so (swap out) değerleri sürekli yüksekse thrashing olasılığı artar. Swap’in var olması tek başına sorun değildir; sürekli aktif olması sorundur.

Swap alanı nasıl hesaplanmalı? Dosya mı partition mı?

Swap alanı iki ana yöntemle sağlanır:

• Partition (ayrılmış disk alanı): Kurulum sırasında veya sonradan eklenir. Sabit bir bölümdür.
• Swap file (dosya): Günümüzde pratikliği nedeniyle sık kullanılır. Sonradan eklemek ve boyutu değiştirmek kolaylaşır.

Net kural: disk türü belirleyicidir

Swap performansı doğrudan disk gecikmesine bağlıdır.

• VDS üzerinde SSD/NVMe varsa swap, “geçici kurtarıcı” olarak daha güvenilirdir.
• Sadece HDD veya yüksek gecikmeli storage varsa swap, performans düşüşünü daha dramatik yaşatır.

Boyut: 2 hedefle netleştirin

Swap boyutunu tek bir sayı gibi düşünmek yerine iki hedefe bağlayın:

1. OOM (Out Of Memory) riskini azaltmak: Kritik süreçlerin ani ölmesini engellemek.
2. Thrashing’i tetiklemeyecek sınırda kalmak: RAM baskısı kalıcıysa swap “çözüm” değil “ertelemektir”.

Genel pratikte şu yaklaşım işe yarar (tamamen tek hedefe kilitlenmeden):

• RAM 4–8 GB aralığında sistemler için swap’in en az 4 GB tutulması, hızlı kurtarma için yaygındır.
• RAM 8–16 GB aralığında 6–12 GB bandı çoğu senaryoda dengelidir.
• RAM 16 GB ve üstünde ise swap’i büyütmek yerine uygulama limitlerini, worker sayısını ve cache stratejisini düzeltmek daha doğru olur; yine de kriz senaryosu için “makul” bir swap bırakılır.

Not: Bulut VDS/VPS’lerde kontrol paneli limitleri ve disk kotası önemlidir. Swap dosyası eklerken diskin dolmasına izin vermeyen bir tasarım yapın.

Linux swap önceliği: swappiness (ve performansın kökü)

Linux’ta swap’in ne kadar agresif kullanıldığını belirleyen ana parametre swappiness’tir.

• Düşük swappiness: Swap daha geç devreye girer.
• Yüksek swappiness: Swap daha erken ve daha sık kullanılır.

swappiness'i net şekilde kontrol edin

Mevcut değeri öğrenmek için:

• cat /proc/sys/vm/swappiness

swappiness değerini örnekleyelim (net öneri)

Birçok üretim sisteminde agresif swap kullanımını azaltmak için swappiness değeri şu çizgide tutulur:

• vm.swappiness=10 (daha az agresif)
• vm.swappiness=1 (çok muhafazakar)

Ne zaman hangi değer?

• Web uygulaması (PHP-FPM, Node, Java) ve RAM’in çoğu cache/dokümanla doluyorsa: 10 daha dengeli bir başlangıçtır.
• Disk gecikmesi yüksekse ve swap thrashing riski varsa: 1 daha güvenlidir.

Değeri kalıcı yapma

Kalıcı ayar için örnek:

• Dosya: /etc/sysctl.d/99-swappiness.conf
• İçerik: vm.swappiness=10
• Sonra: sysctl --system

Burada “tek seferlik ayar” yerine izleme ile doğrulama şart. swappiness’i düşürmek, swap’i azaltır; fakat RAM gerçekten yetersizse OOM riskini de artırır.

Swap sıklığı ile uygulama performansı arasındaki bağlantı

Swap devreye girdiğinde şu zincir oluşur:

1. RAM’den sayfalar disk üzerinde swap alanına yazılır.
2. Daha sonra o sayfaya ihtiyaç duyulunca tekrar RAM’e alınır.
3. Bu yazma/okuma disk I/O’su doğurur.
4. Uygulama iş parçaları (threads/workers) disk I/O bekler.
5. Sonuç: yanıt süreleri ve kuyruklar artar.

Bu nedenle swap “performans düşürücü” değil, duruma göre gecikme artıran bir mekanizmadır. Kritik nokta: Swap’in kalıcı hale gelmesini engellemektir.

Pratik ölçüm: swap kullanımını saniye saniye görün

Aşağıdaki komutlar performansla eşzamanlı yorum yapmanıza yardımcı olur:

• free -h
• Swap: satırında kullanımı görürsünüz.
• vmstat 1
• si/so ile swap hızını izlersiniz.
• iostat -x 1
• swap dosyası disk üzerindeyse disk tarafındaki await ve svctm gibi metrikler gecikmeyi açıklar.

Dosya tabanlı swap kurulumunda dikkat edilmesi gerekenler

Swap dosyası kullanıyorsanız (çoğu VDS’te olduğu gibi) performans ve güvenlik için şu noktalar önemlidir:

1) Dosya konumu ve parçalanma (fragmentation)

Swap dosyası oluştururken dosyanın parçalanmaması gerekir. Dosya bazlı swap’te performans farkı bu yüzden oluşabilir.

2) Doğru izinler

Swap dosyası için izinler kuralına uyulmalıdır (sistemin kullanıcı erişimini kısıtlar). Linux tarafında standart süreç genellikle güvenli olur; ancak manuel adımlarda doğru izinleri kullandığınızdan emin olun.

3) Boyutu ve aktivasyonu doğrulayın

Kurulum sonrası mutlaka şu kontrolleri yapın:

• Swap aktif mi?
• swapon --show
• Swap dosyası gerçekten doğru boyutta mı?
• free -h

Swap dosya/partition tercihi: hangi durumda hangisi?

Aşağıdaki karar matrisi net bir seçim sağlar.

Net sonuç: Çoğu VDS kullanımında swap dosyası pratik bir standarttır; ancak disk performansının düşük olduğu sistemlerde swap’in daha “kontrollü” olması için partition da tercih edilebilir.

Swap kapatma mı azaltma mı? Karar ağacı

Swap’i tamamen kapatmak (disable) bazı sistemlerde işe yarar; çünkü disk gecikmesi kaynaklı performans sorununu ortadan kaldırır. Fakat RAM yetersizse OOM ile süreçlerin ölmesi riski artar.

Aşağıdaki karar ağacıyle net ilerleyin:

• Uygulama yükü RAM’i sürekli tüketiyor ve swap kullanımı dakikalar boyunca devam ediyorsa:
• Öncelik: RAM artırma veya işçi sayısı/queue/pool azaltma.
• Swap’i kapatmak yerine thrashing’i bitirecek yönde ayarlayın.
• Uygulama yükü geçici pik yapıyor ve swap sadece kısa süreli çalışıyorsa:
• Swap’i kapatmak yerine swappiness’i düşürün (ör. 10), boyutu koruyun.
• Disk gecikmesi yüksek ve swap devreye girince yanıt süreleri belirgin artıyorsa:
• Swap’i daha muhafazakar kullanın (swappiness=1 gibi) ve kalıcı RAM planı yapın.

Üretimde en doğru yaklaşım: swap’i “kriz freni” yapın

Swap ayarlarını tek başına “performansı artırır/azaltır” gibi düşünmek yanıltır. En doğru hedef şudur:

• Sistem OOM olmasın (dayanıklılık)
• Disk I/O ile yanıt süreleri bozulmasın (performans)
• Thrashing oluşmasın (stabilite)

Bu hedeflere ulaşmak için en net iş sırası şöyledir:

30 dakikalık Net Aksiyon Planı

1. Mevcut swap ve kullanım durumunu görün: - free -h - vmstat 1 (en az 3-5 dakika)
2. Thrashing var mı karar verin: - si/so değerleri sürekli yüksek mi?
3. swappiness değerini kontrol edin ve hedefe çekin: - cat /proc/sys/vm/swappiness - Başlangıç için vm.swappiness=10
4. Uygulama tarafında paralellik/worker ayarlarını gözden geçirin: - PHP-FPM worker sayısı, Node cluster/worker, Java thread pool gibi
5. Değişiklik sonrası tekrar ölçün: - Yanıt süresi (uygulama loglarından veya APM varsa) + vmstat + iostat

Sonuç: Swap ayarını rakama indir, izlemeyle doğrula

Swap memory ayarlarının performansa etkisi disk I/O gecikmesi üzerinden belirlenir; bu yüzden amaç swap’i “sık kullandırmak” değil, kriz anında devreye alıp thrashing’i önlemek olmalıdır. Bir sonraki adım olarak önce vmstat 1 ile swap aktivitesini ölçün, sonra swappiness değerini 10 bandında başlatıp değişim sonrası tekrar kıyaslayın. Swap devri kalıcıysa tek çözüm ayar değildir: RAM planı ve uygulama worker/queue limitleriyle birlikte ele almanız gerekir.