RAM, CPU, Disk: Sunucu spec’inde hangisi daha kritik?

Sunucu spec’lerinde RAM, CPU ve disk (özellikle depolama/IO) başlıkları sık geçer; fakat her iş yükünde aynı öncelik geçerli değildir. Bu yazıda “hangisi daha önemlidir” sorusunu teoride bırakmadan, uygulama türlerine göre hangi kaynağın darboğaz olacağını netleştiriyoruz. Ayrıca NetKıyas üzerinde karşılaştırma yaparken işine yarayacak ölçülebilir metrikleri ve test kontrol listesini de veriyorum. Sonunda, kendi senaryona göre RAM/CPU/disk ağırlığını doğru şekilde nasıl belirleyeceğini bileceksin.

RAM ne zaman kritik? (Uygulama belleği ve cache)

RAM, uygulamanın aktif çalışırken ihtiyaç duyduğu çalışma belleğidir. CPU ve disk “gecikme” üretirken, RAM çoğu zaman “yetersizlik” nedeniyle doğrudan performansı düşürür: sayfa belleğe sığmadığında sistem swap’e (disk tabanlı geçici bellek) düşer ve gecikme dramatik artar.

RAM’in kritik olduğu tipik senaryolar: - Veritabanı (DB) cache ihtiyacı: PostgreSQL/MySQL gibi sistemlerde buffer cache boyutu, sık okunan verinin disk yerine RAM’den gelmesini sağlar. - Uygulama içinde büyük çalışma seti: Örneğin Node.js/Java/Python süreçlerinde büyük in-memory objeler, oturum (session) yönetimi, template/cache katmanları. - Yüksek eşzamanlılık + her istek için bellek maliyeti: Web uygulaması başına istek başına RAM tüketen mimariler.

RAM yetersizliğinin sahada net belirtileri: - Uygulama yanıt süresi dalgalanır; yük artsa da CPU kullanımı her zaman orantılı şekilde artmaz. - Sistem seviyesinde swap kullanımı başlar. Swap aktif olduğunda disk IO artışı da genellikle eşlik eder. - “Garbage collection” (Java) veya runtime süreçlerinde düzensiz gecikmeler görülür.

RAM’i doğru okumak için bir ölçüm modeli

Sunucu spec’inde “kaç GB RAM var?” sorusunu tek başına cevap kabul etme. Şu yaklaşım işe yarar: 1. Uygulamanın çalışan süreçlerini düşün: web server (nginx), uygulama (Node/Java), worker’lar. 2. Her süreç için gerçekçi bir çalışma seti belirle. 3. Sistem için işletim sistemi + sayfa cache + buffer/paylaşımlar payı ekle.

Örnek senaryo mantığı (sayısal hedef koymak için): - Küçük tek süreçli bir web uygulaması 2 vCPU ile çalışırken 2-4 GB RAM yeterli olabilir. - Aynı uygulama background iş (queue/worker) veya yoğun cache ile 10+ eşzamanlı istek almaya başladığında 8-16 GB RAM daha makul olur.

CPU ne zaman kritik? (Hesaplama ve yoğun iş)

CPU, görevleri ne kadar hızlı hesapladığını belirler. CPU kritik olduğunda performans, genellikle çekirdek sayısı ve saat hızıyla orantılı olarak artar; fakat “tek bir çekirdek mi, tüm çekirdek mi” farkı da önemlidir.

CPU’nun öne çıktığı tipik senaryolar: - Video/stream işleme, görsel dönüştürme (ffmpeg, image resize pipeline). - Ağır şifreleme/şifre çözme, JWT imzalama gibi CPU-bound işler. - Büyük template/render veya yoğun hesaplama yapan uygulamalar. - Çok çekirdekli paralel iş: worker havuzu ile ölçeklenen mimariler.

CPU darboğazını anlatan net işaretler: - CPU kullanımı sürekli yüksek (ör. %70-100 bandı) ve yanıt süreleri buna bağlı artar. - Thread/worker queue birikir; loglarda “geç başlıyor” veya “rate limit tetikleniyor” gibi etkiler görülür. - CPU throttling (bulut/vm ortamında kaynak sınırı) varsa performans iniş-çıkış yapar.

VDS karşılaştırırken CPU’yu nasıl net ölçersin?

“CPU modeli” tek başına yetmez. Aynı kategorideki iki VDS arasında gerçek farkı şu sorular netleştirir: - Kaç vCPU var ve bu vCPU’lar garanti mi (dedicated core) yoksa oversubscription var mı? - Çok çekirdekli yükte mi yoksa tek çekirdek hassasiyeti olan işte mi fark çıkıyor? - Performans testi sırasında CPU steal time (VM’in bekleme payı) yüksek mi?

Bu yüzden karşılaştırmada şu yaklaşımı uygula: - En az 2 farklı yük senaryosu dene: “tek kullanıcı/az eşzamanlı” ve “yüksek eşzamanlı”. - Aynı süre içinde ölç: ortalama yanıt süresi, p95/p99 gecikme ve hata oranı.

Disk ve özellikle IO ne zaman kritik? (Gecikme ve IOPS)

Disk başlığı bazen sadece kapasite gibi görünür; oysa performans diskten yazma/okuma sırasında ortaya çıkan IOPS ve latency ile belirlenir. Bulut/VDS’de disk türü (SSD/NVMe) ve “paylaşımlı depolama” vs “dedike” farkı dramatik sonuç verir.

Diskin kritik olduğu tipik senaryolar: - Veritabanı write-heavy kullanım: çok sık insert/update yapan sistemler. - Dosya servis + küçük dosya çokluğu: medya yükleme, log yazma, dynamic içerik için sık okuma. - Queue/worker ve temp dosyaları: geçici dosyalar diske düşüyorsa IO gecikmesi hızla büyür. - Cache’in disk tabanlı olması: uygulama cache’i Redis/Memcached gibi RAM tabanlı değil de dosya tabanlıysa disk kritikleşir.

Disk darboğazını gösteren net işaretler: - Uygulama p95/p99 gecikmeleri özellikle yük altında artar. - CPU ve RAM gözle görülür şekilde “boş” kalırken disk IO kullanımı/latency yükselir. - Veritabanı tarafında “slow query” ve yüksek IO bekleme süreleri görülür.

NVMe mi SSD mi? Disk seçimini netleştirme

“SSD var” ifadesi tek başına yeterli değildir. Şu parametreleri aramalısın: - Disk NVMe ise genellikle daha düşük latency ve daha yüksek throughput beklenir. - Depolama RAID tipi ve “shared storage” mimarisi IO davranışını etkiler. - Sağlayıcı disk hızını resmi değerlerle veriyorsa karşılaştırma yap; vermiyorsa test olmadan karar verme.

Üçlüsü birlikte çalışır: Hangisi “ilk” darboğaz olur?

Gerçekte performans tek bir kaynakla sınırlanmaz. Ancak pratikte bir kaynağın ilk önce tükendiği durumlar vardır. Aşağıdaki matris, spec seçiminde en sık yapılan hataları azaltır.

RAM/CPU/Disk öncelik matrisi (senaryona göre)

Aşağıdaki tablo, iş yükü tipine göre hangi kaynağı önden değerlendirmen gerektiğini gösterir.

NetKıyas’ta karşılaştırırken bakman gereken spec alanları

Sağlayıcılar farklı terimler kullanabildiği için karşılaştırma yaparken şu spec seti aynı anda sorgulanmalı: - RAM: GB miktarı + (varsa) swap/limit bilgisi - CPU: vCPU sayısı, çekirdek sınırlaması, throttling/garanti bilgisi - Disk: depolama türü (SSD/NVMe), kapasite, (varsa) IOPS/throughput - Ek: bant genişliği limiti, snapshot/yedekleme (backup), lokasyon ve latency bilgisi

Uygulama türüne göre somut öneriler

Bu bölüm “şu kadar RAM al” diye tek kalemde karar vermeyi değil, kaynak önceliğini somutlaştırmayı amaçlar.

Web uygulaması (Node.js/PHP) için karar kuralı

• Yanıt süresi p95/p99 yükseliyor ama CPU düşük kalıyorsa: genellikle disk/IO veya kilitlenme (lock) vardır.
• CPU yüksek kalıyorsa: iş yükü hesaplama-bound olabilir; vCPU arttırmak daha hızlı çözüm olur.
• Swap başlıyorsa: RAM önce büyütülmelidir; CPU artışı kısa vadede bile fayda vermez.

Minimum net kontrol adımı: - Aynı trafik senaryosunda RAM’i 1-2 adım büyütmek mi, vCPU’yu artırmak mı daha hızlı sonuç veriyor test et.

Veritabanı için karar kuralı

• Çok sayıda okuma varsa: RAM öncelikli olur (buffer cache etkisi).
• Çok sayıda yazma/operasyon varsa: disk IO öncelikli olur.
• Query plan (uygun index yoksa) CPU ve disk ikisini birlikte zorlar: bu durumda “sadece spec” değil, query/index iyileştirmesi gerekir.

Dosya yükleme/işleme için karar kuralı

• Geçici dosyalar sık oluşuyorsa disk latency ve throughput öne çıkar.
• Görsel/video dönüştürme yapılıyorsa CPU kritikleşir.
• Aynı anda yüksek trafik alıyorsan RAM de önem kazanır çünkü eşzamanlı worker sayısı arttıkça çalışma seti büyür.

Ölçüm ve test: Tahmin yerine net veri

Spec karşılaştırmasını “tahmin” değil “ölçüm”e bağlamak için kısa bir kontrol listesi veriyorum. (Bu adımlar sağlayıcının ölçüm değerlerini anlamayı da sağlar.)

1) A/B testi gibi düşün

• En az iki konfigürasyon hazırlayıp aynı iş yükünü uygula.
• Konfigürasyon değişimini tek boyutta yap: önce RAM, sonra vCPU, sonra disk.
• Değişkenleri sabit tut: aynı kullanıcı senaryosu, aynı istek dağılımı, aynı süre.

2) İzlenecek metrikler

• Uygulama: ortalama yanıt süresi, p95/p99, hata oranı
• Sistem: CPU kullanımı, run queue/worker bekleme, swap kullanımı
• Depolama: IO wait (disk bekleme), disk throughput/latency
• Veritabanı (varsa): slow query sayısı, buffer cache hit oranı (mümkünse), lock beklemeleri

3) Sonuçları nasıl yorumla?

• p95/p99 artıyor + swap artıyor → RAM yetersizliği.
• p95/p99 artıyor + CPU yüksek → CPU yetersizliği.
• p95/p99 artıyor + CPU/RAM “normal” kalıyor + IO wait artıyorsa → Disk/IO yetersizliği.

Sonuç: Aksiyon planı ile karar ver

RAM, CPU ve disk arasında “tek doğru” yok; doğru seçim senaryoya bağlıdır. En pratik yöntem şudur: önce iş yükünü sınıflandır (hesaplama-bound mı, bellek-bound mı, IO-bound mu), sonra aynı trafik altında p95/p99 ve swap/IO wait verilerine göre ilk darboğazı belirle. NetKıyas’ta konfigürasyon karşılaştırırken de her paketi tek bir sayıya göre değil, RAM + vCPU + disk türü/IO üçlüsüyle birlikte değerlendir. Eğer hedefin büyüme ve belirsizlik ise, ölçüm yapacağın iki adımlı bir test planı hazırlayıp (RAM/CPU ya da disk/IO), en kısa sürede doğru kaynağa yatırım yap.