Sunucu spec’lerinde RAM mı CPU mu disk mi? Net öncelik rehberi

Sunucu spec’lerinde RAM, CPU ve disk (özellikle depolama ve IOPS) birlikte anılır; ancak üçü de her iş yükünde eşit kritik değildir. Yanlış öncelik seçimi, aynı bant genişliği ve aynı internet kalitesinde bile performans düşüşü ve maliyet artışı yaratır. Bu rehberde, hangi senaryoda RAM, hangi senaryoda CPU, hangi senaryoda disk/IOPS daha belirleyicidir; bunu ölçümlerle nasıl doğrulayacağınızı net biçimde anlatıyorum.

1) Önce iş yükünü ayır: RAM, CPU, disk farklı sorunları temsil eder

Sunucu performansını belirleyen kaynaklar, uygulamanın yaptığı işe göre değişir. Bu yüzden “hangisi daha önemli?” sorusunun tek cevabı yoktur; ama doğru sınıflandırma ile net karar verilir.

İş yükü türleri

• RAM ağırlıklı: Büyük sayıda eş zamanlı bağlantı, caching ihtiyacı, uygulama belleğinde veri tutma (ör. uygulama cache’i, session, in-memory işlemler).
• CPU ağırlıklı: Şifreleme, sıkı döngüler, görsel/dönüşüm işleri, sıkıştırma, ağır template/render, bazı oyun sunucuları.
• Disk/IOPS ağırlıklı: Veritabanı yazma oranı yüksek sistemler, küçük rastgele okuma/yazma (random I/O), log yoğun uygulamalar, yoğun arama indeksleme.

Pratik kural: Aynı anda çok sayıda kullanıcı istek atıyorsa RAM/Concurrency kritikleşir. İstek başına “iş” (hesap) artıyorsa CPU öne çıkar. Aynı istek çok sık veritabanı okuma/yazma yapıyorsa disk/IOPS belirleyici olur.

2) Karar tablosu: RAM mı CPU mu disk mi? Yük türüne göre net seçim

Aşağıdaki tablo, en yaygın iş yükleri için hızlı yön bulma sağlar. Buradaki hedef, “önceliklendirme” yapmaktır: Genelde üçünün hepsi optimum olmalı; ama biri genellikle darboğazdır.

Ne zaman “disk” bir numara olur?

Disk/IOPS; özellikle veritabanında random I/O arttığında dramatik şekilde darboğaz olur. Örneğin: - Çok sayıda küçük sorgu - Yüksek bağlantı sayısı ile sık gelen SELECT/UPDATE - Cache hit oranının düşük olduğu durumlar

3) Ölçümlerle doğrula: RAM/CPU/disk hangisi darboğaz?

Tek başına “spec’e bakınca” doğru karar çıkmayabilir. Doğru yaklaşım, mevcut sistemi ölçüp darboğaz kaynağını bulmaktır. Aşağıdaki göstergeler, sorunun kaynağını anlamaya yardım eder.

RAM darboğazı nasıl anlaşılır?

• Uygulama süreçleri büyüyor, swap kullanımı başlıyor.
• OOM (Out of Memory) benzeri olaylar görülüyor.
• Yük artınca gecikme artışı orantısız yükseliyor (memory pressure).

Kontrol: - free -m çıktısında available ve swap davranışı - Uygulama log’larında bellek aşımı uyarıları - (Docker kullanıyorsanız) container limit ve OOMKilled olayları

CPU darboğazı nasıl anlaşılır?

• CPU kullanımı uzun süre %80-100 aralığında kalıyor.
• “iğne gibi” kısa sürede değil, kalıcı yüksek CPU ile yanıt gecikiyor.
• Tek çekirdekte darboğaz varsa toplam CPU yetse bile performans düşebilir.

Kontrol: - top veya htop ile süreç bazında CPU - Uygulama endpoint’lerinde sürelerin CPU ile paralel yükselmesi

Disk/IOPS darboğazı nasıl anlaşılır?

• Uygulama beklemede kalıyor ama CPU/RAM normal aralıkta.
• Veritabanı sorguları yavaş, “slow query” sayısı artıyor.
• Disk latency yükseliyor; kuyruk (queue) büyüyor.

Kontrol: - Veritabanında slow query log - Linux’ta disk latency/await değerleri (örn. iostat ile) - Uygulama seviyesinde timeout’ların disk ile korelasyonu

4) Senaryo bazlı net öneriler: Doğru kaynağı öne al

Şimdi kararın pratiğe döküldüğü yer: “Bu tür sistemde ilk artırmam gereken hangisi?”

Web uygulamaları (PHP/WordPress gibi)

WordPress tarafında çoğu sorun iki başlıkta toplanır: veritabanı ve sayfa üretimi.

1) DB sorguları yavaşsa: öncelik disk/IOPS ve RAM cache ayarlarıdır. - Disk/IOPS düşükse küçük sorgular bile birikir. - RAM yetersizse DB cache/innodb buffer ihtiyacı karşılanamaz.

2) DB değil de PHP hesap süresi yüksekse: öncelik CPU’dur. - Ağır eklentiler, karmaşık sorgular, template/render yükü CPU’yu zorlar.

3) Cache yoksa: RAM/disk etkisi birlikte büyür. - Uygulama cache’i kurulmuyorsa, aynı içerik her istekte üretilir; bu hem CPU hem disk baskılar.

API ve eşzamanlı uygulamalar (Node.js, Go, Java)

Eşzamanlılık arttıkça RAM daha kritik hale gelir. - Her istek; request body, header parsing, worker/state gibi bellek harcar. - Worker sayısı yüksekse RAM tüketimi hızlı büyür.

Net yaklaşım: - Önce concurrency/worker limitlerini belirleyin. - Sonra RAM’i, “eş zamanlı kullanıcı tepe noktasında swap olmadan” çalışacak şekilde konumlandırın.

Veritabanı sunucuları (MySQL/PostgreSQL)

Veritabanında üç kaynak da rol oynar ama darboğaz sıklıkla disk IOPS/latency olur. - Yazma (INSERT/UPDATE) yüksekse disk commit performansı kritiktir. - Çok sayıda bağlantı ile rastgele okuma varsa random I/O gecikmesi büyür.

Öneri sıralaması (genel): 1. Slow query log ile en yavaş sorguları bulun. 2. Sorgular iyileştirilmiyorsa diski (IOPS/latency) artırma gündeme gelir. 3. Buffer/cache ihtiyacı için RAM’i artırın. 4. CPU’yu da paralel sorgu/konumlandırma nedeniyle kontrol edin.

5) VDS/VPS spec satın alırken pratik kontrol listesi

Net sonuç almak için yalnızca RAM ve CPU sayısına bakmayın; disk alt kırılımlarını (IOPS/latency, SSD/NVMe, throttling) ve bant genişliği/paket limitlerini de değerlendirin.

Satın alma kontrol listesi

• Disk türü: SSD mi NVMe mi? “IOPS garanti” var mı?
• IOPS/latency: Rastgele I/O için metrik paylaşılıyor mu?
• CPU modeli ve çekirdek: VM üzerinde throttling var mı?
• RAM yeterliliği: Swap olmadan çalışacak mı?
• Network: Paket kaybı/latency yüksekse uygulama sanki CPU/disk sorunu yaşıyormuş gibi görünebilir.
• Yedekleme (backup): Disk darboğazını artırmadan çalışan otomatik yedekleme stratejisi var mı?

Minimum hedef yaklaşımı

Genel bir hedef koymak gerekirse: - Eşzamanlı kullanıcı beklenen web/API sistemlerinde RAM, “swap’siz çalışma” koşulunu sağlamalıdır. - CPU yoğun dönüşüm ve hesap işlerinde CPU, tek çekirdekte de yeterli olmalıdır. - Veritabanında disk/IOPS düşükse optimizasyonla bile darboğaz kalabilir; bu durumda depolama performansı kritikleşir.

Net gerçek: Disk/IOPS yetersizse, CPU ve RAM artışı gecikmeyi tam çözemeyebilir. Benzer şekilde RAM yetersizse CPU yükseltmek de fayda sağlamaz; çünkü sistem bellek baskısında bekler/çökebilir.

Sonuç: Aksiyon planı—önce ölç, sonra kaynağı sırala

Karar sürecini tek cümleye indirgersen: İlk önce darboğaz kaynağını ölçün (RAM/CPU/disk), sonra spec artışını tek bir eksene yığmadan öncelik sırası ile ilerleyin.

Hemen bugün uygulayabileceğiniz net aksiyonlar: 1) Uygulama/DB için slow query ve timeout loglarını kontrol edin. 2) free, top ve disk latency/await benzeri metriklerle RAM/CPU/disk ayrımını yapın. 3) Darboğaz netleşince ilk olarak o kaynağı optimize edin: web tarafında cache/DB, veritabanında IOPS/latency ve buffer, API tarafında concurrency/RAM. 4) Yine de düzelmiyorsa, ikinci sıradaki kaynakla (CPU veya RAM) birlikte denge kurun.

Bu adımlar doğru yapıldığında, RAM mı CPU mu disk mi sorusu “tahmin” olmaktan çıkar ve satın alma/ölçekleme kararına dönüşür.