VPS’te RAM, Swap ve OOM Killer Yönetimi

VPS’te Bellek Yönetimi Neden Bu Kadar Önemli?

VPS kullanırken çoğu proje başlangıçta CPU, disk ve trafik limitlerine odaklanıyor; RAM, swap ve OOM killer ise ancak ilk ani crash veya beklenmedik restart sonrası gündeme geliyor. Oysa Linux’ta bellek yönetimi doğru kurgulanmadığında, siteniz trafiği kaldırabilecek durumda olsa bile tek bir kötü ayar yüzünden tüm uygulama istikrarsız hâle gelebilir. Özellikle PHP-FPM, Node.js, Java, veritabanı (MySQL/PostgreSQL) ve arka plan kuyruk işçileri gibi RAM tüketimi yüksek servisler bir aradaysa, OOM killer’ın ne zaman devreye gireceğini tahmin etmek zorlaşır.

Bu yazıda DCHost ekibi olarak VPS’lerde RAM, swap ve OOM killer davranışını detaylı ama anlaşılır şekilde ele alacağız. Hedefimiz; bellek taşmalarını teşhis edebilmeniz, swap’i mantıklı kullanabilmeniz ve OOM yüzünden yaşanan beklenmedik servis duruşlarını kalıcı olarak azaltmanız. Adım adım ilerleyip hem sistem seviyesinde (sysctl, swap, cgroup/systemd limitleri) hem de uygulama tarafında (PHP memory_limit, PHP-FPM havuz ayarları, veritabanı buffer’ları vb.) yapılması gerekenleri konuşacağız.

RAM, Swap ve Linux Bellek Modeli

RAM tam olarak neyi tutar?

RAM, çalışan tüm süreçlerin (process) aktif verilerini ve kodlarını tuttuğu ana bellek alanıdır. Linux çekirdeği bu RAM’i sadece uygulama kodu ve verisi için değil, aynı zamanda disk önbelleği (page cache) ve buffer’lar için de kullanır. Bu sayede sık okunan dosyalar ve veritabanı sayfaları RAM’de tutulur, disk erişimi azalır, performans artar.

Özetle RAM’de şunlar bulunur:

• Çalışan süreçlerin kodu ve heap/stack bellekleri
• Disk önbelleği (page cache)
• Filesystem ve ağ buffer’ları
• Kernel veri yapıları

Bu yüzden free -h çıktısında RAM’in “dolu” görünmesi her zaman kötü bir şey değildir. Önemli olan; gerçekten kullanılamayan (reclaim edilemeyen) bellek miktarıdır.

“Boş RAM iyi RAM değildir” yanılgısı

Linux’ta amaç RAM’i boş tutmak değil, verimli kullanmaktır. free -h çıktısında available alanı, uygulamaların kullanabileceği yaklaşık bellek miktarını gösterir. used alanının yüksek olması, çoğu zaman disk önbelleğinin geniş olduğunu ve sistemin iyi çalıştığını bile gösterebilir.

İzlerken şu satıra odaklanmak iyi bir pratiktir:

free -h
              total        used        free      shared  buff/cache   available
Mem:           4.0G        2.5G        200M        100M        1.3G        1.0G

Burada available = 1.0G hâlâ uygulamalar için ayrılabilir RAM olduğunu, yani hemen OOM riski taşımadığınızı gösterir.

Swap nedir, gerçekte ne işe yarar?

Swap, RAM yetersiz kaldığında nadiren kullanılan bellek sayfalarının diske taşınmasını sağlayan, RAM’in “emniyet supabı” görevi gören alanıdır. Linux, aktif olmayan sayfaları swap’e atarak RAM’i boşaltabilir ve daha öncelikli iş yükleri için alan açar.

Swap’in temel amaçları:

• Beklenmedik yük artışlarında sistemi hemen çökertmek yerine nefes aldırmak
• Nadiren kullanılan bellek sayfalarını diske taşıyıp RAM’i aktif işler için serbest bırakmak
• OOM killer’ın devreye girişini geciktirmek veya tamamen engellemek

Ancak swap, disk hızına bağlıdır. NVMe diskteki swap ile yavaş HDD üzerindeki swap arasında büyük fark vardır. Yine de swap performans aracı değil, istikrar aracıdır; fazla swap kullanımı sitenizi yavaşlatabilir, ama hiç swap olmaması çoğu zaman ani crash’lere davetiye çıkarır.

OOM Killer Nedir, Nasıl Çalışır?

OOM (Out Of Memory) durumu

Linux çekirdeği, toplam RAM + kullanılabilir swap tamamen bittiğinde ve yeni bellek isteğini karşılayamadığında “Out Of Memory” durumuna girer. Bu noktada sistemin tamamen donmasını engellemek için OOM killer devreye girer ve bir veya daha fazla süreci zorla öldürerek bellek açmaya çalışır.

Bu durum özellikle küçük ve orta boy VPS’lerde şu senaryolarda sık görülür:

• PHP-FPM havuzunda çok fazla child process açılması
• Node.js veya Java uygulamasında bellek kaçağı
• MySQL/PostgreSQL buffer ve cache ayarlarının aşırı agresif olması
• Arka plan kuyruk işçilerinin (queue workers) sınırsız çoğalması

OOM killer hangi süreci öldüreceğine nasıl karar verir?

Kernel her süreç için bir oom_score hesaplar. Bellek kullanım miktarı, sürecin önemi, root olup olmadığı gibi faktörler bu skoru etkiler. OOM durumu oluştuğunda, genellikle en yüksek skorlu ve en çok RAM tüketen süreç öldürülür.

Bir sürecin skorunu görmek için örnek:

pidof php-fpm
cat /proc/<PID>/oom_score
cat /proc/<PID>/oom_score_adj

Bu skorlar sayesinde, kritik servislerin OOM tarafından öldürülmemesi için ayar yapılabilir. Örneğin veritabanı sürecinin oom_score_adj değerini düşürmek, onun son öldürülecek süreç olmasına yardımcı olur; ama bu ayar dikkatle yapılmalıdır.

OOM log’larını nerede görürüz?

OOM olayları genellikle kernel log’larına düşer. Aşağıdaki komutlarla OOM geçmişini görebilirsiniz:

dmesg | grep -i oom
journalctl -k | grep -i "out of memory"

Burada hangi sürecin öldürüldüğünü, ne kadar bellek kullandığını ve sistemin toplam bellek durumunu görebilirsiniz. Sık sık aynı sürecin hedef alındığını görüyorsanız, muhtemelen o servis için bellek limitlerini veya concurrency ayarlarını yeniden düşünmeniz gerekiyordur.

VPS’te Bellek Taşması Senaryoları: Gerçekçi Örnekler

Senaryo 1: PHP-FPM ve WordPress/WooCommerce

WordPress veya WooCommerce çalıştırılan VPS’lerde en sık gördüğümüz durum, PHP-FPM havuzunda pm.max_children değerinin RAM’e göre fazla yüksek ayarlanması. Her child process, tipik bir WordPress kurulumunda 60–150 MB arası RAM tüketebiliyor. 2 GB RAM’li bir VPS’te 20 child process açarsanız, diğer servisleri hesaba katmadan bile 1.5–3 GB arası RAM ihtiyacı doğabilir.

Bu konuyu detaylı işlediğimiz WordPress ve WooCommerce için PHP-FPM ayarları rehberinde her child’ın tahmini RAM tüketimi üzerinden nasıl hesap yapılacağını anlattık. Buradaki hesaplamayı yapmadan pm.max_children’i “bol keseden” yükseltmek, OOM killer davetiyesi anlamına geliyor.

Senaryo 2: PHP memory_limit ve ağır rapor işleri

Bir diğer klasik durum; php.ini veya panel üzerinden memory_limit değerinin 256M/512M gibi yüksek seviyelere çekilmesi. Bunu tek sayfalık bir script için düşünmek masum gelebilir; fakat eşzamanlı çalışan onlarca PHP sürecini hesaba kattığınızda RAM çarpanı ortaya çıkar.

Bu dengeyi kurmak için PHP memory_limit ve diğer kritik ayarları doğru yapmak üzerine hazırladığımız rehbere göz atmanızı öneririz. Doğru limitler, OOM riskini dramatik şekilde düşürür.

Senaryo 3: MySQL/PostgreSQL buffer ayarları

Veritabanı sunucusunda performans uğruna innodb_buffer_pool_size veya shared_buffers değerlerini “RAM’in yarısı” gibi yuvarlak rakamlarla ayarlamak da tehlikelidir. Aynı VPS üzerinde PHP-FPM, Nginx, Redis, backup script’leri ve cron işleriniz varsa, veritabanına bu kadar RAM ayırmak toplam sistemi kilitleyebilir.

Özellikle büyük kataloglu e-ticaret projelerinde bu ayarların sorgu optimizasyonu ile birlikte düşünülmesi gerekir. Bunun için WooCommerce ve büyük katalog siteleri için MySQL optimizasyon rehberinde index ve sorgu düzenlemelerinin RAM ihtiyacını nasıl azalttığını detaylı anlattık.

Senaryo 4: İzleme, log ve backup süreçleri

Birçok ekip, ana uygulamayı optimize ederken izleme agent’ları, log toplama süreçleri ve yedekleme script’lerini gözden kaçırıyor. Özellikle yoğun disk IO yapan backup araçları ve sıkıştırma (gzip, zstd) işlemleri kısa süreli RAM patlamalarına neden olabilir.

Bu yüzden VPS üzerinde tüm süreçleri uçtan uca izlemek kritik. htop, iotop, Netdata ve Prometheus ile VPS kaynak kullanımı izleme rehberimizde RAM, CPU ve disk IO’yu birlikte izleyerek dar boğazları nasıl tespit edebileceğinizi gösteriyoruz.

Adım Adım RAM ve Swap Teşhisi

free, top/htop ve /proc üzerinden temel analiz

Bellek sorunu yaşadığınızda ilk bakmanız gerekenler:

• free -h: Toplam, kullanılan, boş, buff/cache ve available bellek görünümü
• top veya htop: En çok RAM tüketen süreçler
• vmstat 1: Bellek, swap ve IO hareketini gerçek zamanlı izleme

Örnek bir teşhis akışı:

1. free -h ile available ve Swap used değerlerine bakın.
2. htop’ta RES sütununa göre sıralayıp RAM canavarlarını görün.
3. OOM şüphesi varsa dmesg | grep -i oom ile geçmiş log’ları inceleyin.

Swap kullanımını doğru okumak

Swap kullanımının 0 olması her zaman iyi haber değildir. Bu, sisteminizin swap alanına sahip olmadığı veya hiç kullanmadığı anlamına gelebilir; ancak ani yük dalgalarında OOM riskinizi artırır. Öte yandan sürekli yüksek swap kullanımı da RAM’in yetersiz olduğunu veya bellek sızıntısı (memory leak) olduğunu gösterebilir.

Sağlıklı bir VPS’te çoğu zaman şu tabloyu görmek istersiniz:

• Toplam swap > 0 (örneğin 1–4 GB arası)
• Swap used düşük veya orta seviye (ani sıçramalar incelenmeli)
• Disk IO değerleri (özellikle si/so) makul seviyede

Detaylı izleme ve alarmlar

Orta ve büyük ölçekli projelerde manuel komutlarla izleme yetersiz kalır. Prometheus + Grafana gibi çözümlerle RAM, swap, OOM olayları, process sayıları, load average gibi metrikleri paneller üzerinden takip edip eşik değerlerine alarm koymak çok daha sağlıklı olacaktır.

Bu konuda başlangıç yapmak isterseniz, VPS izleme ve alarm kurulumu rehberimizde RAM ve CPU gibi temel metrikler için pratik alarm örnekleri paylaştık.

Swap Dosyası Oluşturma ve Ayarları

Swap boyutunu nasıl seçmeli?

Yıllarca dolaşan “swap = 2 × RAM” kuralı bugün için her zaman geçerli değil; ama hâlâ kabaca referans olabilir. Modern VPS senaryolarında pratik yaklaşım şöyle olabilir:

• 1–2 GB RAM: En az 1–2 GB swap
• 4–8 GB RAM: 2–4 GB swap
• 16 GB+ RAM: İş yüküne göre 4–8 GB veya daha fazlası

Önemli olan, swap’in aşırı küçük olmaması (hemen OOM’a düşmemek için) ve aşırı büyük olup diski boğmamasıdır. NVMe diskli DCHost VPS’lerde makul büyüklükte swap, hem istikrar hem de performans açısından iyi bir dengedir.

Swap dosyası oluşturma örneği

Varsayalım 2 GB’lık bir swap dosyası oluşturmak istiyorsunuz:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

Kalıcı olması için /etc/fstab dosyasına şu satırı ekleyin:

/swapfile   none    swap    sw    0   0

Mevcut swap durumunu görmek için:

swapon --show
free -h

vm.swappiness ve diğer kernel ayarları

vm.swappiness, çekirdeğin RAM yerine swap kullanmaya ne kadar istekli olacağını belirler. 0’a yakın değerler swap’i minimumda tutar, 100’e yakın değerler daha agresif kullanım sağlar. Tipik web sunucularında 10–30 arası değerler iyi çalışır.

sysctl vm.swappiness
sysctl -w vm.swappiness=20

Kalıcı yapmak için /etc/sysctl.d/99-sysctl.conf dosyasına ekleyebilirsiniz:

vm.swappiness = 20
vm.vfs_cache_pressure = 100

vm.vfs_cache_pressure ise kernel’in inode/dentry cache’lerini ne kadar agresif temizleyeceğini belirler; aşırı düşük ayarlamak bellek baskısında sorun çıkarabilir.

OOM Killer’ı Yönetmek: Önleme, Sınırlama ve İzleme

Overcommit ayarları

Linux, bellek tahsisi konusunda “overcommit” denilen bir mekanizma kullanır. Yani süreçlere teorik olarak toplam RAM + swap’ten daha fazla bellek “vaadedebilir”. Bu davranışı şu ayarlarla kontrol edebilirsiniz:

sysctl vm.overcommit_memory
sysctl vm.overcommit_ratio

Değerler kısaca:

• vm.overcommit_memory=0: Varsayılan, heuristik.
• 1: Serbest; kernel neredeyse her isteği kabul eder.
• 2: Daha katı; toplam bellek + oran kısıtlaması uygular.

Kritik veritabanı sunucularında overcommit_memory=2 kullanmak tercih edilebilir; ancak web + DB aynı VPS’teyse yanlış yapılandırma istenmeyen hatalara yol açabilir. Küçük VPS’lerde genellikle varsayılan değerle kalıp uygulama ve service seviyesinde limit koymak daha güvenlidir.

systemd ile servis bazlı bellek limitleri

Modern Linux dağıtımlarında (Ubuntu, Debian, AlmaLinux vb.) systemd üzerinden her servise özel RAM sınırları koyabilirsiniz. Örneğin PHP-FPM için:

systemctl edit php-fpm.service

Açılan dosyaya:

[Service]
MemoryMax=1G

ekleyip kaydedin, ardından:

systemctl daemon-reload
systemctl restart php-fpm

Bu sayede PHP-FPM toplamda 1 GB’tan fazla RAM kullanamayacak; limit aşıldığında OOM killer yerine systemd devreye girip süreci kontrollü biçimde yeniden başlatacaktır. Benzer limitleri Node.js, arka plan worker’ları veya log toplayıcılar için de uygulayabilirsiniz.

OOM scorer ile kritik süreçleri korumak

Veritabanı gibi kritik servislerin, OOM durumunda en son öldürülecek süreç olmasını isteyebilirsiniz. Bunun için ilgili servisin unit dosyasında aşağıdaki gibi bir ayar yapılabilir:

[Service]
OOMScoreAdjust=-500

Bu değer -1000 (asla öldürme) ile +1000 (hedefte olsun) arasında değişir. Kritik servisleri korurken, gereksiz arka plan süreçlerine daha yüksek skor verip OOM anında onların feda edilmesini sağlayabilirsiniz. Yine de bu ayarları yapmadan önce mutlaka test ortamında denemenizi öneririz.

Uygulama Tarafı: PHP, Node.js, Java ve Diğerleri

PHP ve PHP-FPM için pratik öneriler

PHP tabanlı sitelerde bellek taşmalarının çoğu, PHP-FPM veya Apache PHP handler’larının yanlış ayarlarından kaynaklanır. Dikkat edilmesi gerekenler:

• memory_limit: Gerçek ihtiyaçlar üzerinden hesaplanmalı, “sonsuz” bırakılmamalı.
• pm.max_children: Kullanılabilir RAM / (ortalama child RAM tüketimi) üzerinden hesaplanmalı.
• pm.max_requests: Belirli sayıda istekte bir child’ların yeniden başlatılması, bellek sızıntılarını azaltır.

Bu parametreleri gerçek senaryolar üzerinden nasıl hesaplayacağınızı zaten PHP-FPM ayarları rehberimizde adım adım gösterdik. Bu rehberi RAM ve OOM yönetimiyle birlikte düşünmek en sağlıklı yaklaşım olacaktır.

Node.js uygulamaları

Node.js, tek iş parçacıklı olsa da yoğun JSON işleme, büyük sorgu sonuçları veya cache’lenmiş verilerle çalışırken rahatlıkla yüzlerce MB RAM tüketebilir. Dikkat edilmesi gerekenler:

• Node process’lerini PM2 veya systemd ile yönetip --max_old_space_size parametresiyle üst sınır koymak
• Her Node instance’ı için RAM hesabı yapıp, aynı VPS’te kaç instance çalıştırabileceğinizi belirlemek
• Uzun yaşayan, hafızada veri tutan yapıların (in-memory cache) boyutlarına limit koymak

Node.js projelerini canlıya alırken genel mimariyi nasıl kuracağınızı merak ediyorsanız, Node.js uygulamalarını host etme rehberimizde VPS tarafındaki temel yaklaşımları özetledik.

Java ve JVM tabanlı uygulamalar

Java veya Kotlin tabanlı servisler, bellek yönetimi açısından daha deterministiktir; çünkü JVM’e başlangıçta -Xms ve -Xmx parametreleriyle net sınırlar verirsiniz. Yine de bu sınırları hesaplarken:

• Toplam RAM ve diğer servislerin ihtiyacı
• GC (Garbage Collector) davranışı ve ek overhead
• Container veya cgroup limitleri (Docker kullanıyorsanız)

gibi etkenleri hesaba katmanız gerekir. Varsayılan JVM ayarları çoğu zaman VPS ortamları için fazla cömerttir; parametreleri iş yükünüze göre sadeleştirmeniz gerekir.

Kapasite Planlama ve Önleyici Stratejiler

Başlangıçta doğru VPS boyutlandırması

RAM, swap ve OOM sorunlarını minimize etmenin en kolay yolu, başlangıçta iş yükünüze uygun bir VPS boyutu seçmektir. Ziyaretçi sayısı, sayfa başına ortalama işlem süresi, kullanılan teknoloji yığını (WordPress, Laravel, Node.js, Magento vb.) ve arka plan işleri (cron, queue, raporlar) birlikte değerlendirilmelidir.

Yeni bir proje için temel hesaplara nereden başlayacağınızı bilmiyorsanız, yeni web sitesi için CPU, RAM ve trafik hesaplama rehberimizde kapasite planlaması için kullanılabilir pratik formüller paylaştık. Bu hesaplar üzerine biraz güvenlik payı koymak, OOM riskini büyük ölçüde düşürür.

Periyodik izleme ve trend analizi

Bellek sorunları çoğu zaman “bir anda” çıkmış gibi görünse de grafiklere baktığınızda yavaş yavaş artan bir trend olduğunu görürsünüz. Bu yüzden:

• RAM ve swap kullanımını günlük/haftalık grafiklerle izlemek
• Yeni sürüm deploy’larından sonra bellek trendini yakından takip etmek
• Veritabanı veya cache konfigürasyonu değişikliklerinden sonra metrikleri kıyaslamak

gibi pratikler, henüz OOM killer devreye girmeden aksiyon almanızı sağlar. DCHost altyapısında çalışan projelerde, müşterilerimize özellikle staging’de load test yaptıktan sonra RAM trendlerini izlemelerini tavsiye ediyoruz. Load test tarafına ilgi duyuyorsanız, k6, JMeter ve Locust ile kapasite ölçme rehberimiz iyi bir başlangıç olacaktır.

Alarm eşiği nasıl belirlenmeli?

İzleme sistemi kurduğunuzda, her küçük dalgalanmada uyarı almak istemezsiniz. Pratik eşik önerileri:

• RAM usage: %80 üzerine 5–10 dakika çıkarsa “warning”, %90 üzerine çıkarsa “critical”
• Swap usage: Toplam swap’in %20–30’unu geçerse uyarı, %50 üzeri sürekli ise kapasite gözden geçirilmeli
• OOM events: Her yeni OOM olayı “critical” kabul edilmeli ve kök neden analizi yapılmalı

Bu eşikler elbette iş yükünüzün doğasına göre değişebilir; fakat özellikle e-ticaret ve SaaS projelerinde bu tür sınırlar, müşteri şikâyeti gelmeden önce aksiyon almanızı sağlar.

Sonuç: VPS’te RAM, Swap ve OOM Killer’ı Rayına Oturtmak

VPS dünyasında bellek yönetimi, çoğu zaman “RAM’i yetmeyince yükseltiriz” düzeyinde ele alınıyor; ama gerçek hayatta işin bu kadar basit olmadığını hep beraber görüyoruz. Swap’i hiç kullanmamak da, aşırı güvenmek de sorun; OOM killer’ı tamamen şeytanlaştırmak da onu yok saymak da riskli. Sağlıklı bir mimaride:

• İş yüküne uygun RAM ve swap kombinasyonu
• Uygulama bazlı bellek limitleri (PHP, Node.js, Java, veritabanı)
• systemd/cgroup ve kernel (sysctl) ayarlarının dengeli kullanımı
• Sürekli izleme, alarm ve kapasite planlama

birlikte düşünülmeli. Biz DCHost ekibi olarak; VPS, dedicated sunucu ve colocation altyapılarımızda müşterilerimize tam olarak bu dengeyi kurmaları için destek veriyoruz. Bellek taşmaları, OOM kaynaklı crash ve restart sorunları yaşıyorsanız, hem sunucu boyutlandırması hem de Linux ayarları konusunda birlikte çalışarak projenizi daha dayanıklı hâle getirebiliriz.

Mevcut VPS’inizi optimize etmek veya yeni bir projeyi baştan doğru kurgulamak istiyorsanız, DCHost üzerinde ihtiyaçlarınıza uygun VPS veya fiziksel sunucu seçeneklerini değerlendirip, RAM–swap–OOM dengesini daha ilk günden planlamak uzun vadede size zaman, para ve uykusuz gecelerden tasarruf sağlar.