VDS İçin Kaç CPU ve Kaç GB RAM Gerekir?

VDS kaç RAM gerekir sorusunu soranların çoğu aslında paket tablosuna bakıp "2 GB yeter mi acaba" diye tahmin yürütüyor. Sorun şu ki tahmin, sunucu ilk gün çalıştığı için doğru görünür; asıl fatura üç hafta sonra trafik biraz artınca, Allowed memory size exhausted hataları başlayınca ya da MySQL çöküp bir daha kalkmayınca gelir. Sunucu boyutlandırma tahminle yapılacak bir iş değil, toplama işlemidir — ve toplamanın kalemlerini kimse yazmadığı için insanlar tahmin etmek zorunda kalıyor.

Bu yazıda tam olarak o toplamayı kuruyoruz. Önce vCPU'nun ne olduğunu ve kaç çekirdeğin gerçekten gerektiğini netleştireceğim; sonra RAM'i katman katman çıkaracağız: işletim sistemi, kontrol paneli, web sunucusu, PHP-FPM worker başına düşen bellek, MySQL InnoDB buffer pool ve önbellek katmanı. Her kalem için sunucunuzda çalıştırıp kendi rakamınızı ölçebileceğiniz komut vereceğim — çünkü "WordPress 512 MB ister" gibi cümlelerin hiçbir karşılığı yok, sizin WordPress'iniz sizin eklentilerinizle ne kadar yiyorsa o kadar ister. Sonunda üç gerçek senaryo için hesaplanmış tablolar ve swap'ın ne zaman dost ne zaman düşman olduğu var.

vCPU Nedir ve Kaç Çekirdek Gerçekten Gerekir#

vCPU, fiziksel sunucudaki bir CPU çekirdeğinin (çoğu zaman bir hyper-thread mantıksal çekirdeğinin) sanallaştırma katmanı üzerinden size tahsis edilmiş halidir. Yani 4 vCPU, size 4 mantıksal iş parçacığı kadar zamanlama hakkı verir.

Buradaki en kritik ayrım şudur: web trafiği CPU değil, çoğunlukla bellek ve disk problemi yaratır. Bir WordPress sayfası isteğini karşılamak milisaniyeler süren bir PHP çalışmasıdır; sunucunun asıl darboğazı aynı anda kaç PHP işlemi tutabildiğidir, bunları ne kadar hızlı çalıştırdığı değil. Bu yüzden "2 vCPU / 8 GB" bir web sunucusu için genelde "8 vCPU / 2 GB"den çok daha iyi bir tercihtir.

CPU'nun gerçekten belirleyici olduğu işler ayrıdır:

• Görsel işleme, video dönüştürme, PDF üretimi
• Yoğun cron işleri, veri içe/dışa aktarma
• Derleme (build) süreçleri, Node.js SSR uygulamaları
• Şifreleme yükü çok yüksek TLS sonlandırma
• Oyun sunucuları — bunların çoğu tek çekirdek hızına duyarlıdır, çekirdek sayısına değil; ayrıntısı oyun sunucusu için hangi VDS yazısında
• Model eğitimi/çıkarımı — bunlar zaten CPU değil GPU işidir, GPU sunucu kiralama rehberi bu ayrımı açıyor

Pratik kural olarak: tek bir WordPress/kurumsal site için 2 vCPU başlangıç noktasıdır. Birden fazla siteyi barındıracaksanız ya da WooCommerce çalıştıracaksanız 4 vCPU rahatlatır. 8 ve üzeri vCPU'yu, CPU'nun gerçekten doyduğunu ölçmeden almayın — çünkü boşta duran çekirdek size hiçbir performans kazandırmaz, o parayı RAM'e çevirmek her zaman daha iyi sonuç verir.

CPU'nuzun doyup doymadığını ölçmenin en dürüst yolu yük ortalamasını çekirdek sayısına bölmektir:

nproc
uptime
cat /proc/pressure/cpu

uptime çıktısındaki 15 dakikalık yük ortalaması, nproc değerinin sürekli üzerindeyse CPU gerçekten yetmiyor demektir. /proc/pressure/cpu satırındaki some avg60 değeri yüzde 10'un üstünde seyrediyorsa süreçler CPU beklemek zorunda kalıyordur.

RAM Hesabını Katman Katman Kurmak#

RAM ihtiyacı tek bir sayı değil, altı kalemin toplamıdır:

Toplam RAM = İşletim sistemi
           + Kontrol paneli ve servisleri
           + Web sunucusu (Nginx/Apache/LiteSpeed)
           + PHP-FPM (worker sayısı × worker başına bellek)
           + Veritabanı (buffer pool + bağlantı başına bellek)
           + Önbellek katmanı (Redis/Memcached)
           + %20-25 emniyet payı

Emniyet payı süs değil; sayfa önbelleği (page cache) için boş bellek kalmazsa disk okuması artar ve sunucu ölçülebilir biçimde yavaşlar. RAM'i son bayta kadar doldurmayı hedeflemeyin.

Şimdi kalemleri tek tek ölçelim.

PHP-FPM Worker Başına Ne Kadar Bellek Düşer#

PHP-FPM belleğinin tamamı pm.max_children × ortalama worker boyutu çarpımından gelir. Bu iki değerden ilkini siz yazarsınız, ikincisini uygulamanız belirler — ve ikincisini ölçmeden ilkini yazmak, sunucunun OOM ile ölmesinin bir numaralı sebebidir.

Çalışan worker'ların gerçek boyutunu şöyle ölçün:

ps --no-headers -o rss,cmd -C php-fpm8.2 \
  | awk '{sum+=$1; n++} END {printf "adet: %d  ortalama: %.0f MB  toplam: %.0f MB\n", n, sum/n/1024, sum/1024}'

Sürüm adınız farklıysa -C php-fpm ya da -C php-fpm8.3 deneyin. Sahadan gördüğüm tipik aralıklar şöyle:

Bunlar sizin ölçümünüzün yerine geçmez, sadece beklenen büyüklük sırasını verir. Kendi rakamınızı aldıktan sonra max_children şöyle hesaplanır:

pm.max_children = (PHP'ye ayırabildiğiniz RAM) / (ortalama worker RSS)

Örnek: 8 GB'lık sunucuda işletim sistemi, MySQL ve Nginx'e 3,5 GB ayırdıktan sonra PHP'ye 3 GB kaldıysa ve worker ortalaması 90 MB ise:

3072 / 90 ≈ 34  →  pm.max_children = 30 (emniyetli aşağı yuvarlama)

Havuz dosyanızda (/etc/php/8.2/fpm/pool.d/www.conf) karşılığı:

pm = dynamic
pm.max_children = 30
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

pm.max_requests satırını atlamayın: bellek sızdıran bir eklenti varsa worker 500 istekten sonra yeniden doğar ve sızıntı birikmez. Havuz ayarlarının tamamı için PHP-FPM pool ayarları ve web sunucusu tarafıyla birlikte kurgusu için Nginx PHP-FPM yapılandırma yazılarına bakın.

⚠️ php.ini içindeki memory_limit ile worker'ın gerçek RSS'i aynı şey değildir. memory_limit = 256M, tek bir isteğin tavanıdır; ortalama worker o tavana genelde yaklaşmaz. Hesabı memory_limit üzerinden yaparsanız sunucuyu gereksiz yere üç kat büyük alırsınız. Tavana çarpma anını ise allowed memory size exhausted hatası yazısında ele aldık.

MySQL InnoDB Buffer Pool Nasıl Boyutlandırılır#

InnoDB buffer pool, veritabanının veri ve indeks sayfalarını bellekte tuttuğu alandır ve MySQL'in tek en önemli ayarıdır. Doğru boyut, veri + indeks toplam boyutunuzun biraz üzerinde olandır — sunucu RAM'inin sabit bir yüzdesi değil.

Önce gerçek veri boyutunuzu ölçün:

SELECT
  ROUND(SUM(data_length + index_length) / 1024 / 1024, 0) AS toplam_mb
FROM information_schema.tables
WHERE engine = 'InnoDB';

Diyelim çıktı 900 MB. O zaman buffer pool'u 1 GB yapmak yeterlidir; 4 GB yapmak boş yere bellek bağlamaktır. Tersi durumda veri 12 GB ve sunucunuz 4 GB ise, buffer pool'u büyütemezsiniz — bu, sunucuyu büyütmeniz gerektiğinin işaretidir.

Ayar /etc/mysql/mysql.conf.d/mysqld.cnf içinde:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 1
innodb_log_file_size = 256M
max_connections = 60
table_open_cache = 2000

Buffer pool'un yeterli olup olmadığını yine ölçebilirsiniz:

SHOW ENGINE INNODB STATUS\G

Çıktıdaki Buffer pool hit rate satırı 1000/1000'e yakın olmalı. 950'nin altına düşüyorsa disk okuması yapıyorsunuz demektir.

max_connections değerini de rastgele büyütmeyin: her bağlantı kendi sıralama ve birleştirme tamponlarını ayırır, yani bağlantı sayısı bellek maliyetidir. max_connections değerini PHP pm.max_children değerinizin biraz üzerinde tutun; PHP'nin açabileceğinden fazla bağlantıya ihtiyacınız yoktur. Bu ilişkiyi ihmal etmek MySQL too many connections hatası ile sonuçlanır. Genel MySQL ayarları için MySQL/MariaDB performans optimizasyonu yazısına bakın.

Kaba bir başlangıç noktası olarak MySQL'in toplam bellek tüketimi:

MySQL RAM ≈ buffer_pool + (max_connections × ~4-8 MB) + ~200 MB temel

Kontrol Panelinin Kendi Tüketimi Hesaba Katılmalı#

Kontrol paneli kurmak, sunucunuzun bir bölümünü baştan kiraya vermek gibidir. Bu kalem neredeyse hiç yazılmaz ama boyutlandırmayı en çok o bozar.

Yani cPanel kurulu 2 GB'lık bir VDS'te, siteniz daha bir istek almadan belleğin yarısından fazlası tükenmiş olur. Bu yüzden panelli kurulumlarda 4 GB pratik taban, konforlu çalışma için 8 GB'dır. Kaynağı verimli kullanmak öncelikliyse panelsiz gidin ve yönetimi otomasyona bırakın — Ansible ile sunucu otomasyonu tam olarak bunu çözer.

Panelin ClamAV tarama servisi çoğu küçük sunucuda gereğinden ağırdır; kapatmak ya da tarama saatini gece yapmak tek başına yüzlerce megabayt geri kazandırır.

Üç Gerçek Senaryo İçin Hesaplanmış Boyutlandırma#

Aşağıdaki tablolar yukarıdaki formülün üç tipik durum için işletilmiş halidir. Rakamlar tavan değil, hesabın nasıl yürüdüğünü gösteren örneklerdir.

Senaryo 1 — Tek WordPress sitesi, panelsiz, günlük birkaç bin ziyaret

Senaryo 2 — cPanel'li sunucu, 5-10 küçük site

Senaryo 3 — WooCommerce mağazası, kampanya trafiği alan

Üçüncü senaryoda PHP worker sayısının düşük ama worker boyutunun yüksek olduğuna dikkat edin: WooCommerce'te sepet ve ödeme istekleri önbelleklenemez, her biri gerçek PHP çalışması ve gerçek bellek demektir. Mağazanızın önbellekleme stratejisi doğrudan RAM ihtiyacınızı belirler; WooCommerce performans yazısı bu tarafı açıyor.

Swap Ne Zaman Gerekir Ne Zaman Zarar Verir#

Swap, RAM'in yedeği değildir; RAM biterse sunucunun çökmek yerine yavaşlamasını sağlayan bir emniyet supabıdır. Doğru kullanımı budur.

Kural şudur:

• Swap açık olsun, ama RAM'in eksiğini kapatmak için değil, ani tepe anlarında OOM Killer'ın MySQL'i öldürmesini engellemek için. Kapasitesi 1–2 GB genelde yeterlidir.
• Sürekli swap kullanılıyorsa bu bir ayar sorunu değil, kapasite sorunudur. Sunucu büyütülmelidir.
• swappiness düşürülmelidir. Varsayılan 60, veritabanı çalıştıran sunucular için yüksektir:

sysctl vm.swappiness=10
echo "vm.swappiness=10" >> /etc/sysctl.conf

Swap alanı oluşturmanın adımları swap alanı oluşturma yazısında. Swap'a gerçekten girip girmediğinizi ölçmek için:

free -m
vmstat 1 5

vmstat çıktısındaki si ve so sütunları sürekli sıfırdan farklıysa aktif olarak swap'a yazıp okuyorsunuz demektir — bu, sitenizin yavaşlığının açıklamasıdır.

Disk ve Ağ da Boyutlandırmanın Parçası#

RAM ve CPU'ya odaklanıp diski atlamak yaygın bir hata. Bir veritabanı sunucusunda disk türü, çoğu zaman ek RAM'den daha büyük fark yaratır. NVMe ile SATA SSD arasındaki rastgele okuma farkı, buffer pool'un ıskaladığı her sorguda kendini gösterir.

Disk alanını hesaplarken şunları unutmayın:

1. İşletim sistemi ve paketler: 5–10 GB
2. Yedekler: yedeği aynı diskte tutuyorsanız site boyutunun en az 2 katı
3. Log dosyaları: dönüşümlü (logrotate) tutulmuyorsa aylar içinde onlarca GB
4. MySQL binlog ve ibdata dosyaları
5. Mail kutuları (panelli sunucularda en hızlı büyüyen kalem)

Disk doluluğunu izlemeyi unutmak, sunucuyu RAM yetmezliğinden daha sık kilitleyen sebeptir:

df -h
du -sh /var/log/* | sort -h | tail -10

İzleme tarafını kurmak isterseniz Netdata ile sunucu izleme ve süreç bazlı bakış için ps, top, htop ile süreç izleme yazıları işinizi görür.

Kaynak Yetmediğini Nasıl Anlarsınız#

Sunucu "yavaşladı" demek yetersiz bir teşhistir. Hangi kaynağın bittiğini belirtilerden ayırt edebilirsiniz:

OOM Killer'ın gerçekten devreye girip girmediğini şöyle doğrularsınız:

dmesg -T | grep -i -E "out of memory|killed process"
journalctl -k --since "3 days ago" | grep -i oom

Killed process 1234 (mysqld) satırını görüyorsanız tartışma bitmiştir: RAM yetmiyor. Bu satır olmadan "RAM az galiba" demek tahmindir.

Paylaşımlı hostingten geliyorsanız ve orada 508 resource limit is reached hatası alıyorsanız, aslında zaten bu hesabı yapmanız gereken noktadasınız — o hata paketin CPU/bellek/işlem limitine dayandığınızı söyler. Paylaşımlı ile VDS arasındaki mimari farkı shared vs VPS hosting yazısı karşılaştırıyor.

Sıkça Sorulan Sorular#

WordPress için kaç GB RAM yeterli#

Sade bir WordPress sitesi için panelsiz kurulumda 2 GB çalışır, rahat çalışması için 4 GB önerilir. Belirleyici olan ziyaretçi sayısı değil, aynı anda kaç PHP isteğinin işlendiğidir; sayfa önbelleği kullanan bir site aynı trafiği çok daha az bellekle karşılar. Eklenti sayısı arttıkça worker başına düşen bellek de arttığı için hesabı kendi sunucunuzda ölçtüğünüz worker boyutuyla yapmalısınız. cPanel gibi bir panel kuracaksanız tabanı doğrudan 4 GB'a çekin.

2 vCPU bir site için yeterli mi#

Evet, tek bir WordPress veya kurumsal site için 2 vCPU çoğu durumda yeterlidir. Web istekleri kısa süreli CPU tüketir, asıl sınır belleğe ve eşzamanlı işlem sayısına takılır. CPU'yu artırmanız gereken durumlar görsel/video işleme, ağır cron görevleri, derleme süreçleri ve eşzamanlı kullanıcı sayısı yüksek uygulamalardır. Yük ortalamanız çekirdek sayınızın sürekli üstünde değilse CPU'ya para vermek yerine RAM'e yatırım yapın.

vCPU ile fiziksel çekirdek arasındaki fark nedir#

vCPU, sanallaştırma katmanının size tahsis ettiği mantıksal işlemci birimidir ve genelde fiziksel çekirdeğin bir hyper-thread'ine karşılık gelir. Fiziksel çekirdek tüm önbelleğe ve işlem hattına tek başına sahipken, iki hyper-thread aynı fiziksel çekirdeği paylaşır. Bu yüzden 4 vCPU, 4 fiziksel çekirdek kadar iş yapmaz; aradaki fark iş yüküne göre değişir. Tek çekirdek hızının önemli olduğu işlerde (bazı oyun sunucuları, tek iş parçacıklı hesaplamalar) bu ayrım belirleyici hale gelir.

pm.max_children değerini nasıl belirlemeliyim#

PHP'ye ayırabildiğiniz belleği ortalama worker boyutuna bölerek belirlersiniz. Önce ps --no-headers -o rss -C php-fpm çıktısıyla gerçek worker boyutunuzu ölçün, ardından toplam RAM'den işletim sistemi, veritabanı ve web sunucusu payını düşün. Çıkan sayıyı aşağı yuvarlayın; tavana yakın ayarlamak, tepe trafikte OOM riskini doğurur. Bu değeri php.ini içindeki memory_limit üzerinden hesaplamak yaygın ama yanlış bir yöntemdir, çünkü memory_limit ortalama değil tavan değeridir.

InnoDB buffer pool RAM'in yüzde kaçı olmalı#

Sabit bir yüzde yerine veri ve indeks toplamınızın biraz üzerinde olmalıdır. information_schema.tables üzerinden veri boyutunuzu ölçün; 900 MB veriniz varsa 1 GB buffer pool yeterlidir ve fazlası boşa bağlanmış bellektir. "RAM'in yüzde 70'i" tavsiyesi yalnızca sunucu sadece veritabanı çalıştırıyorsa anlamlıdır; web ve PHP aynı makinedeyse bu oran sunucuyu OOM'a sürükler. Yeterli olup olmadığını SHOW ENGINE INNODB STATUS çıktısındaki buffer pool isabet oranıyla doğrulayın.

Swap açmak sunucuyu yavaşlatır mı#

Swap'ın kendisi yavaşlatmaz, swap'a düşülmesi yavaşlatır. Boşta duran bir swap alanı sunucuya hiçbir maliyet getirmez ve ani bellek tepelerinde OOM Killer'ın veritabanınızı öldürmesini engeller. Sorun, sunucunun sürekli swap kullanmaya başlamasıdır; bu durumda çözüm swap'ı büyütmek değil RAM'i artırmaktır. vm.swappiness değerini 10 civarına çekmek, çekirdeğin gereksiz yere swap'a yazmasını azaltır.

Sunucumu sonradan büyütebilir miyim#

Çoğu VDS altyapısında CPU ve RAM sonradan artırılabilir, bu işlem genelde kısa bir yeniden başlatma gerektirir. Disk büyütmesi de mümkündür ancak küçültme genelde desteklenmez, bu yüzden diski gereğinden çok büyük almak yerine ihtiyaca yakın alıp gerektiğinde büyütmek daha mantıklıdır. Büyütme öncesi mevcut darboğazınızı ölçmeniz önemlidir; yanlış kaynağı artırmak sorunu çözmez. Yükseltme sonrası PHP-FPM ve MySQL ayarlarınızı yeni belleğe göre yeniden hesaplamayı unutmayın.

Kontrol paneli kurmasam ne kadar kaynak kazanırım#

Panelsiz bir kurulumla tipik olarak 1–2 GB RAM ve belirgin miktarda CPU zamanı kazanırsınız. cPanel gibi tam donanımlı bir panel, arka planda kendi veritabanını, mail servislerini, tarama ve yedekleme görevlerini çalıştırır; bunların hepsi siz hiç sayfa yayınlamadan bellek tüketir. Buna karşılık panelsiz kurulumda e-posta, yedekleme ve DNS yönetimini kendiniz kurmanız gerekir. Küçük bir sunucuda tek site barındıracaksanız panelsiz gitmek, aynı parayla belirgin şekilde daha hızlı bir sistem verir.

Kapanış#

Sunucu boyutlandırmanın tamamı tek bir alışkanlığa dayanıyor: tahmin etmek yerine ölçmek. Worker boyutunuzu ps ile, veri boyutunuzu information_schema ile, gerçek darboğazınızı vmstat ve dmesg ile öğrenebiliyorsanız kaç GB RAM ve kaç vCPU gerektiğini de hesaplayabilirsiniz. Formülün kalemleri hep aynı: işletim sistemi, panel, web sunucusu, PHP-FPM worker'ları, veritabanı buffer pool'u, önbellek ve emniyet payı. Bu kalemleri yazmadan alınan her sunucu ya gereğinden büyük olur ve boşa para gider, ya da gereğinden küçük olur ve üç hafta sonra 502 hatalarıyla döner.

Hesabınızı yaptıktan sonra paketi seçme sırası gelir. Tek site ya da orta ölçekli bir proje için VDS sunucu paketleri çoğu ihtiyacı karşılar; kaynak ihtiyacınız dalgalıysa ve büyümeyi kolay yönetmek istiyorsanız bulut sunucu tarafı daha esnek davranır. Yüksek eşzamanlılık ve garantili CPU gerektiren iş yükleri için performans sunucuları daha uygun bir başlangıçtır. Sunucuyu kurup ayarlarını sizin adınıza yapacak birini istiyorsanız sunucu yönetimi hizmetimize de göz atabilirsiniz; PHP-FPM ve MySQL ayarlarının doğru kurulması, çoğu zaman bir kat büyük sunucu almaktan daha çok fark yaratıyor.