vCPU Nedir? 4 vCPU Gerçekten 4 Çekirdek mi (Overselling)

İki sağlayıcının fiyat listesi açık duruyor. İkisi de "4 vCPU, 8 GB RAM, 100 GB NVMe" yazıyor. Biri ayda 400 lira, diğeri 1.200. Aynı sayılar, üç kat fark. Aradaki farkın nereden geldiğini teknik özellik tablosunda bulamazsınız, çünkü fark tabloda yazan sayıda değil, o sayının arkasında ne kadar gerçek işlemci zamanı durduğundadır.

vCPU, fiziksel bir donanım parçası değildir. Sanal makinenize gösterilen bir soyutlamadır: işletim sisteminiz onu gerçek bir çekirdek sanır, nproc dört yazar, htop dört sütun çizer. Ama o dört sütunun altında, hipervizörün sizin adınıza fiziksel çekirdeklerde açtığı bir zaman payı vardır — ve o pay sabit değildir. Aynı fiziksel çekirdeği kaç kişiyle paylaştığınıza ve komşularınızın o an ne yaptığına göre değişir.

Bu yazıda önce vCPU'nun fiziksel çekirdek ve thread ile ilişkisini netleştireceğiz, sonra overselling'in nasıl çalıştığını ve neden tek başına kötü bir şey olmadığını göreceğiz. Asıl değerli kısım sonda: sunucunuzda steal time ölçerek "ödediğim CPU'yu gerçekten alıyor muyum" sorusuna kendi verinizle cevap vermeyi öğreneceksiniz.

vCPU Tam Olarak Neyi Temsil Eder?#

Bir sanal makine oluşturulurken hipervizöre "bu makineye dört adet mantıksal işlemci göster" denir. Hipervizör bunu yaptığında, misafir işletim sistemi dört ayrı çalıştırma bağlamı görür ve iş parçacıklarını bunlara dağıtır. Sistem çağrısı seviyesinde bu dört birim gerçek çekirdeklerden ayırt edilemez.

Perde arkasında olan şudur: her vCPU, hipervizör için zamanlanması gereken bir iş parçacığıdır. Sizin makinenizdeki bir vCPU çalışmak istediğinde, hipervizör onu fiziksel bir çekirdeğe yerleştirir, belirli bir süre çalıştırır, sonra sırada bekleyen başka bir makinenin vCPU'sunu oraya alır. Tıpkı tek çekirdekli bir bilgisayarda işletim sisteminin onlarca süreci sırayla çalıştırıp hepsinin aynı anda çalıştığı izlenimi vermesi gibi — sadece bir kat yukarıda.

Buradan iki sonuç çıkar. Birincisi, vCPU sayısı bir hız değil bir genişlik ölçüsüdür: dört vCPU, aynı anda dört iş parçacığını paralel çalıştırabileceğiniz anlamına gelir, her birinin ne kadar hızlı olacağı anlamına gelmez. İkincisi, o genişliğin gerçekten kullanılabilir olması, sıraya girdiğinizde çekirdeğin sizi bekletmemesine bağlıdır.

Sunucunuzun hangi sanallaştırma katmanı üzerinde koştuğunu ve size ne gösterildiğini şu komutlarla görebilirsiniz:

# Hangi hipervizörün üstündeyiz?
systemd-detect-virt

# CPU modeli, çekirdek/thread yapısı ve hipervizör bilgisi
lscpu

# İşletim sisteminin gördüğü mantıksal işlemci sayısı
nproc

lscpu çıktısındaki Hypervisor vendor satırı KVM, VMware ya da Microsoft yazıyorsa sanal bir makinedesiniz. Model name satırı ise altta koşan gerçek işlemcinin adını verir — bu satır, karşılaştırma yaparken elinizdeki en somut veridir. Sanallaştırma teknolojilerinin farkları için KVM ile sanallaştırma yazısı işin altyapı tarafını açıyor.

4 vCPU Gerçekten 4 Fiziksel Çekirdek mi?#

Kısa cevap: hayır, ve bunun iki ayrı sebebi var.

Birinci sebep thread'lerdir. Modern Intel ve AMD işlemcilerde bir fiziksel çekirdek, eşzamanlı çoklu iş parçacığı (SMT / Hyper-Threading) sayesinde iki mantıksal iş parçacığı sunar. Sektörde neredeyse evrensel uygulama, bir thread'i bir vCPU olarak saymaktır. Yani 32 fiziksel çekirdekli, 64 thread'li bir sunucu "64 vCPU kapasiteli" kabul edilir.

Bu sayım hile değildir ama eşitlik de değildir. İki thread aynı çekirdeğin yürütme birimlerini, önbelleğini ve bellek yolunu paylaşır. İkinci thread, birincinin bekleme boşluklarını doldurarak toplam verimi artırır — ama bu artış iş yüküne göre yaklaşık yüzde 15 ile 30 arasındadır, yüzde 100 değil. Dolayısıyla "2 vCPU" olarak size verilen bir çekirdek çifti, iki ayrı fiziksel çekirdek kadar iş çıkarmaz.

İkinci sebep zaman paylaşımıdır. Bir vCPU, tek başına bir thread'i sürekli işgal etmez. Sağlayıcı aynı thread'i birden fazla müşterinin vCPU'suna tahsis edebilir. İşte overselling burada devreye girer.

Overselling Nasıl Çalışır ve Neden Tek Başına Kötü Değil?#

Overselling, bir fiziksel sunucudaki toplam thread sayısından daha fazla vCPU satmaktır. 64 thread'li bir makinede toplamda 192 vCPU dağıtmak, 3:1 oranında bir aşırı tahsis demektir.

Bunun mantığı, tüm müşterilerin aynı anda tam kapasite çalışmamasıdır. Gerçek dünyada bir web sunucusunun CPU kullanımı gün boyu yüzde 2 ile 15 arasında gezinir; sadece trafik anlarında yükselir. Herkese kesintisiz bir fiziksel thread ayırmak, o thread'in zamanının yüzde doksanını boşa harcamak olurdu — ve fiyatlar buna göre şekillenirdi. Yani overselling, paylaşımlı barındırmanın temel ekonomisidir; onsuz ucuz VDS diye bir şey olmazdı.

Sorun oranın kendisi değil, oranın denetimsiz olmasıdır. 3:1 ile çalışan ve doluluk izleyen bir sağlayıcıda hiçbir zaman bekleme hissetmezsiniz. 10:1 ile çalışan ve aynı fiziksel makineye sürekli müşteri ekleyen bir sağlayıcıda ise günün belirli saatlerinde sunucunuz görünürde boşken bile yavaşlar. İkisinin de fiyat listesinde "4 vCPU" yazar.

Aradaki farkı özellik tablosundan okuyamazsınız. Okuyabileceğiniz tek yer, kendi sunucunuzdan alacağınız ölçümdür.

Paylaşımlı vCPU ile Ayrılmış vCPU Arasındaki Fark#

Sağlayıcılar bu iki modeli genellikle farklı ürün adlarıyla satar: "standart / paylaşımlı" ve "dedicated / ayrılmış CPU". Fiyat farkı çoğu zaman iki-üç kattır ve bu fark doğrudan yukarıdaki tahsis oranından gelir.

Paylaşımlı vCPU, patlamalı (bursty) iş yükleri için tasarlanmıştır. Kısa süreli yükselmelerde komşularınızın boş bıraktığı zamanı kullanabilir, hatta zaman zaman nominal payınızın üstüne çıkabilirsiniz. Sürekli yüzde yüz CPU isteyen bir işte ise pay hesabı devreye girer ve beklemeye başlarsınız. Kurumsal siteler, WordPress kurulumları, küçük API'ler, panel arkası uygulamalar bu modele uyar.

Ayrılmış vCPU, bir fiziksel thread'in yalnızca size tahsis edilmesidir. Fiyatı yüksektir çünkü sağlayıcı o kaynağı başka kimseye satamaz. Buna karşılık performansınız saatten saate değişmez — ki bazı işler için asıl kritik olan budur. Video kodlama, sürekli çalışan derleme sunucuları, gerçek zamanlı işlem yapan finansal uygulamalar, yoğun veritabanı sunucuları ve düşük gecikme isteyen oyun sunucuları bu sınıfa girer.

Seçim yaparken sorulacak soru "ne kadar CPU lazım" değil, "performansın öngörülebilir olması benim için ne kadar değerli" olmalıdır. Ortalama hızı aynı olan iki sistemden biri saatte bir kez üç kat yavaşlıyorsa, kullanıcı deneyimi açısından o sistem daha yavaştır. Kaynak ihtiyacınızı boyutlandırırken VDS için kaç CPU ve RAM gerekir yazısındaki hesap yöntemi iyi bir başlangıç noktasıdır. İşin bir de üst sınırı vardır: sürekli tam kapasite çalışan yükler için dedicated sunucu ne zaman gerekir sorusu kaçınılmaz olarak gündeme gelir.

Steal Time Nedir ve Sunucunuzda Nasıl Ölçülür?#

İşte yazının asıl işe yarayan bölümü. Steal time, vCPU'nuzun çalışmaya hazır olduğu ama hipervizörün ona fiziksel çekirdek veremediği için beklediği süredir. Linux çekirdeği bunu ölçer ve %st olarak raporlar.

Bu metriğin değeri şuradan gelir: sağlayıcının sizi ne kadar sıkıştırdığını doğrudan gösterir. Yüksek steal, "sunucum yavaş" hissinin öznel olmadığının kanıtıdır ve destek talebinde elinizdeki en sağlam veridir.

Anlık bakış#

En hızlı yol top komutudur. Üstteki %Cpu(s) satırının sonunda st alanını göreceksiniz:

top -b -n 1 | head -5

vmstat daha okunaklı bir akış verir; en sağdaki st sütunu steal yüzdesidir:

vmstat 1 10

Çekirdek başına dağılım için sysstat paketindeki mpstat idealdir — bir vCPU'nun ezildiğini diğerlerinin rahat olduğunu ancak böyle görürsünüz:

sudo apt install -y sysstat
mpstat -P ALL 2 5

Doğru ortalamayı almak#

Tek bir anlık okuma yanıltıcıdır; steal dalgalanır. Çekirdeğin tuttuğu ham sayaçlardan iki nokta arası gerçek ortalamayı hesaplamak daha sağlıklıdır:

read -r _ u n s i w irq sirq st _ < /proc/stat
t1=$((u+n+s+i+w+irq+sirq+st)); s1=$st
sleep 60
read -r _ u n s i w irq sirq st _ < /proc/stat
t2=$((u+n+s+i+w+irq+sirq+st)); s2=$st
awk -v a=$((s2-s1)) -v b=$((t2-t1)) 'BEGIN{printf "60 sn steal: %.2f%%\n", a*100/b}'

Bu betik /proc/stat dosyasının ilk satırındaki toplam sayaçları okur, altmış saniye bekler, farkı alır ve steal payını yüzde olarak yazar. Anlık örneklemeye göre çok daha güvenilirdir.

Uzun süreli kayıt#

Asıl önemli olan, steal'in hangi saatlerde yükseldiğidir. Komşularınızın yedekleme ya da toplu iş çalıştırdığı saatler varsa bu ancak günlük bir grafikte görünür. sysstat paketi bunu arka planda toplar:

sudo systemctl enable --now sysstat
# Bugünün saatlik dökümü
sar -u | awk 'NR<4 || $NF+0>0 {print}'
# Dünün kayıtları (gün numarasına göre)
sar -u -f /var/log/sysstat/sa17

Grafiksel takip istiyorsanız Netdata ile sunucu izleme kurulumu steal metriğini de hazır panelde gösterir ve eşik aşımında uyarı üretebilir.

Steal Time Kaçtan Sonra Sorun Sayılır?#

Kesin bir eşik yoktur ama saha pratiğinde şu aralıklar iyi çalışır:

Kısa süreli sıçramalar normaldir; birkaç saniyelik yüzde 15'lik bir tepe kimsenin dikkatini çekmemelidir. Anlamlı olan, saatler boyunca süren ortalamadır. Bir saat boyunca yüzde 8 steal görüyorsanız, o saat içinde satın aldığınız işlemci zamanının yaklaşık on ikide birini hiç kullanamamışsınız demektir.

Steal ile load average değerini birlikte okumak ayrımı netleştirir. Yük ortalaması yüksek ve steal sıfıra yakınsa, sorun sizin uygulamanızdadır: gerçekten CPU tüketiyorsunuz ve daha fazlasına ihtiyacınız var. Yük ortalaması yüksek, steal de yüksekse, süreçleriniz iş yaptıkları için değil sıra bekledikleri için kuyrukta duruyor demektir — bu ikisi tamamen farklı çözümler gerektirir. Birincisinde kod ya da kapasite optimize edilir, ikincisinde sağlayıcıyla konuşulur.

Destek talebi açarken ham cümle yerine ölçüm gönderin: hangi saat aralığında, kaç dakikalık örnekte, ortalama yüzde kaç steal gördüğünüz. Bu veriyle gelen talep, "sunucum yavaş" diyen talepten çok farklı işlem görür.

Steal Görünmüyorsa Sorun Yok Demek Değildir#

Burada bir tuzak var: bazı platformlarda steal metriği ya hiç raporlanmaz ya da anlamlı değildir.

VMware üzerinde misafir işletim sistemi genellikle steal göremez. VMware'in karşılığı olan %RDY (CPU ready) değeri host tarafında ölçülür ve sizin göremediğiniz vCenter panelinde durur. %st sıfır çıkıyor diye rahat olamazsınız; bu ortamda gerçek testi bir sonraki bölümdeki sabit iş yükü yöntemiyle yapmalısınız.

Konteyner tabanlı sanallaştırmada (OpenVZ, LXC) tablo daha da karışır. Bu sistemlerde çekirdek host ile paylaşılır ve nproc ile lscpu çoğu zaman host makinenin tüm çekirdeklerini gösterir. Elinizde 2 vCPU'luk bir paket varken nproc 48 yazabilir. Gerçek sınırı cgroup ayarlarından okumanız gerekir:

# cgroup v2
cat /sys/fs/cgroup/cpu.max

# cgroup v1
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us

cpu.max çıktısı 200000 100000 şeklindeyse, 100 ms'lik her periyotta 200 ms CPU zamanı hakkınız var demektir — yani 2 çekirdek. max 100000 yazıyorsa kota yok demektir. Kota mekanizmasının uygulama üzerindeki etkileri için ulimit ile kaynak limitleri yazısı da tamamlayıcı bir bakış sunar.

Üçüncü bir görünmez etken işlemci frekansıdır. Aynı "4 vCPU" etiketi, 2,1 GHz'de çalışan eski bir sunucu işlemcisinde de, 3,8 GHz'de turbolanan yeni bir çekirdekte de kullanılır. Tek iş parçacıklı performans arasındaki fark iki katı bulabilir. lscpu çıktısındaki Model name satırı bu yüzden fiyat karşılaştırmasında vCPU sayısı kadar önemlidir.

Aldığınız CPU'yu Gerçekten Alıyor musunuz? Sabit İş Yükü Testi#

Steal ölçülemediği durumlarda ya da ölçümü doğrulamak istediğinizde, değişmeyen bir işi tekrar tekrar çalıştırıp süresini karşılaştırmak en dürüst yöntemdir. Mantık basittir: iş aynıysa, süre uzuyorsa aradaki fark size verilmeyen CPU zamanıdır.

Hiçbir paket kurmadan çalışan bir ölçüm için OpenSSL yeterlidir:

# Tek çekirdek şifreleme performansı
openssl speed -evp aes-256-cbc 2>/dev/null | tail -3

# Tek çekirdek saf hesaplama, süre ölçümü
time openssl speed -seconds 5 rsa2048 2>/dev/null | tail -2

Daha yapılandırılmış bir test için sysbench kullanabilirsiniz. Tek çekirdek ve tüm çekirdekler için ayrı ayrı çalıştırmak, SMT etkisini de görmenizi sağlar:

sudo apt install -y sysbench

# Tek iş parçacığı
sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep -E "events per second|total time"

# Tüm vCPU'lar
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run | grep "events per second"

Burada dikkat edilecek nokta, dört vCPU'lu bir makinede dört iş parçacığının tek iş parçacığının dört katı sonuç vermesini beklememenizdir. SMT nedeniyle üç ile üç buçuk kat arası normaldir. Buna karşılık iki katın altında kaldıysanız, ya vCPU'larınız aynı fiziksel çekirdeğin thread'leridir ya da ciddi bir paylaşım baskısı vardır.

Asıl kanıtı üreten adım ise tekrardır. Aynı testi saat başı çalıştırıp sonucu kaydedin:

# /etc/cron.d/cpu-olcum
0 * * * * root sysbench cpu --cpu-max-prime=20000 --threads=1 run 2>/dev/null | \
  awk -v d="$(date +\%F\ \%H:\%M)" '/events per second/{print d, $4}' >> /var/log/cpu-olcum.log

Bir hafta sonra dosyayı açtığınızda üç şeyden birini görürsünüz. Sayılar yüzde beşlik bir bantta sabit kalıyorsa, aldığınız kaynak istikrarlıdır ve sağlayıcı sözünü tutuyordur. Belirli saatlerde düzenli olarak düşüyorsa, komşu iş yükleriyle çakışıyorsunuz demektir — bu genelde konuşulabilir bir durumdur. Sayılar rastgele ve geniş bir aralıkta savruluyorsa, o fiziksel makine ağır biçimde aşırı satılmış demektir; ölçümü sunun, düzelme olmazsa taşınmayı planlayın.

Ölçüm Sonucuna Göre Ne Yapmalı?#

Verinin işe dönüşmesi için son bir sıralama:

1. Steal düşük, tek çekirdek testi iyi, ama sistem yine de yavaş. Sorun CPU'da değil. Disk gecikmesine (iostat -x 1), bellek yetersizliğine ve takas kullanımına (free -m, vmstat) bakın. Yavaşlığın çok büyük bölümü CPU değil G/Ç kaynaklıdır.
2. Steal düşük, ama tüm çekirdekler dolu. Gerçekten kapasiteniz bitmiş. Uygulamayı optimize edin ya da vCPU sayısını artırın; sağlayıcı değiştirmek bir şey kazandırmaz.
3. Steal yüksek ve süreklilik gösteriyor. Ölçümlerinizi tarih-saat bilgisiyle destek talebine ekleyin. Sağlayıcılar bu tür somut verilerle gelen makineleri genellikle daha az yoğun bir düğüme taşır.
4. Sonuçlar rastgele savruluyor ve düzelmiyor. Paylaşımlı modelden ayrılmış vCPU'ya geçmeyi ya da sağlayıcı değiştirmeyi değerlendirin. Yeni sağlayıcıyı seçerken aynı testleri deneme süresi içinde tekrarlayın; kararı fiyat listesine değil kendi ölçümünüze dayandırın.

Sağlayıcı seçerken bakılacak diğer başlıklar için VDS alırken nelere dikkat edilmeli listesi bu yazıdaki ölçüm alışkanlığını tamamlar. Sonuçta vCPU sayısı bir vaattir; steal time ise o vaadin tutulup tutulmadığının makbuzudur.

Sıkça Sorulan Sorular#

4 vCPU kaç fiziksel çekirdeğe denk gelir?#

Yaygın uygulamada bir vCPU bir işlemci thread'ine karşılık gelir, yani 4 vCPU genellikle 2 fiziksel çekirdeğin 4 thread'i demektir. Ancak paylaşımlı modellerde bu thread'ler başka müşterilerle de paylaşılır, dolayısıyla eldeki gerçek işlem gücü 2 fiziksel çekirdeğin altında kalabilir. Ayrılmış vCPU satan sağlayıcılarda ise 4 vCPU, size özel 4 thread anlamına gelir.

Steal time yüzde kaçın üstünde sorun sayılır?#

Kısa süreli sıçramalar normaldir; asıl bakılması gereken saatlik ortalamadır. Yüzde 1'in altı sorunsuz, yüzde 5'e kadar kabul edilebilir, yüzde 5-10 arası ölçümü sağlayıcıya iletmenizi gerektiren bir seviyedir. Yüzde 10'un üzerinde süreklilik gösteren steal, satın aldığınız işlem gücünün önemli bir kısmını fiilen kullanamadığınız anlamına gelir ve taşınma ya da yükseltme kararını gündeme getirir.

Windows sunucuda steal time nasıl görülür?#

Windows misafir işletim sistemleri Linux'taki %st metriğinin doğrudan karşılığını sunmaz. Bu ortamda pratik yöntem, sabit bir hesaplama işini düzenli aralıklarla çalıştırıp süresini kaydetmek ve zaman içindeki dalgalanmaya bakmaktır. Performans İzleyici'deki işlemci sayaçları da yardımcı olur ancak bunlar sizin kullandığınız zamanı ölçer, beklediğiniz zamanı değil.

Overselling yapan sağlayıcıdan kaçınmalı mıyım?#

Bir miktar aşırı tahsis, paylaşımlı sunucu ekonomisinin doğal parçasıdır ve tamamen kaçınmak isterseniz ayrılmış CPU ya da fiziksel sunucu fiyatlarını ödemeniz gerekir. Belirleyici olan oranın kendisi değil, sağlayıcının doluluğu izleyip izlemediğidir. Karar için tek güvenilir ölçüt, deneme süresi içinde kendi sunucunuzda aldığınız steal ve tekrarlı performans ölçümleridir.

nproc 48 gösteriyor ama 2 vCPU satın aldım, neden?#

Bu durum genellikle konteyner tabanlı sanallaştırmada (OpenVZ, LXC) görülür. Çekirdek host ile paylaşıldığı için misafir sistem host makinenin tüm mantıksal işlemcilerini listeler, oysa gerçek sınır cgroup kotasıyla uygulanır. Gerçek payınızı /sys/fs/cgroup/cpu.max dosyasından okuyabilirsiniz. Bazı uygulamalar nproc çıktısına göre iş parçacığı havuzu açtığı için bu uyumsuzluk performans sorunlarına da yol açabilir.

Daha fazla vCPU almak her zaman hızlandırır mı?#

Hayır. vCPU sayısı paralel çalışma genişliğini artırır, tek bir işin hızını artırmaz. Tek iş parçacıklı bir uygulama, sekiz vCPU'lu bir makinede iki vCPU'lu makinedekiyle aynı hızda çalışır. Ayrıca darboğaz diskte, ağda veya veritabanı sorgularındaysa CPU eklemek hiçbir kazanç sağlamaz. Yükseltmeden önce steal, disk bekleme süresi ve bellek kullanımını ölçüp darboğazın gerçekten CPU olduğunu doğrulayın.