Sunucu İçin RAM mi CPU mi Daha Önemli?

Yıllarca sunucu yönetimi yapan biri olarak şunu söyleyebilirim: bu soruyu doğru cevaplamak, binlerce dolarlık donanım kararını etkileyebilir. “Daha fazla RAM mı alalım yoksa daha hızlı işlemci mi?” sorusu her proje toplantısında çıkar karşıma. Ve her seferinde aynı şeyi söylerim: yanlış soru bu. Doğru soru şu olmalı: “İş yükümün darboğazı nerede?”

Önce Ölç, Sonra Karar Ver

Tahmine dayalı donanım kararları genellikle israf ya da yetersizlikle sonuçlanır. Sisteminizin gerçekte ne yaptığını anlamadan “daha fazlası iyidir” mantığıyla hareket etmek profesyonelce değil. Başlangıç noktanız her zaman mevcut sistemin profilini çıkarmak olmalı.

Linux’ta anlık sistem durumunu görmek için:

# CPU, RAM ve yük ortalamasını tek bakışta görmek
vmstat 1 10

# Daha detaylı bellek analizi
free -h && cat /proc/meminfo | grep -E "MemTotal|MemFree|Cached|SwapUsed"

# İşlemci kullanımı süreç bazlı
top -b -n 1 | head -20

Bu komutları özellikle yoğun saatlerde çalıştırın. Gece 3’teki sistem durumu sizi yanıltır. Öğleden sonra 2, Pazartesi sabahı 9 veya uygulamanızın en çok kullanıldığı zaman dilimi sizin için gerçek resmi gösterir.

Windows Server tarafında da benzer şeyi Performance Monitor ile yapabilirsiniz, ama komut satırından hızlı bir bakış için:

# Windows Server - PowerShell ile bellek ve CPU durumu
Get-Counter 'Processor(_Total)% Processor Time','MemoryAvailable MBytes' -SampleInterval 2 -MaxSamples 10

CPU Darboğazını Tanımak

İşlemci darboğazı yaşayan bir sistemin belirtileri oldukça nettir. load average değerleriniz CPU çekirdek sayınızı sürekli aşıyorsa, iowait değil user veya sys zamanı yüksekse, CPU sınırlı bir sistemdesiniz demektir.

# CPU kullanımını çekirdek bazında izlemek
mpstat -P ALL 2 5

# Hangi süreçler CPU yutuyor?
ps aux --sort=-%cpu | head -15

# CPU steal değeri (sanal makinelerde kritik!)
iostat -c 2 5

steal değerine dikkat edin. Özellikle cloud veya VPS ortamlarında bu değerin yüksek olması, fiziksel sunucudaki diğer sanal makinelerin CPU kaynağınızı çaldığı anlamına gelir. Bu durumda daha güçlü bir plan almak gerekebilir, ama daha fazla CPU satın almak çözüm değildir.

CPU darboğazının tipik senaryoları şunlardır:

Matematiksel hesaplama yoğun uygulamalar: Makine öğrenmesi modeli eğitimi, video encoding, şifreleme işlemleri
Yüksek concurrency altında web sunucuları: Çok sayıda eş zamanlı isteği işleyen API servisleri
Veritabanı sorgu optimizasyonu: Özellikle karmaşık JOIN ve aggregation işlemleri
Compiler ve build sistemleri: CI/CD pipeline’larında derleme süreçleri
Gerçek zamanlı veri işleme: Log analizi, stream processing

RAM Darboğazını Tanımak

Bellek yetersizliği çok daha sinsi davranır. Sistem çökmez, sadece yavaşlar. Ve bu yavaşlama zamanla logaritmik olarak artar çünkü işletim sistemi swap kullanmaya başlar.

# Swap kullanımını ve ne zaman başladığını görmek
swapon --show
vmstat 1 5 | awk '{print $7, $8, $9}'
# si: swap-in (diskten RAM'e), so: swap-out (RAM'den diske)

# Hangi süreçler ne kadar bellek kullanıyor?
ps aux --sort=-%mem | head -15

# Detaylı bellek haritası (production'da dikkatli kullanın)
pmap -x $(pgrep -f "java|python|node") 2>/dev/null | tail -3

vmstat çıktısında so (swap out) değerinin sıfırdan farklı olması ciddi bir uyarıdır. Sistem aktif olarak belleği diske taşıyorsa, performans probleminizin kaynağı büyük ihtimalle RAM yetersizliğidir.

RAM darboğazının klasik göstergeleri:

so ve si değerleri sürekli sıfırdan farklı: Swap aktif kullanımda
free çıktısında available bellek sürekli düşük: Kernel buffer/cache kullanımı makul bile olsa
Uygulama OOM (Out of Memory) hataları: Kernel süreçleri öldürüyor
Disk I/O yükü belirgin şekilde yüksek: RAM’e sığmayan veriler diske taşınıyor

# OOM olaylarını kernel loglarında aramak
dmesg | grep -i "out of memory|oom_kill"
journalctl -k | grep -i oom | tail -20

Eğer bu komutlar çıktı veriyorsa, sunucunuz bellek açısından stres altında demektir.

Workload Tiplerine Göre Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Web Uygulaması

Birkaç yıl önce büyük bir e-ticaret müşterisinin altyapısını devralırken karşılaştığım durumu anlatayım. 8 çekirdek ve 16 GB RAM’li sunucularda PHP tabanlı uygulama çalışıyordu. Kampanya günlerinde sistem çakılıyordu.

İlk içgüdüsel karar “CPU’yu ikiye katalım” yönündeydi. Ama profilleme başka bir şey söyledi: PHP-FPM süreçleri worker başına ortalama 180 MB RAM tüketiyordu ve 80 worker çalışıyordu. Bu başlı başına 14 GB yapıyor. Sisteme neredeyse hiç boş RAM kalmıyordu.

Çözüm? CPU değil, RAM. 64 GB’a çıkıldığında kampanya günleri sorunsuz geçmeye başladı. CPU kullanımı zaten %40-50 bandında kalıyordu.

# PHP-FPM süreç bellek kullanımını hesaplamak
ps aux | grep php-fpm | grep -v grep | awk '{sum += $6} END {print sum/1024 " MB toplam, ortalama: " sum/NR/1024 " MB"}'

Senaryo 2: Veri Ambarı Sorguları

Büyük ölçekli raporlama yapan bir fintech şirketi için PostgreSQL optimizasyonu yaparken tam tersi durumla karşılaştık. Sunucuda 128 GB RAM vardı, sorgular hala yavaştı.

# PostgreSQL'de yavaş sorguları bulmak
psql -U postgres -c "SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes';"

# Shared buffer ve effective cache ayarlarını kontrol etmek
psql -U postgres -c "SHOW shared_buffers; SHOW effective_cache_size; SHOW work_mem;"

RAM doluydu ama işlemci tek çekirdekte çalışıyordu. max_parallel_workers_per_gather parametresi 0’dı ve büyük aggregation sorguları paralel işlenemiyor, tek çekirdekte sürünüyordu. Burada RAM değil CPU konfigürasyonu sorundu. Daha doğrusu, mevcut CPU’nun doğru kullanılmaması.

Senaryo 3: Kubernetes Cluster’ı

Konteyner ortamlarında bu soruyu doğru yanıtlamak daha da kritik. Çünkü yanlış resource limit tanımları cascade failure’a yol açabilir.

# Node kaynak kullanımını görmek
kubectl top nodes

# Pod bazlı kaynak kullanımı
kubectl top pods --all-namespaces --sort-by=memory | head -20

# Node'da allocatable kaynak miktarını görmek
kubectl describe node <node-name> | grep -A 5 "Allocatable:"

Kubernetes’te CPU limiti aşıldığında pod throttle edilir, yani yavaşlatılır. RAM limiti aşıldığında pod OOMKilled ile sonlanır ve restart eder. Bu davranış farkını anlamak, limit değerlerini doğru belirlemenizi sağlar.

Bellek Türü ve CPU Mimarisi de Önemli

Sadece miktar yetmiyor. Belleğin hızı ve işlemcinin mimarisi de kritik rol oynar. Modern sunucularda DDR4 vs DDR5 farkı, yoğun bellek erişimli uygulamalarda fark edilir düzeyde. NUMA (Non-Uniform Memory Access) mimarisi hakkında bilgi sahibi olmak da özellikle yüksek çekirdek sayılı sistemlerde önemli.

# NUMA topolojisini görmek
numactl --hardware

# Sürecin NUMA dağılımını kontrol etmek
numastat -p $(pgrep -f "mysqld|postgres|java") 2>/dev/null

# NUMA politikasını belirlemek (veritabanı süreçleri için)
numactl --cpunodebind=0 --membind=0 /usr/bin/mongod --config /etc/mongod.conf

Büyük bir veritabanı sunucusunda NUMA-aware konfigürasyon yapmadan önce ve sonraki kıyaslama yapıldığında, sadece bu ayarlamayla %20-30 sorgu performansı artışı gördüğüm oldu. Donanım satın almadan, sıfır maliyet.

Cache ve Buffer Mantığını Anlamak

Linux kernel’i boş belleği israf olarak görür. free -h komutunda gördüğünüz “free” değeri düşük olabilir ama bu sorun değildir, eğer “available” yeterince yüksekse.

# Doğru okuma: available değeri önemli olan
free -h
#               total        used        free      shared  buff/cache   available
# Mem:           31Gi        8.2Gi       1.1Gi       512Mi        22Gi        22Gi

# Kernel'in page cache kullanımını görmek
cat /proc/meminfo | grep -E "^(Cached|Buffers|SwapCached|Active|Inactive):"

# Page cache'i temizlemek (dikkatli! production'da performansı geçici düşürür)
echo 3 > /proc/sys/vm/drop_caches

Kernel’in page cache’i dolu tutması aslında bir optimizasyon. Disk yerine bellekten okunan veri çok daha hızlı işlenir. Eğer uygulamanız aynı dosyaları veya veri bloklarını tekrar tekrar okuyorsa, yeterli RAM bu erişimleri otomatik olarak cache’ler.

Gerçek Yük Testi ile Karar Vermek

Teorik analizin ötesinde, gerçek yük testleri en güvenilir cevabı verir. Basit bir yaklaşım:

# stress-ng ile CPU stres testi
stress-ng --cpu 4 --cpu-load 75 --timeout 60s --metrics-brief

# Bellek baskısı testi
stress-ng --vm 2 --vm-bytes 4G --timeout 60s --metrics-brief

# Her iki kaynağı birlikte test etmek
stress-ng --cpu 4 --vm 2 --vm-bytes 2G --timeout 120s --metrics-brief 2>&1 | tee stress_results.txt

Test sırasında vmstat 1 veya dstat ile sistemi izlemek, hangi kaynağın önce doyuma ulaştığını gösterir. Doyuma ulaşan kaynak sizin darboğazınızdır.

# dstat ile kapsamlı izleme (stress testi sırasında)
dstat -cdngy --top-cpu --top-mem 2

Uygulamaya Özel Genel Kurallar

Kesin bir kural olmasa da deneyime dayalı başlangıç noktaları verebilirim:

Çok RAM gerektiren iş yükleri:

In-memory veritabanları: Redis, Memcached, Apache Ignite
Büyük dataset işleyen analitik sistemler: Elasticsearch, ClickHouse, Spark
JVM tabanlı uygulamalar: Heap boyutu belirleyici, büyük heap = fazla RAM
Sanallaştırma host’ları: Her VM’in RAM’i fiziksel RAM’den geliyor

Çok CPU gerektiren iş yükleri:

Paralel hesaplama: FFmpeg, rendering, bilimsel simülasyon
Yüksek RPS web servisleri: Her istek CPU tüketiyor, concurrency ile skala
CI/CD build sunucuları: Paralel derleme için çekirdek sayısı kritik
Şifreleme yoğun sistemler: TLS termination, VPN gateway

Her ikisi de kritik:

Yüksek trafikli veritabanları: Hem query işleme CPU ister, hem working set RAM ister
Büyük ölçekli Kubernetes node’ları: Konteyner yoğunluğuna göre dengelenmiş olmalı

Performans Metrikleri Toplama ve Alarm Kurma

Anlık ölçüm yetmez. Trend analizi için metrik toplamanız gerekir. Basit bir yaklaşım:

# Sistematik metrik toplama scripti
#!/bin/bash
LOGFILE="/var/log/perf_metrics.log"
while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
    MEM_USED=$(free | awk '/^Mem:/{printf "%.1f", $3/$2*100}')
    SWAP_USED=$(free | awk '/^Swap:/{if($2>0) printf "%.1f", $3/$2*100; else print "0"}')
    LOAD=$(cat /proc/loadavg | awk '{print $1}')
    echo "$TIMESTAMP CPU:$CPU% MEM:$MEM_USED% SWAP:$SWAP_USED% LOAD:$LOAD" >> $LOGFILE
    sleep 60
done

Bu scripti systemd servisi olarak veya nohup ile arka planda çalıştırabilirsiniz. Birkaç günlük veri size normal yük profilini gösterir.

Kapasite Planlama Yaklaşımı

Mevcut sisteminizi doğru ölçtünüz, darboğazı buldunuz. Şimdi büyüme planı yapma zamanı.

Pratik bir kural olarak:

CPU kullanımı sürekli %70 üzerindeyse: Ölçeklendirme zamanı. Dikey (daha güçlü CPU) veya yatay (daha fazla sunucu).
Available RAM sürekli toplam RAM’in %15’inin altındaysa: RAM artırma vakti.
Swap kullanımı sıfırın üzerindeyse ve artıyorsa: RAM yetersiz, acil müdahale.
Load average çekirdek sayısının 2 katını geçiyorsa: CPU kuyruğu tehlikeli boyutta.

# Otomatik uyarı için basit bir kontrol scripti
#!/bin/bash
CORE_COUNT=$(nproc)
LOAD=$(cat /proc/loadavg | awk '{print $1}')
SWAP=$(free | awk '/^Swap:/{if($2>0) printf "%d", $3/$2*100; else print 0}')
AVAIL_MEM_PCT=$(free | awk '/^Mem:/{printf "%d", $7/$2*100}')

[ $(echo "$LOAD > $CORE_COUNT * 1.5" | bc) -eq 1 ] && 
    echo "UYARI: Yüksek load average: $LOAD (Çekirdek: $CORE_COUNT)"

[ $SWAP -gt 10 ] && 
    echo "UYARI: Swap kullanımı %$SWAP"

[ $AVAIL_MEM_PCT -lt 15 ] && 
    echo "UYARI: Kullanılabilir bellek kritik: %$AVAIL_MEM_PCT"

Sonuç

“Yüksek RAM mı, güçlü CPU mi?” sorusunun tek doğru cevabı: “Ölçmeden bilmek mümkün değil.” Her iş yükünün farklı bir darboğazı var. Tahmine dayalı donanım kararları çoğu zaman hem pahalıya, hem de zaman kaybına neden olur.

Yıllarca gördüğüm en yaygın hata şu: uygulama yavaşladığında ilk refleks “sunucu yavaş, yeni sunucu alalım” olmak. Oysa çoğu zaman problem konfigürasyonda, yanlış ayarlanmış bellek limitlerinde, optimize edilmemiş sorgularda veya ölçülmemiş bir darboğazda.

Pratik yaklaşımı özetleyeyim:

Ölç: vmstat, top, free, iostat ile gerçek yük profilini çıkar
Analiz et: CPU mu, RAM mı, disk I/O mu, network mı tıkanıyor?
Konfigürasyonu optimize et: Donanım almadan önce yazılım ve ayar katmanında ne yapılabilir?
Sonra karar ver: Darboğazın türüne göre doğru kaynağı artır

Donanım bütçesi sınırlıysa ve ikisi arasında seçim yapmak zorundaysanız, çoğu web ve veritabanı iş yükü için RAM daha önce gelir. Bellek yetersizliği çoğu zaman swap’a düşer ve sistem tam anlamıyla felç olur. CPU yetersizliği ise genellikle yavaşlama olarak kendini gösterir, sistem çalışmaya devam eder.

Ama en doğrusu: kendi sisteminizin verilerine güvenin. Araçlar hazır, yorum sizden.

Yüksek RAM mı Güçlü CPU mi: Sunucu Performansını Ne Belirler