VPS.TC
| $
Sunucu Durumu
Turkey İstanbul, Türkiye
Aktif
USA New York, ABD
Aktif
Sepet Toplamı:
Sepeti Görüntüle
VPS’te Swap Alanı Oluşturma ve Linux Bellek Yönetimi
Linux

VPS’te Swap Alanı Oluşturma ve Linux Bellek Yönetimi

Defne avatarı Defne Ağustos 30, 2026 11 dk okuma 0 Yorumlar
Paylaş:

VPS’te Swap Alanı Oluşturma ve Linux Bellek Yönetimi

Bir VPS’in yavaşladığı gece ilk baktığım yer çoğu zaman işlemci değildir. top açarım, birkaç sürecin durumunu kontrol ederim, ardından bellek tablosuna geçerim. CPU neredeyse boşta görünürken uygulamalar cevap vermiyorsa RAM baskısı ihtimalini gözden kaçırmamak gerekir. Servisi hemen yeniden başlatmak, bazen yalnızca alarmı susturur.

Swap burada devreye girer. RAM’de yer kalmadığında Linux, bazı bellek sayfalarını diskteki özel bir alana taşıyabilir. Bu alan RAM kadar hızlı değildir. Amacı RAM’in yerine geçmek değil, kısa süreli bellek baskısında sistemi doğrudan OOM katiline bırakmamaktır.

🚀 VPS Sunucu ile Hızınızı Artırın!

Yüksek performanslı SSD depolama ve %99.9 uptime garantisi ile projelerinizi hızlandırın.

Hemen Başla

VPS’te swap alanı oluşturmak birkaç komutla biter. Güvenli bir kurulum için dosya izinlerini, kalıcı bağlama kaydını, mevcut swap alanlarını ve sağlayıcının politikalarını da kontrol ederim. Benim sık gördüğüm hata, swap dosyasını oluşturup /etc/fstab kaydını atlamak. Sunucu yeniden başladığında dosya orada durur, fakat etkin değildir.

Linux belleği yalnızca RAM’den oluşmuyor

Linux belleğini kabaca anonim bellek, dosya önbelleği ve çekirdek tarafından kullanılan alanlar şeklinde düşünebilirsiniz. PHP-FPM sürecinin ayırdığı bellek anonim sayfalarda tutulurken diskten okunan dosyalar page cache içinde önbelleğe alınabilir. Bu nedenle free çıktısındaki buff/cache değerini doğrudan boşa harcanmış bellek saymak yanıltıcıdır.

free -h

Örnek bir çıktı şöyle görünebilir:

☁️ Cloud Sunucu ile Esneklik Kazanın!

Ölçeklenebilir kaynaklar ve anlık yedekleme ile bulutun gücünü deneyimleyin.

Keşfet
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       2.1Gi       180Mi       120Mi       1.5Gi       1.3Gi
Swap:          1.0Gi       128Mi       896Mi

Ben özellikle available sütununa bakarım. free düşük görünse bile kullanılabilir bellek yüksek olabilir; Linux ihtiyaç duyduğunda dosya önbelleğinin bir bölümünü bırakır. Swap satırında kullanım görülmesi de tek başına kriz değildir. Asıl soru, sistemin sürekli ve yoğun biçimde swap okuyup yazıp yazmadığıdır.

Bellek baskısı arttığında çekirdek önce kolayca yeniden oluşturulabilecek önbellekleri bırakır. Yetmezse anonim sayfaları swap alanına taşıyabilir. Hiçbir işlem kurtarılamıyorsa OOM killer devreye girer ve belleği tüketen süreçlerden birini sonlandırır. Üretimde öldürülen sürecin veritabanı veya web sunucusu olmasını istemezsiniz.

Swap neyi çözer, neyi çözmez?

Swap, düşük RAM’li bir VPS’te ani bellek sıçramalarını karşılayan bir emniyet supabı olabilir. Yedekleme sırasında sıkıştırma işleminin kısa süreli olarak daha fazla bellek istemesi buna örnek. Swap süreci ayakta tutabilir.

Disk RAM’den çok daha yavaştır. Sistem sürekli swap kullanıyorsa uygulama gecikmeleri artar, disk I/O beklemeleri yükselir ve VPS’in tamamı ağırlaşır. Böyle bir durumda daha büyük swap eklemek kalıcı çözüm değildir. Önce bellek tüketen süreci bulur, gereksiz servisleri kapatır veya VPS planını büyütürüm.

Gözlem Muhtemel anlam İlk kontrol
Swap kullanımı var, available yüksek Uzun süredir dokunulmayan sayfalar diske taşınmış olabilir free -h ve zaman içindeki değişim
Swap sürekli artıyor RAM baskısı veya bellek sızıntısı olabilir vmstat 1, süreçlerin RSS değerleri
RAM ve swap dolu OOM riski çok yüksek Journal kayıtları ve servis limitleri
Swap I/O çok yoğun Sistem RAM yerine diski kullanıyor iostat ve uygulama logları

Komut çalıştırmadan önce tabloyu görün

Komutları root olarak çalıştırabilirsiniz. Ben yine de mümkün olduğunca sudo kullanıyorum; yanlış terminalde yapılan işlemler için sihirli bir koruma sağlamaz ama niyeti görünür kılar. Production shell’lerimdeki kırmızı prompt da aynı alışkanlığın devamı.

hostnamectl --static
free -h
swapon --show
cat /proc/swaps
lsblk -f

swapon --show boş dönüyorsa sistemde etkin swap olmayabilir. Bazı sağlayıcılar VPS’i hazır swap alanıyla sunar, bazıları sanallaştırma katmanında swap kullanımını sınırlar. Sağlayıcınızın dokümantasyonunu kontrol edin. Aynı alanı ikinci kez etkinleştirmeye çalışmak gereksizdir.

Diskteki boş alanı da ölçün:

df -h /
findmnt -no FSTYPE,OPTIONS /

Swap dosyasını kök dosya sistemine koyacaksanız yeterli boş alan bulunmalı. Dosya sistemi de önemlidir. Modern Linux kurulumlarında ext4 ve XFS üzerinde swap dosyası genellikle sorunsuz çalışır. Btrfs kullanıyorsanız swapfile için özel koşullar vardır; copy-on-write davranışının kapatılması ve dosya düzeninin uygun olması gerekir. Btrfs üzerinde genel bir tarifi düşünmeden uygulamam.

Ubuntu ve Debian’da swap dosyası oluşturma

Aşağıdaki örnekte 2 GiB büyüklüğünde /swapfile oluşturuyorum. İhtiyacınız farklı olabilir. 512 MiB RAM’li her VPS’e otomatik olarak 4 GiB swap eklemek doğru bir kural değil; çalışan servislerin gerçek tüketimini ölçmek daha sağlıklı.

Dosyayı ayırın

sudo fallocate -l 2G /swapfile
ls -lh /swapfile

fallocate hızlıdır ve dosyayı istenen boyutta ayırır. Bazı dosya sistemlerinde veya eski ortamlarda beklenmedik sonuç alırsanız dd kullanılabilir:

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

Bu satır daha yavaş olabilir; dosyaya sıfırları gerçekten yazar. count=2048 ve bs=1M yaklaşık 2 GiB alan üretir. Hedef yolu iki kez kontrol edin. of= değerindeki bir yazım hatası pahalıya mal olabilir.

Dosya izinlerini daraltın

sudo chmod 600 /swapfile
ls -l /swapfile

Beklenen izinler yaklaşık olarak -rw------- biçimindedir. Swap içeriği, süreçlerin RAM’den taşınmış parçalarını barındırabilir. Herkesin okuyabildiği bir swap dosyası bırakmak doğru değildir. chmod 777 ile izin sorunlarını çözmeye çalışmak burada da işe yaramaz; yalnızca güvenlik açığını büyütür.

Swap olarak biçimlendirin ve etkinleştirin

sudo mkswap /swapfile
sudo swapon /swapfile
sudo swapon --show
free -h

mkswap dosyaya swap imzası yazar, swapon ise onu çekirdeğin kullanabileceği hale getirir. swapon --show çıktısında /swapfile görünüyorsa etkinleştirme tamamlanmıştır.

swapon: /swapfile: insecure permissions benzeri bir uyarı görürseniz önce chmod 600 uygulayın. Operation not permitted hatası sanallaştırma sağlayıcısının swap kullanımını engellediğine işaret edebilir. Böyle bir durumda rastgele komut denemek yerine VPS türüne ve destek belgelerine bakın.

Yeniden başlatma sonrasında da etkin kalsın

Şimdi /etc/fstab dosyasına tek satır ekleyin:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Ben dosyanın sonuna eklemeden önce mevcut swap kayıtlarını kontrol ederim:

grep -nE '[[:space:]]swap[[:space:]]' /etc/fstab
sudo systemctl daemon-reload
sudo swapoff /swapfile
sudo swapon -a
sudo swapon --show

Son üç komut, fstab kaydının okunabildiğini yeniden başlatmadan sınar. swapoff sırasında yeterli RAM yoksa işlem başarısız olabilir; çalışan bir sunucuda swap’ı kapatmadan önce free -h çıktısını kontrol edin. Zorlamak sistemi daha kötü duruma sokabilir.

Swap boyutunda sihirli sayı aramayın

RAM miktarına göre hazırlanmış otomatik swap tabloları internette sık görülüyor. Bunlar başlangıç noktası olabilir, karar mekanizması değil. Web sunucusu, veritabanı, Docker konteynerleri ve derleme işleri farklı bellek davranışlarına sahiptir.

Bir VPS için boyutu belirlerken üç şeye bakarım: yoğun saatlerdeki available bellek, süreçlerin tepe tüketimi ve disk kapasitesi. Birkaç yüz megabaytlık ani artışı karşılamak için 1 veya 2 GiB swap yeterli olabilir. Büyük veritabanlarını swap’a güvenerek çalıştırmak ise performans sorununu ertelemektir.

Örneğin 2 GiB RAM’li, yalnızca Nginx ve küçük bir uygulama çalışan VPS’te 1 GiB swap makul bir emniyet payı olabilir. Aynı makinede Elasticsearch, MariaDB ve birkaç konteyner çalışıyorsa önce servislerin bellek sınırlarını düzenlerim. Yeni VPS kurulumlarında temel adımları kontrol etmek için Yeni VPS Sunucuyu 30 Dakikada Canliya Alma Rehberi içindeki servis ve güvenlik sırasına da bakabilirsiniz.

Linux’un swap kullanma eğilimini ayarlamak

Linux çekirdeği swap’a ne kadar istekli davranacağını vm.swappiness değeriyle etkiler. Değer 0 ile 200 arasında olabilir; yorum ayrıntıları dağıtım ve çekirdek davranışına göre değişse de düşük değer, anonim belleği swap’a taşımada daha temkinli bir yaklaşım anlamına gelir.

cat /proc/sys/vm/swappiness

Geçici olarak 10 değerini denemek isterseniz:

sudo sysctl vm.swappiness=10

Kalıcı ayar için ayrı bir dosya kullanmak daha düzenlidir:

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-memory.conf
sudo sysctl --system

Bu değeri 0’a çekmek çoğu zaman iyi fikir değildir. Swap hiç kullanılmasın isteği anlaşılır, fakat RAM tamamen dolduğunda sistemin manevra alanını daraltabilirsiniz. Ben düşük RAM’li uygulama VPS’lerinde 10 veya 20 ile başlar, monitoring verisine bakmadan daha ileri ayar yapmam.

Swap gördüğünüz anda swappiness’i değiştirmek de aceleciliktir. Saatlerdir dokunulmayan bir sayfanın swap’a taşınması RAM’i dosya önbelleği için serbest bırakabilir. Uygulama yanıt süreleri normal, swap I/O düşük ve available bellek sağlamsa bu davranış tek başına hata değildir.

Yoğun swap kullanımının izini sürmek

Bir makinenin gerçekten swap yüzünden zorlanıp zorlanmadığını anlık free çıktısından anlamak zordur. vmstat ile bir saniyelik aralıklarla izlemek daha anlamlıdır:

vmstat 1

Çıktıdaki si swap-in, so ise swap-out hızını gösterir. Bu iki sütun uzun süre düzenli biçimde yüksekse bellek baskısı vardır. Kısa bir değer görüp paniğe kapılmayın; süreklilik ve uygulama gecikmeleri daha değerlidir.

Hangi süreçlerin belleği tükettiğini görmek için:

ps -eo pid,user,comm,%mem,rss --sort=-rss | head -n 15
systemd-cgtop

rss, sürecin RAM’de tuttuğu fiziksel bellek miktarını yaklaşık olarak gösterir ve kilobayt cinsindendir. Paylaşılan kütüphaneler nedeniyle süreç değerlerini basitçe toplamak toplam RAM kullanımını birebir vermez. Yine de listenin tepesinde hangi servisin durduğunu anlamak için işe yarar.

Docker kullanıyorsanız konteynerlerin bellek sınırlarını da kontrol edin:

docker stats --no-stream

Bir konteyner için bellek limiti belirlemek, uygulamanın kontrolsüz büyümesini engelleyebilir. Limiti rastgele düşük vermek ise konteyneri OOM durumuna sokar. Önce normal ve yoğun çalışma profillerini ölçün.

Geçen ay bir müşteri VPS’inde uygulama yanıt süreleri artmış, fakat free -h çıktısında boş bellek hâlâ görünüyordu. vmstat 1 çıktısındaki düzenli si ve so hareketi şüpheyi swap’a çevirdi; ardından ps listesinin tepesinde beklenenden fazla PHP-FPM worker’ı gördüm. Worker sayısını uygulamanın gerçek trafiğine göre düşürüp birkaç saat izledik. Swap’ı büyütmedim. Sorun, diskin küçük olması değil, süreç havuzunun kontrolsüz genişlemesiydi.

Swap alanını kaldırmak veya yeniden boyutlandırmak

Yanlış boyutta bir swap dosyası oluşturduysanız yeni bir dosya eklemek zorunda değilsiniz. Önce aktif alanı kapatın, fstab satırını kaldırın, dosyayı silin ve yeni boyutu oluşturun.

sudo swapoff /swapfile
sudo sed -i '|^/swapfile none swap sw 0 0$|d' /etc/fstab
sudo rm -f /swapfile

sed satırı yalnızca tam eşleşen kaydı siler. Yine de production sistemlerinde dosyayı değiştirmeden önce sudo cp -a /etc/fstab /etc/fstab.bak ile küçük bir yedek alırım. swapoff başarısız olursa RAM durumunu inceleyin; sistemin taşıyamayacağı bir işlemi zorlamayın.

Dosyayı silmeden önce aktif swap’ın gerçekten kapandığını swapon --show ile doğrulayın. Aynı isimle yeni dosyayı hazırlarken etkin eski alanı karıştırmak, özellikle acele bir gece müdahalesinde kolaydır.

VPS ortamında dikkat edilmesi gereken noktalar

Her VPS aynı sanallaştırma özelliklerine sahip değildir. OpenVZ tabanlı bazı eski ortamlarda kullanıcı içinden swap oluşturmak mümkün olmayabilir. KVM tabanlı bir VPS’te sanal disk üzerinde swap dosyası oluşturmak daha yaygın bir yöntemdir; sağlayıcının kullanım şartları yine geçerlidir.

Swap dosyasının bulunduğu disk dolarsa sistemin başka sorunları da başlar. Loglar, veritabanı dosyaları ve yedekler aynı dosya sistemindeyse df -h değerini izleyin. Disk alanı kritik seviyeye geldiğinde önce ncdu ile hangi dizinin büyüdüğünü bulurum; rastgele dosya silmek yerine sahibini ve uygulamanın davranışını anlamaya çalışırım.

Güvenlik tarafında swap dosyasını şifrelemek bazı tehdit modellerinde değerlidir. VPS sağlayıcısının disk şifrelemesi, snapshot politikası ve fiziksel disk erişimi hakkında bilgi sahibi değilseniz swap’a taşınabilecek hassas verileri ayrıca değerlendirin. Tam disk şifreleme mümkün değilse Linux’ta şifreli swap kurulumu dağıtıma ve açılışta anahtar yönetimine göre değişir; kopyala-yapıştır bir reçete vermek yerine bu kısmı sağlayıcının belgeleriyle birlikte tasarlamak gerekir.

Swap, yedek değildir. İçeriği korunacak uygulama verisi değil, çekirdeğin çalışma alanıdır. Sistem çöktüğünde swap dosyasının var olması veritabanını geri getirmez. Yedek kontrolü için Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım başlığındaki yedekleme ve erişim kontrolleriyle birlikte ayrı bir plan yürütün.

ZRAM ne zaman daha mantıklı olabilir?

ZRAM, RAM içinde sıkıştırılmış bir blok cihazı oluşturarak swap benzeri bir alan sağlar. Fiziksel disk I/O’sunu azaltabilir ve küçük sistemlerde işe yarayabilir; karşılığında CPU kullanır. Klasik swap dosyasının her ortamda otomatik alternatifi değildir.

CPU’su zaten dolu olan bir VPS’te zram eklemek yanıt sürelerini kötüleştirebilir. Düşük trafikli bir sistemde kısa bellek sıçramalarını RAM içindeki sıkıştırılmış alanla karşılamak ise faydalı olabilir. Önce sağlayıcının çekirdek ve modül desteğini, ardından monitoring sonuçlarını kontrol edin.

Kurulumdan sonra baktığım noktalar

  • free -h ile RAM ve swap görünür mü?
  • swapon --show beklenen dosyayı veya bölümü listeliyor mu?
  • ls -l /swapfile çıktısında izinler 600 mı?
  • /etc/fstab içinde tek ve doğru bir kayıt var mı?
  • sudo swapoff /swapfile && sudo swapon -a testi başarıyla tamamlanıyor mu?
  • vmstat 1 sırasında sürekli yüksek si ve so değerleri görülüyor mu?
  • Monitoring RAM kullanımı, swap ve OOM kayıtlarını izliyor mu?

Kernel günlüklerine de bakarım:

journalctl -k -b | grep -iE 'out of memory|oom|killed process'

Çıktının boş olması iyi bir işarettir, fakat gelecekte OOM olmayacağını kanıtlamaz. Uptime Kuma veya Grafana ve Prometheus kullanan bir sisteminiz varsa bellek, swap ve disk I/O metriklerini aynı zaman aralığında izleyin. Olay anındaki süreç, trafik ve deploy kayıtlarını yan yana koymak tek bir grafiğe bakmaktan daha sağlıklıdır.

VPS swap komutları kısa, bellek yönetimi biraz daha sabır isteyen bir konu. Benim çalışma sıram basit: önce ölçer, sonra swap ekler, ardından kullanımın gerçekten düzelip düzelmediğini izlerim. Sunucuda swap bulunması rahatlatıcıdır; onu sürekli kullanan sunucu ise size hâlâ çözülmemiş başka bir sorunu anlatıyordur.

Sık Sorulan Sorular

VPS için ne kadar swap alanı oluşturmalıyım?

Tek bir doğru boyut yoktur; VPS’in RAM miktarı, çalışan servisler ve en yoğun bellek kullanımı birlikte değerlendirilmelidir. Küçük bir uygulama sunucusunda 1-2 GiB başlangıç için yeterli olabilir. Swap’ı RAM eksikliğinin kalıcı çözümü gibi görmeyin.

Swap kullanımı VPS’i yavaşlatır mı?

Evet. Yoğun swap okuma ve yazma işlemleri, diskin RAM’e göre yavaş olması nedeniyle uygulamaları ağırlaştırabilir. Kısa süreli ve düşük swap kullanımı normal olabilir; vmstat 1 çıktısında si ve so değerleri sürekli yükseliyorsa bellek tüketimini inceleyin.

Swap dosyası mı, swap bölümü mü daha iyi?

Modern Linux sistemlerinde swap dosyası, yönetim kolaylığı nedeniyle çoğu VPS için yeterlidir. Swap bölümü doğrudan disk alanı sunar, fakat boyutunu sonradan değiştirmek daha zahmetlidir. VPS sağlayıcısı özel bir seçenek sunmuyorsa dosya pratik bir tercihtir.

Swap dosyası yeniden başlatmadan sonra neden kayboluyor?

swapon komutu swap’ı yalnızca mevcut çalışma oturumu için etkinleştirir. /etc/fstab içine /swapfile none swap sw 0 0 kaydı eklenmemişse yeniden başlatma sonrasında dosya otomatik olarak etkinleşmez.

Defne avatarı
Yazar

Defne

vps.tc blog yazarı. Sistem yönetimi, Linux ve hosting dünyası üzerine yazıyor.