vCPU ile Fiziksel Çekirdek İlişkisi

Panelde "4 vCPU" yazan bir sanal sunucu satın aldın ve nproc komutu sana dört çekirdek gösteriyor. Peki bu dört çekirdek, fiziksel makinenin içindeki dört gerçek çekirdek mi? Yoksa aynı fiziksel çekirdeği başka on müşteriyle paylaşan dört sıra numarası mı? Bu sorunun cevabı sağlayıcıdan sağlayıcıya, hatta aynı sağlayıcının farklı ürün ailelerinde bile değişir — ve fiyat farkının büyük bölümünü de bu belirler. vCPU ile fiziksel çekirdek arasındaki ilişkiyi anlamadan, iki teklifi doğru kıyaslaman mümkün değil.

Bu rehberde bir vCPU'nun hipervizör tarafında fiziksel olarak neye karşılık geldiğini, zamanlayıcının (scheduler) CPU zamanını nasıl dilimlediğini, aşırı tahsis (overcommit) oranlarının gerçek hayatta hangi aralıklarda dolaştığını, hyper-threading'in "çekirdek sayısı" yanılgısını nasıl beslediğini ve en önemlisi kendi makinende bu kaynağın gerçekten sana ait olup olmadığını hangi komutlarla ölçebileceğini anlatacağım. Sonunda "4 vCPU" ifadesine bakıp ne aldığını tahmin etmek yerine, elinde ölçüm olacak.

vCPU Aslında Neyi Temsil Eder#

Bir vCPU, hipervizörün misafir işletim sistemine sunduğu sanal bir işlemci soketidir. Misafir işletim sistemi açısından bu, tam donanımlı bir CPU çekirdeğidir: kendi kayıt yığını, kendi kesme (interrupt) hattı, kendi zamanlayıcı kuyruğu vardır. Ancak hipervizör tarafında bu vCPU, çoğu modern sistemde (KVM, Xen, VMware ESXi) yalnızca ana makine üzerinde çalışan bir iş parçacığıdır (thread). KVM'de tam anlamıyla böyledir: her vCPU, qemu-kvm süreci içinde bir POSIX thread'idir ve Linux'un kendi CFS zamanlayıcısı tarafından, tıpkı bir Nginx işçisi ya da bir MySQL bağlantısı gibi sıraya sokulur.

Bu tek cümle çoğu şeyi açıklar. Fiziksel çekirdek (pCPU) bir kaynaktır; vCPU ise o kaynağa erişmek için sıraya giren bir taleptir. Sekiz fiziksel çekirdekli bir ana makinede toplam 32 vCPU dağıtabilirsin — hipervizör bunu memnuniyetle kabul eder. Sorun, o 32 vCPU'nun aynı anda iş yapmak istemesi durumunda ortaya çıkar. Talep kapasiteyi aştığında zamanlayıcı sıraya alır, bekleyen misafir ise bu bekleme süresini steal time olarak görür. Ana makinedeki fiziksel çekirdek sayısını görmek için:

# Fiziksel soket, çekirdek ve thread dağılımı
lscpu | grep -E 'Socket|Core|Thread|Model name'
# Örnek çıktı:
# Thread(s) per core:   2
# Core(s) per socket:   16
# Socket(s):            2
# Model name:           Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz

Bu çıktıda toplam mantıksal işlemci sayısı 2 × 16 × 2 = 64 olur, ancak fiziksel çekirdek sayısı 32'dir. Aradaki fark hyper-threading'ten gelir ve birazdan ayrı bir başlıkta ele alacağım. Misafir makinenin içinde aynı komutu çalıştırdığında göreceğin değerler, hipervizörün sana sunduğu sanal topolojidir; ana makinenin gerçeği değil.

Zamanlayıcı vCPU'ya Zamanı Nasıl Dağıtır#

Linux/KVM tarafında iş çok basit bir mantıkla yürür: her vCPU thread'i, çalıştırılabilir hale geldiğinde zamanlayıcının çalışma kuyruğuna girer ve kendisine bir zaman dilimi (time slice) verilene kadar bekler. Dilim genellikle birkaç milisaniyedir. Dilim bitince ya da thread bloke olunca (örneğin disk I/O beklerken) CPU başka bir thread'e geçer. Misafir işletim sistemi bu geçişten habersizdir; onun için zaman kesintisiz akıyormuş gibi görünür, sadece "arada bir saat ileri sıçramış" gibi davranır.

Bu modelin en önemli sonucu şudur: boştaki bir vCPU, fiziksel çekirdeği tüketmez. Bir müşterinin sunucusu günün yirmi saatinde %2 CPU kullanıyorsa, o vCPU'nun karşılığı olan fiziksel kapasite fiilen boştadır ve başka bir misafir tarafından kullanılabilir. Aşırı tahsisin ekonomik mantığı tam olarak budur — havayolu şirketinin uçağı fazla satması gibi, çünkü herkesin aynı anda uçuşa gelmeyeceğini bilir. Sorun sadece herkes aynı anda gelirse çıkar.

CPU zamanının gerçekten nasıl dağıtıldığını hipervizörde cgroup üzerinden sınırlayabilirsin. KVM/libvirt kullanan bir ortamda bir misafire CPU kotası koymak şöyle görünür:

# Bir misafire toplam 2 fiziksel çekirdek değerinde kota ver
# period 100000 us = 100 ms, quota 200000 us = 200 ms -> 2 çekirdek
virsh schedinfo musteri-vm --set vcpu_period=100000 --set vcpu_quota=200000 --live

# Mevcut ayarı oku
virsh schedinfo musteri-vm

Burada quota / period oranı, misafirin alabileceği maksimum fiziksel çekirdek karşılığını verir. Kota konulmuş bir sistemde misafir, boştaki fiziksel kapasiteyi görse bile onu kullanamaz; bu, "garantili çekirdek" satan ürünlerin arka planındaki mekanizmadır. Kota yoksa misafir, ana makine müsaitse tahsis edilenden fazlasını da anlık olarak kullanabilir — ama komşular uyandığında o fazlalık aniden geri çekilir ve uygulaman "bazen hızlı bazen yavaş" davranmaya başlar.

vCPU:pCPU Oranı ve Gerçekçi Sınırlar#

Sektörde "aşırı tahsis oranı" dediğimiz şey, ana makinedeki toplam vCPU sayısının fiziksel çekirdek sayısına bölümüdür. Bu oranın doğru bir değeri yoktur; iş yüküne göre değişir. Aşağıdaki tablo, sahada gördüğüm tipik aralıkları ve o aralıklarda ne beklemen gerektiğini özetliyor:

Bu tabloya bakarken şunu unutma: oran tek başına bir şey ifade etmez, komşuların davranışı ile birlikte anlam kazanır. 6:1 oranındaki bir ana makinede tüm misafirler geceleri boşta duran küçük WordPress siteleriyse hiçbir sorun yaşamazsın. Aynı 6:1 oranında komşularından biri sürekli video kodlaması yapıyorsa, sen %15 steal time görür ve neden yavaşladığını anlayamazsın. Bu yüzden ciddi iş yükleri için oranı sormak yerine, garantiyi sormak daha doğrudur: "vCPU'lar pinlenmiş mi, kota var mı, CPU başına kaç misafir düşüyor?"

Öngörülebilirlik senin için kritikse, çekirdeklerin fiziksel olarak ayrıldığı VDS veya dedicated sunucu tarafına geçmek, paylaşımlı bir üründe daha fazla vCPU satın almaktan çok daha etkilidir. Hangi eşikte fiziksel makineye geçmen gerektiğini dedicated sunucu ne zaman gerekir yazısında ayrıntılı olarak ele aldım.

Hyper-Threading ve "Çekirdek" Sayma Yanılgısı#

Intel'in Hyper-Threading, AMD'nin SMT dediği teknoloji, tek bir fiziksel çekirdeği işletim sistemine iki mantıksal işlemci olarak gösterir. Amaç, bir thread bellek beklerken çekirdeğin boşta kalan yürütme birimlerini ikinci bir thread'e kullandırmaktır. Kazanç gerçektir ama sınırlıdır: iş yüküne göre genellikle %15 ile %30 arasında ek verim sağlar, asla iki katı değil.

Sorun, çoğu sağlayıcının vCPU sayarken mantıksal işlemcileri saymasıdır. 32 fiziksel çekirdekli bir ana makine, hyper-threading açıkken 64 mantıksal işlemci gösterir ve 64 vCPU dağıtıldığında oran kağıt üzerinde 1:1 görünür. Gerçekte ise iki vCPU aynı fiziksel çekirdeğin yürütme birimlerini paylaşıyordur; yani gerçek oran 2:1'dir. Bunu misafirin içinden doğrudan göremezsin, ama tek çekirdek performansını ölçerek dolaylı olarak anlarsın:

# Tek çekirdek üzerinde saf hesaplama testi (openssl her dağıtımda var)
openssl speed -evp aes-256-cbc 2>/dev/null | tail -3

# sysbench ile tek ve çok çekirdek karşılaştırması
sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep 'events per second'
sysbench cpu --cpu-max-prime=20000 --threads=4 run | grep 'events per second'

Dört thread'lik sonuç, tek thread'in dört katına yaklaşıyorsa çekirdekler gerçekten ayrıktır. Eğer sonuç 2.2 – 2.6 kat civarında kalıyorsa, büyük olasılıkla vCPU'ların ikişer ikişer aynı fiziksel çekirdeği paylaşan thread kardeşleridir. Bu ölçüm bir dakika sürer ve satın alma kararını değiştirecek kadar bilgi verir.

vCPU Performansını Kendi Sunucunda Ölçmek#

Sağlayıcının pazarlama metninden bağımsız olarak, elindeki makinenin ne yaptığını ölçebilirsin. Şu üç ölçümü sırayla yapmanı öneririm:

1. Steal time taban çizgisi. vmstat 1 10 çalıştır ve st sütununu izle. Sürekli sıfırsa kaynak sana ayrılmış demektir; tek haneli değerler kabul edilebilir, çift haneliler ciddi paylaşım işaretidir.
2. Tek çekirdek ham gücü. sysbench cpu --threads=1 ile ölçtüğün değeri not et. Aynı fiyat bandındaki iki teklif arasında bu sayı bazen %40 fark eder çünkü ana makinelerin işlemci nesli farklıdır.
3. Yük altında kararlılık. Tüm çekirdekleri 10 dakika doldurup ölçümü tekrarla. Değer düşüyorsa ya termal kısıtlama ya da komşu baskısı vardır.

# 1. Adım: steal time izleme
vmstat 1 10
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  1  0      0 512340  84512 903112    0    0     0     8  412  760  6  1 93  0  0

# 3. Adım: tüm çekirdekleri doldurup kararlılığı ölç
stress-ng --cpu $(nproc) --timeout 600s --metrics-brief

Steal time'ın ne anlama geldiğini ve hangi eşiğin gerçekten sorun sayıldığını CPU steal time nedir yazısında sayısal olarak ele aldım. Bellek tarafında benzer bir "görünen ile gerçek" farkı olduğunu da RAM balloon ve bellek aşırı tahsisi yazısında bulabilirsin; CPU ve bellek aşırı tahsisi neredeyse her zaman birlikte uygulanır.

CPU Pinning, NUMA ve Ayarlama#

Sanallaştırma katmanında performansı öngörülebilir hale getirmenin en güçlü aracı CPU pinning'dir: bir misafirin vCPU thread'lerini belirli fiziksel çekirdeklere sabitlersin, zamanlayıcı onları başka çekirdeğe taşıyamaz. Bunun iki büyük faydası vardır. Birincisi, misafir sürekli aynı çekirdekte çalıştığı için L1/L2 önbelleği sıcak kalır ve önbellek ıskalamaları azalır. İkincisi, çok soketli makinelerde vCPU ile belleğin aynı NUMA düğümünde kalması sağlanır — çapraz düğüm bellek erişimi ciddi bir gecikme kaynağıdır.

# vCPU 0'ı fiziksel çekirdek 4'e, vCPU 1'i çekirdek 5'e sabitle
virsh vcpupin musteri-vm 0 4 --live --config
virsh vcpupin musteri-vm 1 5 --live --config

# Mevcut pinleme haritasını göster
virsh vcpupin musteri-vm

Pinning'in bedeli esnekliktir: sabitlenmiş bir misafir, boştaki başka çekirdekleri kullanamaz. Bu yüzden pinning genellikle garantili kaynak satılan ürünlerde ve gecikmeye duyarlı iş yüklerinde (veritabanı, gerçek zamanlı işleme, oyun sunucusu) uygulanır. Çok soketli sistemlerde bunun neden bu kadar önemli olduğunu ve yanlış yerleşimin nasıl %30'a varan kayıp yarattığını NUMA nedir ve VM performansına etkisi yazısında anlattım.

Sık Yapılan Hatalar ve Tuzaklar#

En sık gördüğüm hata, yavaşlığı vCPU sayısı artırarak çözmeye çalışmak. Uygulaman tek thread'liyse — klasik bir PHP-FPM isteği, tek işçili bir Node süreci, indeks kullanmayan bir SQL sorgusu — sekizinci vCPU'yu eklemenin hiçbir faydası olmaz, çünkü darboğaz tek çekirdek hızıdır. Önce top içinde 1 tuşuna basıp yükün çekirdeklere nasıl dağıldığına bak: tek çekirdek %100, diğerleri boştaysa sorun paralellikte, kapasitede değil.

İkinci tuzak, vCPU'yu çok fazla vermek. Kulağa ters gelir ama fazla vCPU sanal makineyi yavaşlatabilir. Hipervizör, bazı işlemler için misafirin tüm vCPU'larını aynı anda zamanlamak zorunda kalır (co-scheduling); vCPU sayısı arttıkça bu kadar çekirdeği aynı anda boşta bulmak zorlaşır ve misafir daha uzun bekler. 16 vCPU'lu bir makinenin 8 vCPU'luya göre daha kötü sonuç verdiği durumları defalarca ölçtüm. Kural basit: gerçekten kullanmadığın çekirdeği alma.

Üçüncü hata, top çıktısındaki %CPU değerine misafir içinden bakıp mutlu olmak. Misafirin gördüğü yüzde, kendisine verilen zamanın yüzdesidir; ana makine ona zamanın yarısını veriyorsa %50 görünen yük aslında fiziksel çekirdeğin %25'idir. Gerçek resmi ancak steal time ve mutlak bir kıyaslama testi (benchmark) birlikte verir. Son olarak, karşılaştırmayı farklı saatlerde yapmak da bir tuzaktır: gece 03:00'te ölçtüğün değer, iş saatlerindeki komşu yükünü hiç yansıtmaz. En az bir kez yoğun saatte tekrar ölç.

Sıkça Sorulan Sorular#

vCPU bir fiziksel çekirdeğe eşit mi#

Hayır, doğrudan eşit değildir. vCPU, hipervizörün misafire sunduğu sanal bir işlemcidir ve arka planda ana makinede bir iş parçacığı olarak çalışır. Sağlayıcı 1:1 tahsis yapıyor ve pinning uyguluyorsa pratikte bir fiziksel çekirdeğe çok yakın performans alırsın. Aşırı tahsis yapılan paylaşımlı ürünlerde ise aynı fiziksel çekirdek birden fazla misafirin vCPU'sunu taşır ve aldığın gerçek kapasite komşu yüküne göre değişir.

Kaç vCPU almam gerektiğini nasıl belirlerim#

Mevcut sistemindeki gerçek kullanımı ölçerek başla. Bir hafta boyunca sar -u 1 ya da basit bir izleme aracıyla ortalama ve tepe CPU kullanımını kaydet. Tepe kullanımın mevcut çekirdek sayısının %70'ini geçmiyorsa artırmaya gerek yoktur. Uygulaman tek thread'li çalışıyorsa çekirdek sayısı yerine tek çekirdek hızı yüksek bir ürün seçmek çok daha etkili olur.

Hyper-threading vCPU sayısını iki katına çıkarır mı#

Mantıksal işlemci sayısını iki katına çıkarır ama gerçek işlem kapasitesini çıkarmaz. İki thread aynı fiziksel çekirdeğin yürütme birimlerini paylaştığı için tipik kazanç iş yüküne göre %15 – %30 bandındadır. Bu yüzden "64 vCPU" ilanı gördüğünde ana makinede 32 fiziksel çekirdek olma ihtimali yüksektir ve kağıt üstündeki 1:1 oranı gerçekte 2:1'dir.

vCPU sayısını artırınca sunucum neden hızlanmadı#

Büyük olasılıkla darboğazın CPU değil. Disk I/O beklemesi (vmstat çıktısında wa sütunu), bellek yetersizliği ya da tek thread'li bir uygulama mimarisi en sık nedenlerdir. Ayrıca uygulaman paralel çalışsa bile fazla vCPU, hipervizörün tüm çekirdekleri aynı anda zamanlamasını zorlaştırarak ters etki yapabilir. Artırmadan önce yükün çekirdekler arasında nasıl dağıldığını mutlaka ölç.

vCPU performansımı ücretsiz nasıl ölçerim#

Dağıtım depolarındaki araçlar yeterlidir. sysbench cpu --threads=1 run tek çekirdek gücünü, aynı komutun --threads=$(nproc) hali toplam kapasiteyi verir; vmstat 1 çıktısındaki st sütunu ise komşu baskısını gösterir. openssl speed neredeyse her sunucuda kurulu gelir ve hızlı bir referans sağlar. Ölçümü hem gece hem de iş saatlerinde tekrarlamak, tek seferlik testten çok daha anlamlı bir tablo çıkarır.

Garantili çekirdek ile paylaşımlı vCPU arasındaki fiyat farkı değer mi#

Yükün öngörülebilirliğe ne kadar bağlı olduğuna göre değişir. Veritabanı, ödeme işleme, video kodlama ya da CI derleme gibi sürekli CPU tüketen işlerde garantili kaynak neredeyse her zaman karşılığını verir; çünkü paylaşımlı üründe yaşadığın dalgalanmayı ek kapasite satın alarak telafi edemezsin. Çoğu zaman boşta duran bir blog ya da kurumsal tanıtım sitesi içinse paylaşımlı vCPU fazlasıyla yeterlidir ve aradaki farkı yedekleme ya da izlemeye ayırmak daha akıllıcadır.

Kapanış#

vCPU, fiziksel çekirdeğin bir kopyası değil, ona erişim hakkı veren bir sıradır. Bu yüzden kağıt üzerindeki çekirdek sayısı tek başına hiçbir şey söylemez; anlamlı olan üç şey vardır: aşırı tahsis oranı, çekirdeklerin sabitlenip sabitlenmediği ve komşuların davranışı. Aklında tutman gereken pratik alışkanlıklar da bunlardan çıkar — satın almadan önce tek çekirdek performansını ölç, steal time'ı düzenli izle, yavaşlığı çekirdek ekleyerek değil profil çıkararak çöz ve gerçekten kullanmadığın vCPU'yu alma.

Öngörülebilir CPU performansına ihtiyacın varsa kaynakların fiziksel olarak ayrıldığı VDS paketlerimiz ya da tüm makinenin sana ait olduğu dedicated sunucu çözümlerimiz doğru başlangıç noktasıdır; daha esnek ve ölçeklenebilir bir yapı arıyorsan bulut sunucu tarafına bakabilirsin. Kurulum, ayarlama ve izleme işini kendin üstlenmek istemiyorsan sunucu yönetimi hizmetimiz pinning ve kaynak planlaması dahil bu işleri senin yerine yürütür.