vCPU nedir? Fiziksel CPU çekirdeğinden farkı (net rehber)

vCPU nedir? Sanalda “CPU” sayısı nasıl ölçülür?

VDS/VPS gibi sanallaştırılmış (virtualized) sunucularda karşılaşacağınız vCPU, fiziksel sunucudaki işlem gücünün sanal makinelere paylaştırılmış ifadesidir. Kullanıcı açısından vCPU; VM (Virtual Machine) için ayrılan işlem zamanı hakkını anlatır. Ancak vCPU sayısı her zaman “eşdeğer fiziksel çekirdek” anlamına gelmez. Performans, yalnızca vCPU sayısıyla değil; çalışma frekansı (GHz), çekirdek tahsisi (dedicated vs shared), yoğunluk (oversubscription) ve CPU scheduler (planlayıcı) gibi unsurlarla belirlenir.

Bu yazıda şunları netleştireceksiniz: - vCPU ile fiziksel CPU çekirdeği arasındaki fark ne? - Aynı vCPU sayısında neden farklı performans görünüyor? - CPU kullanımını ölçerken hangi metrikler daha doğru resim verir? - VDS/VPS alırken “vCPU” ifadesini nasıl yorumlamalı ve hangi kontrol listesiyle karar vermelisiniz?

vCPU ile fiziksel çekirdek aynı şey mi?

Hayır. Fiziksel CPU çekirdeği, sunucunun üzerinde fiziksel olarak bulunan işlem birimidir. vCPU ise bu fiziksel çekirdeklerin (veya bazı kurulumlarda fiziksel çekirdek zamanının) sanal makineye mantıksal karşılığıdır.

vCPU nasıl ortaya çıkar?

Tipik senaryolarda, sağlayıcı fiziksel sunucuyu hipervizörle (hypervisor) sanallaştırır: - Kullandığınız VM, hipervizör tarafından fiziksel çekirdeklerin işlem zamanına erişecek şekilde planlanır. - VM’ye “x adet vCPU” verildiğinde bu, VM’nin CPU zaman dilimlerinde çalışabilmesi için mantıksal bir kapasite tanımıdır. - Bu zaman dilimleri, aynı host üzerinde çalışan diğer VM’lerle paylaşılabilir.

Fiziksel çekirdek varken neden vCPU yazılır?

Fiyat/kapasite yönetimi ve ölçekleme için. Sağlayıcı, tek bir fiziksel sunucuyu çok sayıda kullanıcıya paylaştırırken her VM’ye uygulanacak “CPU payını” vCPU üzerinden standardize eder. Böylece ürün planları; örneğin 2 vCPU / 4 vCPU gibi tutarlı paketlerle sunulur.

En kritik fark: Paylaşım derecesi

vCPU sayısı, fiziksel çekirdeklerin birebir karşılığı değildir; özellikle shared CPU veya “oversell” (fazla VM ağırlığı) durumlarında vCPU, fiziksel çekirdek zamanının bir paylaşım oranını temsil eder.

Oversubscription ne zaman fark yaratır?

Oversubscription, bir fiziksel sunucudaki toplam sanal kaynak tahsisinin (vCPU toplamı) fiziksel kapasiteyi aşması durumudur. Bu, sağlayıcının donanımı daha verimli kullanmasını sağlar; fakat yoğun dönemlerde (trafik yükselince) performans dalgalanmasına neden olur.

Belirti olarak gördüğünüz performans farkı

Şu senaryolar, vCPU/çekirdek farkını pratikte hissettirir: - CPU kullanımı arttığında hız düşmesi: VM’niz vCPU’larda “çalışıyor” görünüp ama gerçek iş süresi uzuyorsa. - Aynı paketle gece-gündüz performans farklılığı: Komşu VM’ler yoğunlaştığında siz bekleme yaparsınız. - “İdeal koşul” testinde iyi, üretimde dalgalı performans: Kısa testler oversubscription etkisini her zaman yakalamayabilir.

Oversubscription her sağlayıcıda aynı mı?

Hayır. Bazı sağlayıcılar agresif oversell yapar, bazıları daha muhafazakâr paylaştırır. Buradaki belirleyici, sadece vCPU sayısı değil; host’un CPU modeli, çekirdek sayısı, toplam VM yoğunluğu ve CPU scheduler politikasıdır.

Aynı vCPU sayısı neden farklı performans verir?

Tek değişken vCPU değildir. CPU performansını etkileyen başlıca etkenler:

1) CPU mimarisi ve frekans

Farklı nesil Intel/AMD CPU’lar aynı “çekirdek sayısı”nı farklı performansla verir. Örneğin aynı 4 vCPU paketi; 3.0 GHz ve 4.0 GHz sınıfında ya da farklı mimarilerde farklı sonuçlar doğurur.

2) Gerçek tahsis türü: dedicated vs shared

• Dedicated vCPU yaklaşımında, VM’ye ayrılan CPU zaman dilimi daha belirgindir.
• Shared yaklaşımlarda, VM’ler aynı fiziksel çekirdek havuzundan zaman dilimi alır.

3) CPU limitleri ve burst davranışı

Bazı VDS planlarında “baseline” kapasite ve kısa süreli “burst” mantığı bulunur. CPU’nuz sürekli %70-100 çalışıyorsa burst avantajı sınırlı kalabilir.

4) CPU planlayıcı (scheduler) davranışı

Hipervizörün planlayıcısı; I/O bekleyen işler ile CPU-bound işler arasında zaman paylaşımını etkileyebilir. Özellikle veritabanı, kompresyon, şifreleme gibi CPU-bound işlerde bu fark daha belirginleşir.

vCPU sayısını doğru okumak için kontrol listesi

vCPU içeren bir VDS/VPS ürününü değerlendirirken şu ölçütler “paket metnindeki vCPU”dan daha belirleyicidir.

1) Sağlayıcı “CPU sınırlaması” koyuyor mu?

• “Guaranteed vCPU”, “dedicated core”, “no oversell” gibi ifadeler varsa açıklamasını kontrol edin.
• “Burstable”, “limit/average” gibi ibareler varsa limitin nasıl ölçüldüğünü isteyin veya dokümanda arayın.

2) CPU modelini ve neslini net yazıyor mu?

Mümkünse teklif/ürün sayfasında CPU modelini görün. Sadece “Xeon” veya “AMD EPYC” gibi genel ifadeler yerine model, çekirdek/iş parçacığı (threads) ve nesil faydalıdır.

3) Aynı vCPU ile I/O beklentiniz uyuşuyor mu?

CPU-bound işlerde vCPU kritiktir. Ancak web sunucusu gibi senaryolarda performansı belirleyen şey sadece CPU değildir; disk ve ağ gecikmesi de etkiler.

• Cache (önbellek) kullanmayan dinamik sayfalarda CPU + RAM + disk I/O birlikte darboğaz olur.
• Yüksek sorgu/işleme yapan sistemlerde CPU baskın hale gelir.

4) Kaynak izleme (monitoring) erişimi var mı?

VM üzerinde CPU kullanımı, yük (load average), throttling (kısılma) benzeri sinyaller için izleme ihtiyacınız var.

Önerilen pratik kontrol: - İlk kurulumdan sonra CPU kullanımını 24-48 saat boyunca izleyin. - Aynı dönemde gecikme (latency) ve uygulama yanıt sürelerini de kaydedin.

vCPU vs fiziksel çekirdek: karar verirken hangi paket daha mantıklı?

Aşağıdaki tablo, “vCPU sayısı” ile “beklenen iş türü” arasında daha doğru bir eşleştirme kurmanıza yardımcı olur.

vCPU sayısını artırma ne zaman yanlış olur?

• İşin darboğazı CPU değil disk/IO veya RAM ise vCPU artırmak tek başına fayda sağlamaz.
• Uygulama hatalı ayarlanmışsa (ör. bağlantı havuzu yanlış, query’ler yavaşsa) CPU artışı gecikmeyi tamamen çözmez.

CPU performansını ölçmek için pratik yöntemler

vCPU kavramını “kağıt üzerinde” okumak yetmez. Aşağıdaki yaklaşım, sanallaştırmada yanıltıcı olabilecek kısa testlerin yerine daha gerçekçi sinyal verir.

1) CPU-bound test: kısa değil, gerçek yükle

Örnek bir ölçüm mantığı: - Uygulama senaryonuzda aynı iş tipini üreten bir yük oluşturun. - CPU kullanımıyla birlikte yanıt sürelerini (p95/p99) izleyin.

2) CPU yükü ile throttling davranışını birlikte düşünün

Eğer CPU sürekli yüksek kullanıma yaklaşıp yanıt süreleri uzuyorsa şu ihtimaller güçlüdür: - Host üzerinde oversubscription - CPU limit/burstin tükenmesi - Uygulamanın CPU-bound olması ve scheduler gecikmesi

3) Aynı paket içinde “yeniden test” yapın

Özellikle ilk haftada farklı gün/saatlerde test yapmak önemlidir. Sağlayıcı kaynak paylaşımını dinamik yönetebilir.

vCPU ile ilgili en sık yanlış anlaşılmalar

“vCPU sayısı = fiziksel çekirdek sayısı”

Yanlış. vCPU, VM’nin eriştiği mantıksal kapasiteyi anlatır; paylaşım ve zamanlama, sonuçları değiştirir.

“2 vCPU alırsam 2 çekirdek kadar performans görürüm”

Yanlış. CPU’nun nesli, frekans ve host yoğunluğu belirleyicidir. Aynı 2 vCPU, iki farklı sağlayıcıda ciddi farklılık gösterebilir.

“CPU %100 hep aynı hızda çalışır”

Yanlış. Throttling/limit ve scheduler gecikmeleri devreye girebilir. Ayrıca uygulama queue biriktiriyorsa CPU kullanımı artarken yanıt süresi de uzar.

NetKıyas’ta seçim yaparken nasıl ilerleyin?

Kararınızı “sadece vCPU sayısına” göre değil, aşağıdaki sırayla netleştirin: 1. Teklif/ürün açıklamasında CPU modelini ve tahsis türünü (dedicated/shared) bulun. 2. CPU limit/burst ifadesi varsa nasıl çalıştığını dokümandan doğrulayın. 3. RAM ve disk I/O değerlerini vCPU ile eşleştirin; darboğazı doğru yerde arayın. 4. Kurduktan sonra CPU + uygulama yanıt süresi + yük metriğini beraber gözlemleyin.

Sonuç: vCPU’ya bakın ama kontrolü ölçümle tamamlayın

vCPU, sanallaştırılmış sunucularda VM’nin CPU zamanına erişimini ifade eden mantıksal bir ölçüdür; fiziksel CPU çekirdeğiyle birebir eşdeğer değildir. Bu yüzden aynı vCPU sayısında performans farkı normaldir: oversubscription, CPU mimarisi ve limit/burst gibi faktörler belirleyicidir. En doğru aksiyon; ürün sayfasında tahsis türünü ve CPU modelini kontrol etmek, sonra VM’de gerçek senaryoyla CPU + yanıt sürelerini izleyerek seçimi doğrulamaktır.