Derin deniz dalışında (Scuba Diving) dalgıcın hayatta kalmasını sağlayan en kritik ekipman, ana hava tüpünün yanında taşıdığı ahtapot (yedek regülatör) ve acil durum rezerv valfidir. Tecrübeli hiçbir dalgıç, "Ben zaten 30 metreye ineceğim, dipte 25 dakika kalacağım, ana tüpüm bana 40 dakika yetiyor; yedek regülatör taşımayayım, tüp sırtımda ağırlık yapmasın" demez. Çünkü denizin altında akıntıya kapılırsanız, bir kramp girerse veya panikleyip kalp atışınız fırlarsa akciğerleriniz normalin üç katı hava tüketir. Ana tüp bittiğinde elinizi uzatacağınız o yedek hava kaynağı yoksa, ciğerleriniz bir yudum havaya muhtaç kalır ve suyun 30 metre altında boğularak can verirsiniz. O yedek regülatör konfor için değil; anlık bir ölüm-kalım krizinde yüzeye çıkacak kadar nefes sağlamak içindir.
Linux sistem mühendisliğinde sanal sunucularda (VPS/Cloud) Swap (Takas / Sanal Bellek) alanını yapılandırmamak veya "Nasılsa 4 GB RAM aldık, yetmeli" diyerek Swap'ı sıfırda bırakmak, suyun dibine yedek regülatörsüz inmekten farksızdır.
Efsaneler vs. Gerçekler: "Swap SSD'yi Eskitir Mi?"
İnternetteki eski forumlarda veya yüzeysel blog yazılarında sistem yöneticilerini zehirleyen bir şehir efsanesi dolaşır:
"SSD disklerde Swap açmayın! Swap diske sürekli yazma yaptığı için NVMe/SSD diskin ömrünü (TBW) tüketir, sunucuyu yavaşlatır. RAM biterse gidin daha fazla RAM satın alın!"
Bu argüman teoride bir mantık kırıntısı taşısa da pratik sistem yönetiminde intihar anlamına gelir:
- Modern SSD/NVMe Dayanıklılığı: Günümüz kurumsal veri merkezi SSD'leri petabaytlarca (PBW) yazma garantisine sahiptir. Günde birkaç yüz megabaytlık takas alanı kullanımı bir SSD'yi yıpratamaz.
- Swap'ın Asıl Amacı RAM Yerine Geçmek Değildir: Swap, sistemin RAM'i bittiğinde uygulamaların diski RAM gibi kullanıp ışık hızında çalışması için tasarlanmamıştır. Swap; ani bir bellek sıçramasında işletim sisteminin panikleyip hayati servisleri öldürmesini engelleyen, acil durum amortisörüdür (hava yastığı).
- Boşta Kalan Belleğin Temizlenmesi: Linux çekirdeği (Kernel), uygulamaların belleğe yüklediği ama günlerdir hiç dokunmadığı hareketsiz sayfaları (anon sayfalar) Swap'a aktararak fiziksel RAM'i yüksek hızlı disk önbelleğine (page cache) tahsis eder. Swap olan bir sunucu, Swapsız bir sunucudan çoğu zaman daha verimli çalışır.
OOM Killer (Out Of Memory Katili): Çekirdeğin Acımasız İnfazcısı
Peki, Swap alanı olmayan bir Linux sunucuda fiziksel RAM %100 dolarsa ne olur?
Linux çekirdeği bellek yönetiminde Overcommit mimarisini kullanır. Uygulamalara fiziki olarak var olandan daha fazla bellek vadedebilir. Ancak tüm uygulamalar aynı anda vaat edilen belleği fiziki olarak istemeye başladığında ve serbest bırakılacak tek bir bayt RAM kalmadığında işletim sistemi kilitlenme tehlikesiyle yüzleşir.
Kernel donmamak için tek bir çareye sahiptir: OOM Killer (Bellek Yetersizliği Katili) mekanizmasını tetiklemek.
┌────────────────────────┐
│ RAM: %99.9 DOLDU! │
│ SWAP ALANI: 0 MB! │
└───────────┬────────────┘
│
▼
[LINUX KERNEL: OOM KILLER]
"Sistem donmak üzere! Birini
kurban etmek zorundayım!"
│
▼
[Kurban Puanlama: oom_score]
- En çok belleği kim yiyor?
- Kim daha kolay öldürülebilir?
│
┌─────────────────┴─────────────────┐
▼ ▼
mysqld (MySQL Veritabanı) php-fpm / node worker
RAM Kullanımı: 1.8 GB RAM Kullanımı: 400 MB
oom_score: 842 oom_score: 120
│
▼
[mysqld İNFAZ EDİLDİ! SIGKILL -9] ❌
(Sistem yöneticisine haber verilmedi,
loglara sadece 1 satır 'Killed process' yazıldı!)
OOM Killer merhametsiz bir cerrahtır. Hastayı yaşatmak için en büyük uzvu anında kesip atar. Bir sunucuda genellikle en çok belleği tüketen proses kimdir? MySQL / PostgreSQL veritabanı veya uygulamanızın ana motorudur.
Kernel gözünü bile kırpmadan MySQL prosesine SIGKILL (Kill -9) sinyalini fırlatır. Veritabanı transaction'ları tamamlayamadan, tamponları diske boşaltamadan masada kalır.
Semptom: Gece 03:00'te Kendi Kendine Kapanan MySQL
Sistem yöneticisinin destek taleplerinde sıkça karşılaştığımız o çaresiz feryat gelir:
"Sunucumda hiçbir saldırı yokken, gece durup dururken MySQL servisi duruyor. systemctl restart mysql yapınca düzeliyor ama iki gün sonra yine çöküyor! MySQL'de bug mı var?"
Sistem yöneticisi /var/log/mysql/error.log dosyasını açar; orada hiçbir hata göremez. Çünkü MySQL kendi isteğiyle kapanmamıştır; arkasından vurulmuştur.
Gerçek katili bulmak için işletim sistemi çekirdek loglarına (dmesg) bakmak gerekir:
dmesg -T | grep -i -E 'oom[- ]killer|killed process'
# ÇIKTI TÜYLER ÜRPERTİCİDİR:
# [Paz Oca 19 03:14:22 2026] Out of memory: Kill process 1245 (mysqld) score 842 or sacrifice child
# [Paz Oca 19 03:14:22 2026] Killed process 1245 (mysqld) total-vm:2845920kB, anon-rss:1450200kB, file-rss:0kBOlay aydınlanmıştır. Gece çalışan bir cron görevi, sitemizi tarayan agresif bir bot veya büyük bir XML import işlemi anlık olarak RAM'i 100 megabayt aşmış; sunucuda Swap olmadığı için Linux çekirdeği saniyeler içinde MySQL'in boğazını sıkmıştır.
5 Dakikalık Hayat Kurtarma Operasyonu: Swapfile Oluşturma
Bir Linux sunucusuna Swap eklemek, ambulansın arkasına oksijen tüpü bağlamak kadar hızlı ve basittir. Ayrı bir disk bölümü (partition) ayırmanıza gerek yoktur; tek bir dosya (swapfile) ile bu güvence sağlanır.
Adım Adım Cerrahi Müdahale:
# 1. Mevcut Swap durumunu kontrol edin (Eğer boş dönüyorsa acil durumdasınız!)
free -h
swapon --show
# 2. 4 GB boyutunda boş ve bitişik bir takas dosyası tahsis edin:
sudo fallocate -l 4G /swapfile
# (Eğer fallocate desteklenmiyorsa: sudo dd if=/dev/zero of=/swapfile bs=1M count=4096)
# 3. Dosya izinlerini yalnızca root'un okuyabileceği şekilde kilitleyin!
sudo chmod 600 /swapfile
# 4. Dosyayı Linux takas alanı olarak biçimlendirin:
sudo mkswap /swapfile
# 5. Takas alanını hemen aktif edin:
sudo swapon /swapfile
# 6. Sunucu yeniden başladığında (reboot) Swap'ın kaybolmaması için /etc/fstab'a ekleyin:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabSwappiness: Fren ve Gaz Pedalının Hassas Ayarı
Swap alanını açtıktan sonra yapılacak en kritik ince ayar vm.swappiness parametresidir.
Bu değer (0 ile 100 arasında), Linux çekirdeğinin Swap alanını ne kadar hevesle kullanacağını belirler:
swappiness = 60(Varsayılan): Kernel boşta kalan uygulamaları erkenden Swap'a itmeye çalışır. Masaüstü için iyidir ancak veritabanı sunucularında gereksiz disk I/O yapabilir.swappiness = 10veya1(Veritabanı ve Üretim Sunucuları İçin İdeal): Kernel'a şunu emreder: "Fiziksel RAM tamamen tükenme sınırına gelene kadar Swap'a dokunma! Sadece ölüm-kalım anında Swap'ı kullan!"
# Swappiness değerini 10'a çekin:
sudo sysctl vm.swappiness=10
# Kalıcı hale getirmek için:
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.confBu ayarla sunucunuz normal zamanlarda tüm hızıyla saf RAM üzerinde koşar; ancak ani bir trafik tsunamisinde OOM Killer'ın neşterine kurban gitmek yerine Swap alanına sığınarak hayatta kalır.
Kritik Servisleri OOM Killer'a Karşı Koruma Zırhı
Eğer sunucunuzda MySQL'in ne olursa olsun asla öldürülmesini istemiyorsanız, çekirdeğin puanlama mekanizmasına doğrudan müdahale edebilirsiniz:
# MySQL'in systemd servis dosyasına OOM Score koruması ekleyin:
sudo systemctl edit mysql
# Açılan pencereye şu satırı ekleyin:
[Service]
OOMScoreAdjust=-1000-1000 puan alan bir proses, OOM Killer için dokunulmaz ilan edilir. RAM bittiğinde kernel MySQL'i değil; daha az kritik olan web worker'larını veya SSH oturumlarını feda eder.
Sonuç
Dalış tüpünüz bittiğinde yedek regülatörünüzün olması size lüks bir dalış sunmaz; size nefes aldırır, panik yapmadan yüzeye çıkıp hayatınızı kurtarmanızı sağlar.
Swap alanı da sunucunuzu süper bilgisayar yapmaz; ancak RAM bittiğinde sisteminizin aniden beyin ölümüne girmesini engeller, metrikleri inceleyip sorunu çözmeniz için size altın değerinde dakikalar kazandırır. Birkaç gigabaytlık disk alanından tasarruf etmek uğruna sunucularınızı OOM Killer'ın insafına terk etmeyin.