Red Hat sanallaştırma dokümanında guest CPU topolojisi socket × core × thread olarak tanımlanabilir; toplam vCPU sayısı fiziksel host çekirdeğiyle birebir aynı kavram değildir.
VPS/VDS paketindeki vCPU, çekirdek ve thread kavramlarını; CPU topolojisi, oversubscription, pinning ve tek çekirdek performansıyla birlikte öğrenin.
Red Hat sanallaştırma dokümanında guest CPU topolojisi socket × core × thread olarak tanımlanabilir; toplam vCPU sayısı fiziksel host çekirdeğiyle birebir aynı kavram değildir.
Aynı 4 vCPU iki farklı sağlayıcıda aynı performansı garanti etmez; fiziksel işlemci, frequency policy, overcommit ve scheduler etkisi değişebilir.
Fiziksel core işlemcide bağımsız yürütme kaynaklarına sahip gerçek çekirdektir. SMT/Hyper-Threading bir fiziksel core üzerinde birden fazla logical CPU görünmesini sağlar. vCPU ise hypervisor'ın sanal makineye sunduğu scheduler-visible işlemci birimidir.
Bu nedenle '1 vCPU = 1 fiziksel core' varsayımı teknik sözleşmede açıkça belirtilmedikçe yapılmamalıdır. Bir vCPU fiziksel logical processor zamanı üzerinde schedule edilebilir; dedicated/pinned CPU hizmetlerinde ilişki daha sıkı olabilir.
Linux'ta `lscpu` socket, core per socket, thread per core ve CPU modelini gösterebilir. Ancak hypervisor CPU modelini maskeleyebilir veya sanal topoloji sunabilir. Bu nedenle model adı tek başına hostun tüm fiziksel mimarisini kanıtlamaz.
Windows'ta `Get-CimInstance Win32_Processor` ve Task Manager logical processor sayısını gösterebilir. Yine de bu guest'e sunulan topolojidir.
lscpu
nproc
grep -E 'model name|cpu MHz' /proc/cpuinfo | head
Get-CimInstance Win32_Processor | Select-Object Name,NumberOfCores,NumberOfLogicalProcessors,MaxClockSpeed
vCPU sayısı kapasite potansiyelidir; core başına iş hızı değildir. Eski düşük frekanslı bir hostta 4 paylaşımlı vCPU, yeni yüksek IPC/frekanslı hostta 2 vCPU'dan tek request gecikmesinde geride kalabilir. WordPress/PHP ve bazı oyun server thread'leri tek çekirdek gecikmesine duyarlıdır.
Buna karşılık compile, video encoding, çoklu worker veya paralel container yükünde daha fazla vCPU ölçekleme sağlayabilir. Workload'un paralelleşme derecesi seçimi belirler.
Bir fiziksel hosttaki toplam guest vCPU sayısının fiziksel logical CPU sayısından fazla olması mümkündür. Bu tek başına kötü değildir; çoğu VM sürekli yüzde 100 CPU kullanmaz. Sorun, aynı anda yoğun CPU talebi oluştuğunda scheduler'ın vCPU'ları bekletmesi ve performans varyansının yükselmesidir.
Linux guest'te `%steal` bu konuyu gözlemek için önemli sinyallerden biridir; ayrı CPU steal rehberinde detaylı ölçüm yapılır.
Sağlayıcı 'dedicated CPU' diyorsa neyi garanti ettiğini sorun: fiziksel core mu, logical thread mi, belirli pCPU'ya pinning mi, yalnız scheduler quota mı? Teknik sözleşme olmadan kelime tek başına karşılaştırılabilir bir standart değildir.
İşlemci model/nesli nedir? vCPU shared mı dedicated mı? CPU burst/quota var mı? Steal veya fair-use politikası var mı? Nested virtualization destekleniyor mu? CPU model masking uygulanıyor mu? Paket yükseltirken vCPU hot-add veya restart gerekiyor mu? Bu sorular 4 vCPU etiketinden daha açıklayıcıdır.
| Terim | Anlamı | Yanlış varsayım |
|---|---|---|
| Physical Core | Fiziksel işlemci çekirdeği | Her vCPU buna birebir eşittir |
| SMT Thread | Core üzerindeki logical CPU | İkinci fiziksel core ile aynıdır |
| vCPU | Guest'e sunulan sanal CPU | Performansı sağlayıcıdan bağımsız sabittir |
Tek bir benchmark, port etiketi veya CPU marka adıyla satın alma kararı vermeyin. Aynı testleri farklı saatlerde tekrarlayın; destructive disk testlerini production verisi üzerinde çalıştırmayın ve sağlayıcının kaynak/fair-use politikasını yazılı doğrulayın.
Sağlayıcının hypervisor ve kaynak politikasına bağlıdır; 4 vCPU ifadesi tek başına 4 fiziksel core garantisi değildir.
Hayır. SMT thread'ler aynı core kaynaklarının bir kısmını paylaşır; kazanç workload'a bağlıdır.
Projenizin yazılımını, eşzamanlı kullanıcı sayısını, disk/veritabanı yükünü ve lokasyon hedefini iletin; yalnız RAM/Core sayısına değil gerçek darboğaza göre sunucu sınıfını belirleyin.