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

Swap (takas) memory, RAM dolduğunda işletim sisteminin bir kısmını diske sayfalayarak “OOM (Out of Memory)” riskini azaltan kritik bir bileşendir. Ancak swap’ın miktarı ve kullanım biçimi, özellikle VDS/VPS gibi paylaşımlı veya sınırlı I/O performansına sahip sunucularda ciddi performans farkı yaratır. Bu rehberde; Linux’ta swap ihtiyacını nasıl ölçtüğünüzü, en sık yapılan hataları ve performansı koruyacak somut ayar yaklaşımını adım adım öğreneceksiniz.

Amaç: RAM’i doğru kapasitede kullanırken swap’ı “kurtarıcı” rolünde tutmak; disk/IO darboğazına dönüşmesini engellemek.

Swap ne zaman kullanılır? Performansın kırıldığı nokta

Swap, Linux’un bellekteki sayfaları diske yazmasıyla devreye girer. Bu süreç, RAM’e kıyasla birkaç büyüklük farkında daha yavaş bir I/O yoluna dayanır. Bu yüzden swap aktifken genellikle şu belirtiler görülür:

• Sunucu yanıt sürelerinde dalgalanma (özellikle web istekleri)
• Uygulama gecikmesi (database / cache / background worker)
• Disk I/O kullanımında artış ve kuyruk (queue) büyümesi
• CPU’nun “bekleme” yerine I/O kaynaklı darboğaza düşmesi

Burada kritik ayrım şu: Swap “yedek” olduğu için değil, swap aşırıya kaçtığında performans düşer. Aynı anda çok sayıda sayfalanma (page-in/page-out) oluyorsa sistem “thrashing” durumuna girer.

Thrashing (aşırı sayfalama) nasıl anlaşılır?

Aşağıdaki metrikler, swap kullanımının “kontrollü” değil “sorunlu” olduğunu gösterir.

• si/so (swap in/out) değerleri yüksek ve sürekli
• vmstat çıktısında swap kolonu düzenli şekilde büyür
• iostat ile disk aktifliği (util) yüksekken yanıt süreleri artar
• Uygulama loglarında time-out, queue birikimi

Mevcut swap durumunu ölçme: Tahmin yerine veri

Doğru ayarı yapmanın ilk adımı, mevcut durumun doğru teşhisidir. Aşağıdaki komutlar swap’ın miktarını değil, kullanım davranışını görmenizi sağlar.

Swap boyutu ve kullanımı

• Swap toplamı ve kullanım:
• free -h

Burada iki satır önemlidir: - Swap: Toplam swap - Used: Şu an diske yazılmış sayfa miktarı

Swap “var” ama kullanımı sıfıra yakınsa, çoğu zaman sadece koruma rolündedir.

Page-out / page-in davranışı (thrashing sinyali)

• 2 saniyede bir ölçüm (özet gözlem):
• vmstat 2

Aranan alanlar: - si (swap in): Diskten RAM’e okunan sayfalar - so (swap out): RAM’den diske yazılan sayfalar

si/so sürekli yüksekse sistem swap’ı aktif olarak “çalışma yüzeyi” gibi kullanıyordur.

Disk I/O darboğazı var mı?

Swap’in performans etkisi çoğunlukla diskin IOPS/latency kapasitesinden gelir. Bu yüzden I/O’yu kontrol edin:

• CPU değil disk darboğazı mı?
• iostat -x 2

Önemli göstergeler: - await: Ortalama bekleme süresi - svctm: Servis zamanı (varsa) - util: Disk kullanım yüzdesi

Swap için doğru yaklaşım: “Miktarı büyütmek” çözüm değildir

Swap’ı otomatik büyütmek, RAM yetersizliğini disk üzerinden telafi etmeye çalışmak demektir. Bu; web uygulamalarında gecikme yaratır, veritabanı üzerinde bekleme sürelerini uzatır ve bazen log/queue birikimiyle daha da kötüleşir.

Swap ayarlarında hedef şudur: - RAM kapasitesi yeterli değilse bile sistemi “kurtaracak kadar swap” sunmak - Ama diske sürekli sayfalama yaptırmayacak sınırları korumak

Linux’ta swappiness (vm.swappiness) ne işe yarar?

vm.swappiness değeri, Linux’un swap’i ne kadar agresif kullanacağını belirler. Mantık basittir: - Değer yükseldikçe swap’e daha erken yönelebilir - Değer düşerse RAM’de tutmaya çalışır, swap daha geç devreye girer

Yanlış swappiness, “swap var ama sistem onu kullanıyor” gibi bir duruma yol açabilir.

Aşağıdaki komutla geçerli değeri görebilirsiniz: - sysctl vm.swappiness

Güncel dosya üzerinden kontrol: - /etc/sysctl.conf veya /etc/sysctl.d/*.conf

Somut ayar önerileri: Ne kadar swap? Hangi senaryoda?

Tek bir “her sunucu için doğru swap” yoktur; ancak işletimsel olarak uygulanabilir bir karar matrisi vardır. Aşağıdaki tablo, VDS/VPS üzerinde yaygın senaryolar için pratik bir başlangıç noktası sağlar.

Not: Değerleri üretime almadan önce staging veya düşük trafikli saatlerde test edin.

Swap miktarını “otomatik büyütme” yerine RAM kapasitesini düzeltin

Eğer swap sürekli kullanılıyorsa, genellikle kök neden şunlardan biridir: - Uygulama yanlış bellek boyutu ayarları (heap limit, buffer boyutu) - Database cache ve bağlantı sayısı (max connections) - Container/worker sayısı fazla - Yetersiz RAM (gerçek yükü kaldırmıyor)

Bu durumda yapılacak doğru aksiyon: 1) Önce uygulama ve database bellek ayarlarını düzeltin 2) Worker sayısını ve concurrency’i gerçek ihtiyaca çekin 3) Gerekirse RAM yükseltin 4) Swap’i sadece OOM güvenlik yastığı olarak tutun

Linux swap yapılandırma adımları (tetkik ve kalıcı uygulama)

Aşağıdaki adımlar, swap davranışını kontrol etmek için kullanılan tipik iş akışıdır.

1) Swap var mı? Dosya mı bölüm (partition) mi?

Swap dosyası (swapfile) kullanıyorsanız, genelde daha esnek olur. Mevcut swap’ların listesi: - swapon --show

Çıktıda dosya/partition ve boyut görürsünüz.

2) Kalıcı ayarı doğrulayın

Kalıcılık için sistem yeniden başlatıldıktan sonra swap durumunu kontrol edin: - free -h - swapon --show

Ayrıca /etc/fstab üzerinden swap’ın kalıcı tanımı bulunabilir.

3) swappiness ayarını kalıcı yapma

Geçerli değeri gördükten sonra kalıcı değişiklik için sysctl.d yaklaşımı tercih edilir.

Örnek (dosya yaklaşımı):

/etc/sysctl.d/99-swap.conf

İçerik örneği:

vm.swappiness=10

Ardından: - sysctl --system

Burada hedef agresif swap kullanımını azaltmaktır. Ancak değer düşürmek, bazı uç durumlarda memory basıncını RAM üzerinde daha belirgin hale getirebilir. Bu yüzden önce ölçüm yapın.

4) cgroup/container ortamında swap politikası

Container kullanan sistemlerde swap davranışı, cgroup ayarlarına göre farklılaşabilir. Eğer Docker/Kubernetes kullanıyorsanız swap’i sadece host seviyesinde ayarlamak her zaman aynı sonucu üretmez.

Bu tip yapılarda şu kontrolleri yapın: - container limitleri (memory limit) - swap enable politikaları - OOM kill logları

Performansı korumak için “swap ile birlikte” bakılacak 5 metrik

Swap tek başına sorunu açıklamaz. Performans düşüşünün swap kaynaklı mı yoksa başka bir darboğaz mı olduğunu netleştirmek için aşağıdaki metrikleri birlikte değerlendirin.

1. Disk latency: await (iostat)
2. Swap aktifliği: si/so (vmstat)
3. Memory basıncı: free -h + swap used
4. CPU steal (steal time): sanal ortamda performans paylaşımları (varsa)
5. Uygulama gecikmesi: web/queue iş süreleri

Pratik yorum kılavuzu

• Disk latency yüksek + swap kullanımı yüksek + istek gecikmesi artıyorsa: swap thrashing olasılığı çok yüksektir.
• Swap kullanımı var ama disk latency düşük ve istek gecikmesi sabitse: swap daha çok koruma rolündedir.
• Disk latency düşük, swap kullanımı yüksek ama istek gecikmesi sınırlıysa: kök neden farklı olabilir (ör. CPU bound, lock/IO wait dışı).

Sık yapılan hatalar ve doğru düzeltme sırası

Aşağıdaki hatalar, swap ayarlarında en sık görülen performans sorunlarıdır.

Hata 1: Swap’ı sınırsız büyütmek

Sonuç: Disk I/O kuyruğu artar, gecikme yükselir.

Doğru sıra: - Önce uygulama bellek ayarlarını ve concurrency’i düzelt - Sonra gerekirse RAM artır - Swap’i “OOM emniyeti” olarak tut

Hata 2: swappiness’i tek hamlede aşırı düşürmek

Sonuç: Sistem RAM’de daha agresif sıkışabilir; bazı yüklerde OOM riski artabilir.

Doğru sıra: - vmstat ve iostat ile kademeli ölçüm - OOM logları ve uygulama error rate’i kontrol - Değeri test ederek optimize et

Hata 3: Disk türünü göz ardı etmek

SSD yerine yavaş disklerde swap daha pahalıdır. VDS/VPS’te sağlayıcıdan gelen disk performansı (IOPS/throughput) swap’in etkisini doğrudan belirler.

Doğru sıra: - Sağlayıcının depolama tipini ve IOPS limitlerini gözden geçirin - swap kullanımında iostat ile doğrulayın

Test planı: Ayarı değiştirdikten sonra nasıl doğrularsınız?

Swap ayarlarını değiştirdikten sonra “tek ölçüm” yeterli değildir. En az 30-60 dakikalık gözlem yapın (mümkünse trafik piki içeren zaman aralığı).

Test sırasında izlemeniz gerekenler

• vmstat 2 ile si/so davranışı
• iostat -x 2 ile await ve util
• free -h ile swap used değişimi
• Uygulama metrikleri: response time, error rate

Kabul kriteri örnekleri

• Swap used kısa süreli yükselip sonra hızlı düşüyorsa: iyileşme işareti
• await ve util sürekli yükseliyorsa: swap diski boğuyor
• OOM kill yok, ama yine de gecikme artıyorsa: farklı darboğaz arayın

NetKıyas bakış açısıyla karar: Swap ayarı hangi seçeneklerle birlikte ele alınmalı?

Swap, sunucu mimarisinden bağımsız değildir. Aynı VDS planında: - Daha yüksek RAM, swap kullanma ihtiyacını azaltır - Daha iyi depolama (IOPS/latency), swap’in performans etkisini düşürür - CPU/worker kapasitesi, bellek basıncını dolaylı olarak etkiler

Bu nedenle swap ayarı tek başına “çözüm planı” değildir. Uygulama profiline göre RAM ve disk performansı birlikte optimize edilmelidir.

Sonuç: Aksiyon önerisi

Swap ayarlarını değiştirmeden önce free -h, vmstat ve iostat ile mevcut davranışı ölçün; thrashing sinyali varsa swap’i büyütmek yerine bellek kök nedenini giderin. Eğer sistem swap’i hiç kullanmıyorsa küçük bir koruma swap ile ilerleyin; swap kısa piklerde devreye giriyorsa kontrollü bir swappiness ayarıyla davranışı sınırlayın. Her durumda, değişiklik sonrası 30-60 dakika boyunca si/so ve disk latency’yi birlikte izleyin; hedefiniz disk I/O’yu kalıcı biçimde darboğaza sokmadan OOM riskini minimumda tutmaktır.