vCPU nedir? Fiziksel CPU çekirdeğinden farkı net anlatım

vCPU (virtual CPU), VDS/VPS gibi sanal sunucu planlarında kaynak tahsisini tanımlamak için kullanılan bir ölçü birimidir. Ancak vCPU ile fiziksel CPU çekirdeği aynı şey değildir; aradaki fark, performans beklentisini doğrudan etkiler. Bu yazıda vCPU’nun nasıl hesaplandığını, fiziksel çekirdekten farklarını ve özellikle hangi durumda “aynı vCPU sayısı”nın aynı performansa karşılık gelmediğini net şekilde öğreneceksiniz.

vCPU tam olarak neyi ifade eder?

vCPU, bir sanal makineye (VM) tanımlanan mantıksal işlemci birimidir. Hypervisor (ör. KVM, Xen, VMware) fiziksel CPU’yu sanallaştırır ve VM’e belirli sayıda “sanal çekirdek” tahsis eder.

vCPU’nun en önemli özelliği şudur: vCPU sayısı tek başına performansı garanti etmez. Çünkü fiziksel CPU’nun ne kadarının tahsis edildiği, çekirdek/iş parçacığı (thread) paylaşımı, CPU scheduling politikası ve oversubscription (aşırı tahsis) gibi etkenler sonucu değiştirir.

vCPU ile thread mantığı neden karışır?

Modern CPU’lar çoğu zaman aynı fiziksel çekirdek üzerinde birden fazla donanım iş parçacığı (Intel’de Hyper-Threading, AMD’de SMT) çalıştırır. Bazı sağlayıcılar vCPU’yu “thread” üzerinden sayabilir; bazıları ise farklı katmanlarda (topoloji + tahsis) ölçüm yapar. Bu yüzden aynı “4 vCPU” ifadesi, farklı altyapılarda farklı gerçek yürütme kapasitesine karşılık gelebilir.

Fiziksel CPU çekirdeği nedir?

Fiziksel CPU çekirdeği, ana belleğe ve cache hiyerarşisine doğrudan erişen donanım birimidir. Linux’ta lscpu çıktılarında görülen “Core(s) per socket” ve “Socket(s)” gibi değerler fiziksel topolojiyi temsil eder.

Fiziksel çekirdek, bir VM içinde paylaşılabileceği gibi (sanal ortamda) aynı sunucuda birden fazla VM arasında da paylaştırılabilir. Yani fiziksel çekirdek tek başına “her zaman daha iyidir” demek değildir; ancak vCPU, fiziksel çekirdeğin sanallaştırılmış ve paylaştırılmış bir karşılığı olduğu için aradaki fark önemlidir.

vCPU ile fiziksel çekirdek aynı mı? Net cevap: birebir değil

vCPU, fiziksel çekirdeğin “doğrudan” kopyası değildir. Aradaki farkı 3 başlık altında görmek gerekir:

Paylaşım (sharing): Aynı fiziksel çekirdekler birden çok VM tarafından zaman dilimleri halinde kullanılabilir.
Tahsis politikası (scheduling): Hypervisor, VM’lerin CPU zamanını nasıl böleceğine karar verir. Bu karar, yük arttıkça belirginleşir.
Ölçek ve oran (oversubscription): Sağlayıcılar fiziksel kaynakların tamamını sürekli olarak kullanmayacağını varsayarak vCPU’ları daha fazla VM’e dağıtabilir. Bu, yoğun saatlerde gecikmeyi artırabilir.

Aşağıdaki tablo, kavramsal farkı hızlıca görmenizi sağlar:

Kriter	Fiziksel CPU çekirdeği	vCPU
Tanım	Donanım çekirdeği	VM’e tanımlanan sanal işlemci birimi
Paylaşım	Tek sunucuda donanım kaynağı	VM’ler arasında zaman paylaşımı
Garanti	Sunucu sahibi açısından daha doğrudan	Hypervisor + oversubscription etkiler
Performans etkileyenler	Frekans, cache, mimari	Scheduling, throttling, ratio, noisy neighbor
Ölçüm	Host düzeyi	VM düzeyi (quota/CPU limit, burst)

vCPU hesaplaması nasıl yapılır? (sağlayıcıdan sağlayıcıya değişir)

vCPU hesaplaması çoğunlukla “tek bir standart” değildir. Sağlayıcılar kendi sanallaştırma altyapılarına göre vCPU’yu şu yöntemlerle kurgulayabilir:

1) Topolojiye göre (core/thread bazlı) vCPU

Bazı altyapılarda vCPU sayısı fiziksel çekirdek + SMT iş parçacıklarının toplamına dayanabilir. Burada “4 vCPU” bazen 2 fiziksel core + SMT denkliğine, bazen de farklı bir topolojiye karşılık gelir.

2) Oranlı tahsis (ratio-based)

Oversubscription varsa sağlayıcı, örneğin her 1 fiziksel core’a belirli sayıda vCPU tanımlayabilir. Yoğunluk arttığında VM’in bekleme süresi artar.

3) CPU limit ve burst (quota/token bazlı)

Bazı planlarda VM’e bir CPU limiti tanımlanır. Daha iyi performans için burst pencereleri olabilir. Bu durumda vCPU sayısı “sürekli” CPU gücünü değil, burst’e izin verilen bir kapasiteyi anlatabilir.

4) Frequency scaling (boost, turbolar, termal koşullar)

Fiziksel CPU’nun turbo/boost frekansları ve termal davranışı, VM’in efektif performansını etkiler. Sağlayıcılar farklı soğutma ve güç politikaları kullanır. Aynı “vCPU” sayısı farklı frekanslarda farklı çıktılar verir.

Performansı vCPU değil hangi faktörler belirler?

vCPU satın alırken sadece “kaç vCPU?” sorusu yetmez. Özellikle VDS/VPS performansında şu metrikler kritik hale gelir:

CPU mimarisi ve tek çekirdek performansı

Yüksek paralel çalışan işlerde vCPU sayısı önemlidir. Ancak birçok web uygulaması (özellikle PHP/Node.js tek request içinde) tek çekirdek veya sınırlı paralellikte çalışır. Bu durumda CPU’nun mimarisi ve “tek çekirdek benchmark” seviyesi daha belirleyicidir.

Oversubscription ve noisy neighbor etkisi

Aynı fiziksel host üzerinde birden fazla VM yoğun işlem yaparsa diğer VM’ler CPU zamanı bekler. Bunun sonucu “aynı plan” kullanan iki kullanıcının gece performans farkı yaşaması olabilir.

CPU throttling (limit aşımlarında kısma)

Bazı kurulumlarda VM CPU kullanımını limit aşımında kısar. Bu, benchmarklarda anlık iyi sonuç alıp trafik arttığında düşüş şeklinde görülür.

Disk + CPU etkileşimi

Örneğin uygulama disk I/O beklerse CPU boşa çıkar ve CPU kullanım oranı düşük görünebilir. Bu durumda vCPU yükseltmek bile tek başına fayda sağlamaz; storage performansı ve queue derinliği belirleyici olur.

“Aynı vCPU” aynı performans demek değildir: pratik karşılaştırma ölçütleri

Net karar için sağlayıcıdan plan karşılaştırırken aşağıdaki listeyi doğrudan kontrol edin.

Sağlayıcıdan talep etmeniz gereken net bilgiler

CPU türü: CPU modeli (ör. Intel Xeon/AMD EPYC) ve nesil
Tahsis modeli: dedicated core mu, shared core mu?
CPU limit/guarantee: “Guaranteed” CPU var mı, yoksa overcommit mi?
Burst: burst süresi ve sınırları belirtiliyor mu?
Oversubscription açıklaması: “oversell” oranı veya en azından yaklaşım
Storage performansı: NVMe mi SATA mı, IOPS/throughput var mı?

Kendi ölçümünüzle doğrulama

Planları karşılaştırırken VM üzerinde kısa bir performans doğrulaması yapmak en hızlı yöntemdir. Örneğin: - Uygulamanın tipik iş yükü (request profili) ile saniyedeki iş (RPS) / gecikme (latency) - CPU ile ilişkili metrikler: p95/p99 latency - Zamanlama: yoğun kullanım anında performans düşüyor mu?

vCPU sayısı yerine doğru kapasiteyi nasıl anlarsınız?

vCPU sayısını “hedef iş yükünüzün” ihtiyacına göre yorumlayın.

Hızlı seçim rehberi

Tekrarlı, paralel çok iş (batch işlemler, worker queue): vCPU sayısı daha kritik olur.
Web uygulaması (ortalama istek yükü): vCPU + tek çekirdek performansı + uygulama mimarisi birlikte değerlendirilir.
Veritabanı (MySQL/PostgreSQL): vCPU kadar bellek ve disk IOPS belirleyicidir; CPU tek başına her şeyi çözmez.

Uygulama profiline göre pratik öneri

Trafik dalgalanması yaşayan WordPress/benzeri kurulumlarda “burst + tutarlı CPU” daha değerlidir. Sadece vCPU sayısı yüksek diye gecikme düşmeyebilir.
Container/worker mimarisinde (ör. 4 worker) 4 vCPU çoğu senaryoda iyi bir başlangıçtır. Ancak CPU limit veya oversubscription varsa worker sayısını artırmak tıkanıklığı geciktirmek yerine gecikmeyi büyütebilir.

Net kontrol: Kötü vCPU tanımı nasıl anlaşılır?

Aşağıdaki durumlar genellikle “vCPU var ama efektif performans düşük” senaryolarına işaret eder:

Plan metninde CPU modeli belirsiz, sadece “x vCPU” yazıyor
“Unlimited” veya çok gevşek CPU limit ifadeleri var
Yoğun saatlerde p95/p99 gecikme artışı raporlanıyor (müşteri yorumları + kendi testiniz)
Depolama performansı düşük ve uygulama CPU’yu bekleyerek meşgul gösteriyor

Sonuç: vCPU’yu doğru okuyun, planı doğru doğrulayın

vCPU, VM’in CPU kaynağını ifade etmenin pratik yoludur; fakat fiziksel CPU çekirdeğiyle birebir eşdeğer değildir. Karar verirken “sadece vCPU sayısını” değil; CPU modeli, tahsis modeli (shared/dedicated), CPU limit/burst ve disk performansını birlikte değerlendirin. Aksiyon olarak: satın almadan önce planın CPU garanti/limit detaylarını netleştirin ve mümkünse kısa bir yük testiyle p95/p99 gecikme davranışını doğrulayın. Bu yaklaşım, aynı vCPU sayısının farklı performans vermesi riskini ciddi ölçüde azaltır.