Sunucuda swap memory ayarları: Performans etkisi ve doğru kurulum

Swap memory (swap alanı), sunucunun RAM’i yetmediğinde bellek sayfalarını diske taşıyan bir kurtarma mekanizmasıdır. Ancak swap’i “her zaman açık, hep aynı ayar” yaklaşımıyla ele almak performansı düşürebilir; özellikle I/O (girdi/çıktı) yükü artınca uygulama gecikmeleri belirginleşir. Bu rehberde Linux üzerinde swap’i nasıl ölçeceğinizi, hangi ayarları hangi senaryolarda değiştirmeniz gerektiğini ve hedef sayısal değerlerle performans etkisini nasıl yöneteceğinizi öğreneceksiniz.

Swap memory ne işe yarar, ne zaman sorun çıkarır?

Swap; RAM’in dolmasına yakınken kernelin kullanılmayan bellek sayfalarını disk üzerindeki swap alanına taşımasıdır. Ama swap alanına taşınan sayfalar geri çağrıldığında (page-in), disk erişimi devreye girer. Disk erişimi RAM’e göre ciddi derecede yavaştır.

Doğru kullanım: “kurtarma + kararlılık”

Swap, aşağıdaki durumlarda faydalıdır: - Ani bellek zirvelerinde uygulamanın OOM (Out Of Memory) ile çökmesini engellemek - Bellek sızıntısı (memory leak) gibi sorunlar tamamen çözülmeden önce süre kazanmak - Bazı arka plan işlerinde (örn. derleme, büyük raporlama) geçici zirveleri tolere etmek

Sorunlu kullanım: “I/O gecikmesi ve thrashing”

Swap sorun çıkarırken tipik belirtiler şunlardır: - CPU kullanımından çok disk/IO wait artması (iowait yükselmesi) - Uygulama yanıt süresinde (latency) artış - Sistem yükünün (load average) uzun süre yüksek kalması - Nginx/Apache veya uygulama süreçlerinin sık sık beklemesi

En kritik kavram thrashing’tir: Kernel, RAM’e geri alınan sayfaları tekrar tekrar swap’e atıp geri getirerek sistemi “verimli bellek çalışma” yerine “sürekli sayfa taşıma” moduna sokabilir.

Swap performansını belirleyen 3 değişken

Swap etkisini tek bir ayarla açıklamak doğru değildir. Pratikte üç etken birlikte sonucu belirler.

1) Disk tipi ve gecikme (SSD/NVMe vs HDD)

Swap’in performansı diskten gelir. NVMe SSD veya hızlı SSD üzerindeyse swap gecikmesi daha düşüktür. HDD üzerinde swap kullanmak ise genellikle daha yüksek iowait ve daha uzun yanıt sürelerine yol açar.

Net kontrol: - Diskin gerçek gecikmesini ve IOPS kapasitesini bilmeden “swap’i büyütmek” çoğu zaman çözüm değildir. - Aynı RAM yükünde NVMe ile HDD’nin davranışı dramatik biçimde ayrışır.

2) swappiness (vm.swappiness)

Kernelin swap’i ne kadar agresif kullandığını belirler. Daha yüksek değer daha agresif swap demektir. Linux’ta varsayılan değer birçok dağıtımda 60’tır.

Net yorum: - Düşük swappiness (ör. 10–20): Swap daha az kullanılır; RAM dolunca OOM riski artabilir. - Yüksek swappiness (ör. 80–100): Swap daha erken/devamlı devreye girer; ama disk I/O bekleme süresi artabilir.

3) Uygulama modeli (memory allocation paterni)

Bazı iş yükleri bellek açısından “düzgün” davranır; bazıları ise cache büyütür, sonra serbest bırakır, sonra tekrar büyütür. Swap’in performansa etkisi bu paternle doğrudan bağlantılıdır.

Özellikle: - Cache tutan sistemlerde gereksiz swap, performans düşüşü yaratır. - Tek seferlik büyük bellek kullanımlı işlerde swap, çöküşü engelleyebilir.

Mevcut swap durumunu ölç: kör ayar yapma

Swap performansını iyileştirmeye çalışmadan önce “şu anda swap kullanılıyor mu, ne kadar ve hangi hızda?” sorularını cevaplayın.

Swap kullanımını ve aktifliği kontrol et

Aşağıdaki komutlar swap’in mevcut durumunu görmenizi sağlar: - swapon --show - free -h - /proc/meminfo (özellikle SwapTotal, SwapFree)

Gerçek I/O stresini ölç

Swap ile ilişkili performans düşüşü çoğu zaman disk iowait ile görünür. Kısa kontrol seti: - iostat -x 1 10 - vmstat 1 10 - pidstat -d 1 10 (hangi süreç diski daha çok kullanıyor?)

Net hedef: iowait belirgin şekilde yükseliyor ve swap kullanımı aynı zaman diliminde artıyorsa, problem “swap’in varlığı” değil “swap’in tetiklenme seviyesi + disk hızı + iş yükü” üçlüsüdür.

Doğru swap büyüklüğü: “RAM’in kadar yap” yaklaşımı yerine senaryo

Swap boyutunu evrensel bir formülle tutturmak zor. En doğru yaklaşım iş yükü ve disk tipiyle birlikte düşünmektir.

Senaryo 1: Web uygulaması (WordPress, Laravel, Node.js) ve iyi cache yönetimi

• Amaç: OOM’u önlemek ama thrashing’e düşmemek.
• Disk NVMe ise: daha küçük swap bile yeterli kurtarma sağlayabilir.
• HDD ise: swap artışı çoğu zaman performans kaybını büyütür.

Net pratik hedef: - Genellikle RAM’in %0,25 ile %1,0 aralığı “kurtarma amaçlı” çoğu web iş yükünde başlangıç için makul olur. - Büyük swap’i “hız için” düşünmeyin; hız için RAM ve disk I/O kapasitesi kritiktir.

Senaryo 2: Derleme/işlem odaklı görevler (batch, raporlama, görsel işleme)

• Amaç: Zirvelerde çökmeden tamamlamak.
• Bu iş yüklerinde swap, geçici süre boyunca faydalı olabilir.

Net pratik hedef: - Swap’i sınırlı tutup, paralel iş sayısını azaltmak genellikle daha iyi sonuç verir. - Çünkü swap büyüdükçe thrashing olasılığı artar.

Senaryo 3: Container/VPS üzerinde çoklu süreçler

• Amaç: Bir süreç diğerlerini “swap fırtınasına” sokmasın.

Net pratik hedef: - Swap ayarını tek başına değil, cgroup limitleri (container memory limitleri) ile birlikte ele alın. - Eğer sistem birden fazla uygulamayı aynı hostta barındırıyorsa, swap agresifleştiğinde “etki tüm servisler”e yayılır.

swappiness ayarı: Hangi değer neyi değiştirir?

Linux’ta swap davranışını ayarlayan ana parametre vm.swappiness’tir.

Hızlı başlangıç önerisi

Net hedef: Web uygulaması ve genel servislerde thrashing riskini azaltmak. - Başlangıç için: vm.swappiness = 10 - Eğer OOM ile karşılaşıyorsanız: 10’dan 20 seviyesine yükseltin - Disk I/O bekleme çok yükseliyorsa: swappiness’i 10’a yaklaştırın ve swap kullanımını yeniden ölçün

Üretimde uygulanacak adımlar

1) Mevcut değeri öğrenin: - sysctl vm.swappiness

2) Geçici test (yeniden başlatma sonrası kalmaz): - sudo sysctl vm.swappiness=10

3) Kalıcı ayar (örnek): - /etc/sysctl.conf içine vm.swappiness=10 satırını ekleyin veya dağıtıma göre /etc/sysctl.d/*.conf dosyası kullanın. - Ardından: sudo sysctl -p

Ölçüm kriteri (değerlendirme tablosu)

Ayar yaptıktan sonra en az 10-15 dakika boyunca şu metrikleri izleyin: - vmstat ile si/so (swap giriş/çıkış) - iostat ile %iowait - Uygulama tarafında: hata oranı ve ortalama/p95 yanıt süresi

Basit karar kılavuzu: | Gözlem | Olası yorum | Uygulanacak net aksiyon | |---|---|---| | si/so sürekli yüksek, iowait yüksek | Thrashing eğilimi | swappiness’i düşür + gerekiyorsa swap boyutunu büyütme, daha çok RAM/limit optimizasyonu düşün | | iowait normal ama OOM oluyor | RAM yetersiz | swappiness’i 10’dan 20’ye çıkar veya swap/limit planını gözden geçir | | si/so düşük ama p95 latency artıyor | Swap tek sebep değil | disk/network/cache/metriklerini yeniden hedefle |

Swap’i kapatmalı mı? “Tam kapatma” ne zaman doğru olur?

Swap’i tamamen kapatmak bazı sistemlerde mümkün olsa da net bir kural yoktur. Yanlış zamanda kapatma; ani bellek zirvelerinde OOM ile süreçlerin düşmesine neden olur.

Net değerlendirme: - Uygulama bellek paternini iyi biliyorsanız ve container memory limitleri güçlü şekilde yönetiliyorsa swap daha az kritik olabilir. - Ama gerçek trafik dalgalanması olan servislerde “swap kapalı, her şey RAM’e sığacak” varsayımı risklidir.

Pratik öneri: - Web servislerinde swap’i tamamen kapatmak yerine swappiness’i düşük tutmak genellikle daha kontrollü bir yaklaşım verir.

Swap ile performans düşüşünü düzeltmek için öncelik sırası

Swap ayarını tek hamlede “mükemmel” yapmaya çalışmak genellikle zor. Daha sağlıklı sırayla ilerleyin.

1) Önce uygulama tarafını kontrol et

• Cache boyutları: gereksiz büyüyen cache, swap tetikleyebilir.
• Connection pool: aşırı eş zamanlı istek bellek kullanımını şişirir.
• Leak kontrolü: düzenli artan bellek, swap’i sürekli devreye sokar.

2) Sonra sistem kaynak limitlerini netleştir

• VPS/VDS’te bellek limitiniz varsa (ör. plan veya cgroup), uygulamayı o limite göre ayarlayın.
• Çoklu süreçlerde her prosesin bellek tüketimini ölçün.

3) Disk I/O’yu hedefle

• Swap HDD üzerindeyse, asıl çözüm genellikle disk türünü iyileştirmektir.
• Swap alanını farklı disk/volume’a almak da bazen fayda sağlar; ama en kritik şey I/O gecikmesidir.

4) En son swappiness ve swap boyutunu ince ayarla

• İlk turda hedef: thrashing’i azaltmak.
• İkinci turda: OOM riskini kontrol altına almak.

Pratik kontrol listesi: kararınızı veriyle verin

Aşağıdaki listeyi bir “değerlendirme formu” gibi kullanın. - Swap kullanımı free -h çıktısında düzenli mi, yoksa nadiren mi artıyor? - vmstat’ta si/so sürekli mi, yoksa kısa zirveler mi? - iostat’ta %iowait belirgin şekilde yükseliyor mu? - p95/p99 yanıt süresi swap artışı ile aynı zaman diliminde mi? - Disk tipi NVMe mi SSD mi HDD mi?

Bu soruların çoğu “evet” diyorsa, swap’i büyütmek yerine swappiness’i düşürmek ve disk/iş yükü uyumunu düzeltmek daha hızlı sonuç verir.

Sonuç: swap ayarını tek sayıya indirgeme, hedef metrikle yönet

Swap memory, doğru kurulduğunda çöküşleri önleyen bir emniyet kemeri; yanlış kurulduğunda ise disk I/O beklemesiyle performansı düşüren bir tetikleyici olur. İlk aksiyon olarak mevcut swap kullanımını (si/so), disk kaynak stresini (iowait) ve uygulama gecikmesini birlikte ölçün. Ardından web/servis iş yüklerinde vm.swappiness’i 10 seviyesine çekerek thrashing riskini azaltın; OOM görürseniz 20 seviyesine kademeli çıkarın. Eğer disk gecikmesi yüksekse, çözüm önceliğini disk türü ve kaynak planlamasına verin. Son olarak yaptığınız her değişikliği en az 10-15 dakika izleyip aynı metrik setiyle doğrulayın—bu yaklaşım kararınızı netleştirir ve performans kaybını kalıcı olarak engeller.