Sunucu Spec’lerinde RAM mi CPU mu Disk mi? Net Öncelik Rehberi

Sunucu alırken ya da mevcut altyapıyı yükseltirken spec’ler (RAM, CPU, disk) arasında “hangisi daha önemli?” sorusu kaçınılmazdır. Bu yazıda, gerçek arıza senaryolarını ve ölçülebilir darboğazları baz alarak RAM–CPU–disk önceliğini net biçimde nasıl belirleyeceğinizi öğreneceksiniz. Ayrıca, tipik uygulamalar için (web, veritabanı, önbellek, içerik sunumu) hangi kaynağın önce tükendiğini ve hangi göstergelerle tespit edeceğinizi adım adım uygulayacaksınız.

1) Önce “darboğaz”ı tanımlayın: RAM, CPU, disk neyi sınırlar?

Bir sunucuda performans düşüşü çoğu zaman tek bir kaynağın tükenmesiyle başlar. Ancak RAM, CPU ve disk farklı türde kısıtlar üretir:

• RAM (işlem belleği): Aynı anda çalışan süreçlerin tutabileceği veri miktarını belirler. RAM azaldığında sistem swap’a (disk belleği) düşer.
• CPU: İstekleri işleyen kodun hesaplama kapasitesini belirler. CPU azaldığında süreçler bekler, işlem süresi uzar.
• Disk: Özellikle I/O (Input/Output) performansını ve depolama gecikmesini belirler. Disk yavaşsa hem veritabanı hem de dosya işlemleri tıkanır.

Önemli ayrım: RAM ve CPU genelde “iş yükü” ile ilişkilidir. Disk ise çoğu zaman “I/O deseni” (okuma/yazma sıklığı, rastgele vs ardışık erişim, log/temporary dosya trafiği) ile ilişkilidir. Bu yüzden yanlış kaynağa yükseltme yapmak gereksiz maliyete yol açar.

2) RAM ne zaman kritik olur? Swap sinyallerini okuyun

RAM’in kritik hale gelmesi, çoğu kurulumda şu zincirle görünür: RAM azalır → swap’a düşülür → disk I/O artar → gecikme büyür. Bu tablo “CPU az” sanılan pek çok senaryoda aslında RAM kaynaklı I/O şişmesidir.

RAM darboğazı için net belirtiler

Aşağıdaki gözlemler RAM’in kritik olma olasılığını yükseltir:

• Sistem metriklerinde swap kullanımı (swap in/out) düzenli yükselir.
• Uygulama gecikmesi, CPU kullanımına göre orantısız biçimde artar.
• Veritabanı veya uygulama loglarında “temporary”, “paging”, “out of memory” benzeri uyarılar görülür.
• Yük yükselirken değil, yük sabitken bile yavaşlama artar (çoğu zaman cache ve süreç belleği yetmemesiyle ilişkilidir).

Pratik kontrol: Hangi yüzde daha anlamlı?

CPU/RAM/disk yüzde kullanımına tek başına bakmak yanıltıcıdır. Yine de pratikte şu yaklaşım işe yarar:

• RAM için: Swap’a düşme başlamışsa RAM tarafı önceliklidir.
• CPU için: CPU tek çekirdekte sıkışıyorsa CPU önceliklidir.
• Disk için: Özellikle I/O wait (Linux’ta iowait) yükseliyorsa disk önceliklidir.

Ölçmek için en azından temel metrikleri izleyin:

• CPU: iowait oranı, load average
• RAM: swap kullanımı
• Disk: IOPS, latency (örn. “await”/“svctm” benzeri), kuyruk derinliği

3) CPU ne zaman kritik olur? Hesaplama mı bekleme mi?

CPU kritik olduğunda genelde “işleme süreleri” büyür. Bu durum web uygulamalarında sık görülür: aşırı eşzamanlı istekler, yanlış boyutlandırılmış iş parçaları, ağır şifreleme, büyük sayfa render’ı veya veritabanı sorgularının CPU tüketmesi.

CPU darboğazı için net belirtiler

• CPU kullanımı uzun süre yüksek seyreder (ör. iş günlerinde sürekli yüksek kullanım).
• İşlem süresi (p95/p99 latency) CPU yükselişiyle paralel artar.
• Uygulama katmanında (PHP-FPM, Node.js, Java) worker sayıları ve kuyruklar tıkanır.
• Veritabanı sorguları “slow query” olarak CPU tüketen pattern’lerde yoğunlaşır.

CPU’da en sık yapılan hata: “Toplam CPU”ya bakmak

Toplam CPU yüzde 40 iken bile bazı çekirdekler yüzde 100’e yakın sıkışabilir. Bu yüzden:

• Tek çekirdek/çekirdek grubu bazında ölçüm yapın.
• Uygulama ayarları (worker/process sayıları) CPU çekirdeği sayısıyla uyumlu olsun.

Sunucu tarafında net sinyal

CPU tıkanması çoğu zaman şu düzende görünür: istek kuyruğu uzar, yanıt süreleri artar, fakat disk latency patlamaz. Disk neredeyse sabitse CPU yükseltmek doğru hamle olma ihtimalini artırır.

4) Disk ne zaman kritik olur? I/O gecikmesi çoğu “hız” iddiasını ezer

Disk tarafı özellikle veritabanı, cache katmanı dışı dinamik içerik, log ve temporary dosya kullanımı olan sistemlerde belirleyicidir.

Disk darboğazı için net belirtiler

• Uygulama CPU’su ve RAM’i makulken yanıt süresi ciddi yükselir.
• I/O wait belirgin artar.
• Veritabanı işlemleri (SELECT/INSERT/UPDATE) yavaşlar; “checkpoint”, “flush”, “temporary file” gibi izler görünür.
• Log dosyaları yoğun yazım yapar, journald/rotasyon gecikmeleri oluşur.

SSD mi NVMe mi? “Disk türü” kadar “performans profili” önemli

Aynı “SSD” ifadesi altında bile farklı sürücüler ciddi performans farkı yaratır. VDS/VPS tarafında iki şeyi özellikle kontrol edin:

• NVMe (varsa) kullanımı: Genelde IOPS/latency avantajı sağlar.
• Disk tipi ve garanti: “Burst” veya paylaşımlı IOPS varsa yüksek trafik dönemlerinde dalgalanma görürsünüz.

5) İhtiyaca göre net öncelik: Hangi iş yükü hangi kaynağı önce zorlar?

Aşağıdaki tablo karar verirken işinizi hızlandırır. Buradaki öncelik sırası, tipik davranışlara göredir.

Kısa karar kuralı (en pratik yaklaşım)

• Swap başlıyorsa: RAM’i önce düzeltin.
• iowait yükseliyorsa: disk/IO profilini önce düzeltin.
• CPU tek çekirdekte sıkışıyorsa: CPU çekirdek/worker planlamasını önce düzeltin.

6) RAM/CPU/Disk oranını doğru kurun: Ölçekleme planı ve eşik örnekleri

Tek bir “sihirli oran” yok; ancak iyi bir yükseltme planı, ölçülen semptomla uyumlu olmalıdır. Aşağıdaki yaklaşım, gereksiz art arda yükseltmenin önüne geçer.

6.1 Ölçümle başla: 15 dakikalık periyotta gözlem

Yükseltmeye karar vermeden önce 3 sinyali aynı zaman aralığında görün: - Swap: var/yok ve ne kadar - iowait: düşük/yüksek - CPU: tek çekirdek mi yoksa genel mi

Bu üçlü kombinasyon, “hangi kaynak ilk düzeltilmeli?” sorusunu çoğu vakada net yanıtlar.

6.2 Uygulama katmanı ayarlarını da hesaba kat

RAM/CPU yükseltmek tek çözüm değildir; yanlış ayarlar kaynak israfı yaratır:

• Web uygulaması için worker sayıları (ör. PHP-FPM pool) CPU çekirdeklerine göre ayarlanmalıdır.
• Veritabanında bağlantı sayısı ve sorgu planı kontrol edilmelidir.
• Cache stratejisi (sunucu önbelleği, CDN, uygulama cache) disk ve CPU üzerindeki yükü düşürür.

6.3 Yükseltme sırası: önce en düşük maliyetli kazanım

Genelde şu sıra daha verimli olur:

1) Konfigürasyon + caching + sorgu optimizasyonu (çoğu zaman ücretsiz) 2) CPU/worker ayarı ve limitler 3) RAM artışı (swap kapatacak şekilde) 4) Disk I/O profili (NVMe/IOPS iyileştirme)

Özellikle disk tarafında hamle yapmak maliyetli olabilir; bu yüzden iowait ve I/O bekleme sinyali netleşmeden disk yükseltmek yerine önce RAM swap ve CPU worker uyumuna bakın.

7) Net örneklerle “hangisi daha kritik?” kararını simüle edelim

Örnek A: Web site yükte yavaşlıyor, CPU %35, swap var

• Swap yükseliyor.
• CPU toplamı orta.
• Sonuç: Öncelik RAM. Swap kapatılmadan disk I/O yükü artar, gecikme düşmez.

Örnek B: Veritabanı sorguları yavaş, iowait yüksek, CPU orta

• iowait belirgin.
• CPU tek başına suçlu değil.
• Sonuç: Öncelik disk I/O profili ve veritabanı buffer/indeks stratejisi.

Örnek C: Worker kuyrukları uzuyor, CPU bazı çekirdeklerde uzun süre yüksek

• CPU çekirdek bazında tıkanma var.
• iowait düşük/orta.
• Sonuç: Öncelik CPU (çekirdek ve worker sayısı/iş bölümü).

Sonuç: Aksiyon planı (hedefi netleştirerek yükselt)

“RAM mi CPU mu disk mi?” sorusuna doğru cevap, rastgele yükseltme değil; swap, iowait, çekirdek bazlı CPU gibi net sinyalleri okumaktır. İlk adım olarak 15-30 dakikalık bir gözlem yapın: swap var mı, iowait nasıl, CPU hangi çekirdekte sıkışıyor? Bu verilerle yükseltme sırasını belirleyin: swap varsa RAM, iowait yüksekse disk/IO, çekirdek bazında CPU sıkışması varsa CPU ve worker planlaması. Bu yaklaşımı uygularsanız bütçenizi en etkili kaynağa yönlendirir, performans artışını ölçülebilir biçimde elde edersiniz.