32 fiziksel çekirdeği olan bir host'ta, her birine 4 vCPU verilmiş 20 sanal makine çalışıyor. Basit matematik: 80 vCPU dağıtılmış ama ortada 32 çekirdek var. Buna CPU overcommit — yani işlemcinin fazla dağıtılması — deniyor ve sanallaştırmanın temel ekonomisi tam olarak buna dayanıyor. Sorun şu ki bu oran belli bir noktadan sonra sessizce zarar vermeye başlıyor: sanal makinelerin CPU kullanımı normal görünüyor, kimse yüzde yüzde takılmıyor, ama uygulamaların yanıt süresi ikiye katlanıyor ve sebebini kimse bulamıyor.
Bu yazıda vCPU'nun fiziksel çekirdeğe gerçekte nasıl bölündüğünü, aşırı dağıtımın hangi orana kadar güvenli olduğunu, en önemlisi de zararın hangi metrikle ölçüldüğünü anlatacağım. CPU kullanım yüzdesine bakarak bu sorunu göremezsin; bakman gereken şey CPU ready ve steal time. Hem sunucu sahibi hem sanal sunucu kiralayan taraf için ölçüm komutlarını, güvenli oran tablolarını ve doğru boyutlandırma kurallarını vereceğim.
CPU Overcommit Nedir#
Sanal bir makineye "4 vCPU" verdiğinde ona dört fiziksel çekirdek ayırmış olmazsın. vCPU, hipervizörün zamanlayıcısına sunulan çalıştırılabilir bir birimdir; hipervizör bu birimleri fiziksel çekirdekler üzerinde zaman dilimlerine bölerek sırayla çalıştırır. Tıpkı bir işletim sisteminin onlarca süreci birkaç çekirdek üzerinde paylaştırması gibi.
Bu model işe yarar çünkü sanal makineler hiçbir zaman aynı anda hepsi tam kapasite çalışmaz. Tipik bir sunucu filosunda makinelerin ortalama CPU kullanımı yüzde on ile yirmi arasındadır; geri kalan zamanda vCPU'lar boştadır ve o çekirdek başka bir makinenin işine ayrılabilir. Aşırı dağıtım, bu boş zamanı satmaktır ve dürüstçe yapıldığında herkes kazanır: host verimli kullanılır, maliyet düşer, kimse fark etmez.
Sorun, dağıtılan vCPU'ların aynı anda çalışmak istemesiyle başlar. Bir vCPU çalışmaya hazır olduğu hâlde boş fiziksel çekirdek bulamazsa bekler. Bu bekleme misafir işletim sistemine "CPU meşguldü" olarak görünmez; misafir zamanın kaybolduğunun farkında bile değildir. İçeride yalnızca şunu görürsün: aynı iş dün 200 milisaniyede bitiyordu, bugün 600 milisaniyede bitiyor, CPU kullanımı ise hâlâ yüzde 30.
Overcommit Oranı ve Güvenli Aralıklar#
Oran basit bir bölme işlemidir:
# Host'ta dağıtılmış toplam vCPU / fiziksel çekirdek sayısı
# Örnek: 80 vCPU dağıtılmış, 32 fiziksel çekirdek varsa oran 2.5:1
# Linux host'ta fiziksel çekirdek ve iş parçacığı sayısını gör
lscpu | grep -E "^CPU\(s\)|Core\(s\) per socket|Socket\(s\)|Thread"
Burada ilk tuzak SMT (hyper-threading) ile ilgilidir. lscpu sana mantıksal iş parçacığı sayısını gösterir; 16 çekirdekli bir sunucu 32 mantıksal CPU olarak görünür. Ancak bir iş parçacığı, fiziksel bir çekirdeğin tam kapasitesi değildir — kabaca ek yüzde 20-30 verim getirir. Oran hesabını fiziksel çekirdek üzerinden yaparsan gerçeğe daha yakın durursun.
İş yüküne göre pratikte kullandığım aralıklar şöyle:
| İş yükü tipi | Önerilen oran | Neden |
|---|---|---|
| Gecikmeye duyarlı (veritabanı, gerçek zamanlı) | 1:1 – 2:1 | Bekleme doğrudan yanıt süresine yansır |
| Genel amaçlı üretim sunucuları | 2:1 – 4:1 | Tepe yükler örtüşmediği sürece güvenli |
| Web/uygulama sunucuları (dalgalı yük) | 3:1 – 5:1 | Boş zaman bol, tepe kısa |
| Geliştirme ve test | 5:1 – 8:1 | Yavaşlık tolere edilebilir |
| Nadiren kullanılan yardımcı makineler | 8:1 ve üzeri | Çoğu zaman boşta |
Bu tablo bir kural değil başlangıç noktasıdır. Gerçek sınırı belirleyen şey oran değil, ölçtüğün bekleme süresidir. 6:1 oranda gayet iyi çalışan bir host görebilirsin; 2:1 oranda tıkanan bir host da görebilirsin, çünkü oradaki makineler her sabah dokuzda aynı anda tepe yapıyordur.
Riskin Ölçüsü: CPU Ready ve Steal Time#
Aşırı dağıtımın zararını ölçen iki metrik var ve hangisine bakacağın hangi taraftan baktığına bağlı.
CPU Ready — Hipervizör tarafından ölçülür. Bir vCPU'nun çalışmaya hazır olduğu hâlde fiziksel çekirdek bekleyerek geçirdiği süredir. VMware dünyasında %RDY olarak görünür.
Steal time — Misafir işletim sistemi tarafından ölçülür. Aynı olgunun içeriden görünen hâlidir: "hipervizör benden zaman çaldı." Linux'ta top ve vmstat çıktısındaki st sütunudur. Sanal sunucu kiralayan biri olarak host'a erişemezsin ama bunu görebilirsin — bu yüzden kiracı tarafında en değerli metriktir.
| Metrik | Nerede görülür | Sağlıklı | Dikkat | Sorun |
|---|---|---|---|---|
%RDY (vCPU başına) | esxtop, vCenter | %5 altı | %5 – %10 | %10 üstü |
%CSTP (eş zamanlama) | esxtop | %3 altı | %3 – %5 | %5 üstü |
%st (steal) | misafir içinde top, vmstat | %2 altı | %2 – %5 | %5 üstü, sürekli |
Bu eşikler sektörde yaygın kabul gören başlangıç değerleridir; kendi ortamında normal aralığı bir süre ölçüp kendi taban çizgini oluşturman en doğrusudur. Önemli olan mutlak sayı değil, eğilimdir: steal time'ın haftalar içinde yüzde birden yüzde altıya çıkması, host'un giderek doldurulduğunun en net göstergesidir.
Ölçüm: Misafir ve Host Tarafında Komutlar#
Misafir işletim sistemi içindesin ve sunucunun neden yavaşladığını anlamaya çalışıyorsun. Şu komutlarla başla:
# vmstat: en sağdaki 'st' sütunu steal time'dır
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 812345 91234 445566 0 0 3 12 210 380 8 2 85 0 5
# ^^^^
# top içinde %Cpu satırındaki 'st' değerine bak
top -bn1 | head -5
# Çekirdek başına ayrıntılı görünüm (sysstat paketi gerekir)
mpstat -P ALL 1 5
# Geçmişe dönük eğilim (sysstat toplama açıksa)
sar -u 1 5
st değeri sürekli yüzde 5'in üzerindeyse, sunucun kendi işini yapamıyor demektir — CPU'yu sen değil, komşuların tüketiyor. Bu, uygulama kodunda arayacağın bir sorun değildir.
Host tarafındaysan ve hipervizöre erişimin varsa daha net bir resim görürsün:
# KVM / Proxmox host'ta canlı sanal makine CPU görünümü
virt-top
# Bir makinenin zamanlayıcı ayarlarını gör
virsh schedinfo lab-web01
# Host genelinde çalışma kuyruğu uzunluğu ('r' sütunu çekirdek sayısını
# sürekli aşıyorsa CPU darboğazı vardır)
vmstat 1 10
VMware tarafında ölçüm aracı esxtop'tur: SSH ile host'a bağlanıp esxtop çalıştırır, c tuşuyla CPU görünümüne geçer ve %RDY ile %CSTP sütunlarına bakarsın. Bir makinenin %RDY değerini yorumlarken vCPU sayısına bölmeyi unutma; 4 vCPU'lu bir makinede görünen %20, vCPU başına %5 demektir.
Co-Scheduling Tuzağı: Çok vCPU Neden Yavaşlatır#
Burası, sezgiye en aykırı gelen ve en çok zarar veren konu. Genel eğilim şudur: makine yavaşsa vCPU sayısını artır. Aşırı dağıtılmış bir host'ta bu, durumu kötüleştirir.
Sebebi çok işlemcili sanal makinelerin zamanlanma biçimidir. Bir sanal makinenin vCPU'ları misafir işletim sistemine paralel çalışan gerçek çekirdekler gibi görünür; bunların birbirinden çok fazla geri kalmaması gerekir, yoksa misafirin kendi kilit ve senkronizasyon mekanizmaları bozulur. Bu yüzden hipervizör, çok vCPU'lu makinelerin vCPU'larını kabaca birlikte ilerletmeye çalışır.
Sonuç şu: 8 vCPU'lu bir makinenin çalışabilmesi için hipervizörün aşağı yukarı aynı anda 8 boş çekirdek bulması gerekir. Yoğun bir host'ta 2 boş çekirdek bulmak kolay, 8 boş çekirdek bulmak zordur. Böylece 8 vCPU'lu makine, ihtiyacı olmadığı hâlde daha uzun kuyrukta bekler ve 2 vCPU'lu komşusundan daha yavaş çalışır.
Pratik kural: sanal makineye gerçekten kullandığı kadar vCPU ver. Yeni bir makineyi 2 vCPU ile başlat, bir hafta ölç, gerçekten sürekli tepede takılıyorsa artır. Kullanmadığı vCPU, makineye hiçbir şey kazandırmaz ama hem kendisine hem tüm host'a bekleme maliyeti bindirir.
Doğru Boyutlandırma ve Sınırlama Araçları#
Ölçtükten sonra elinde üç tür müdahale aracı var:
Pay (shares / weight) — Kaynak kıtlığı olduğunda kimin önce koşacağını belirler. Kıtlık yokken hiçbir etkisi olmaz. Kritik makinelere daha yüksek pay vermek en zararsız ve en etkili ayardır.
Rezervasyon (reservation) — Bir makineye belirli miktarda CPU'yu garanti eder. Gecikmeye duyarlı tek bir makine için değerlidir; ama her makineye rezervasyon verirsen aşırı dağıtımın tüm faydasını ortadan kaldırırsın.
Sınır (limit) — Bir makinenin kullanabileceği CPU'ya tavan koyar. Komşuları ezen bir makineyi frenlemek için kullanılır, ancak dikkatli ol: sınıra takılan makine, host boşken bile hızlanamaz ve teşhisi zor bir yavaşlık yaratır.
# Proxmox / KVM: pay ve tavan ayarı
qm set 100 --cpuunits 2048 # varsayılan 1024, bu makineye iki kat pay
qm set 100 --cpulimit 2 # en fazla 2 çekirdek kadar kullanabilsin
# libvirt tarafında aynı ayarlar
virsh schedinfo lab-web01 --set cpu_shares=2048 --live
virsh schedinfo lab-web01 --set vcpu_quota=200000 --live
# Belirli vCPU'ları belirli fiziksel çekirdeklere sabitle (CPU pinning)
virsh vcpupin lab-web01 0 4
virsh vcpupin lab-web01 1 5
CPU sabitleme (pinning) ve NUMA hizalaması, gecikmeye çok duyarlı iş yüklerinde son basamaktır. Faydası gerçektir ama esnekliği öldürür: sabitlenmiş bir makine artık serbestçe zamanlanamaz ve canlı göç seçenekleri daralır. Önce boyutlandırmayı düzelt, sonra payları ayarla; sabitlemeye ancak ölçülmüş bir ihtiyaç varsa geç.
Bir de kaynak planında sık unutulan bir kalem var: iç içe sanallaştırma yapıyorsan tüm bu etkiler iki kat hissedilir, çünkü dış katman da paylaşılan bir kaynak üzerinde çalışır. Ayrıntısı için nested virtualization nedir ve sanal makinede sanal makine çalıştırma yazılarına bakabilirsin.
Sık Yapılan Hatalar#
CPU kullanım yüzdesine bakıp "sorun yok" demek. Aşırı dağıtımın zararı kullanım yüzdesinde görünmez; ready ve steal metriklerinde görünür. Yanlış metriğe bakmak, sorunun aylarca teşhis edilememesinin bir numaralı sebebidir.
Yavaşlık şikâyetine vCPU ekleyerek cevap vermek. Yoğun bir host'ta bu, makineyi daha da yavaşlatır. Önce ready/steal ölç; sorun beklemeyse çözüm vCPU eklemek değil, host'u rahatlatmaktır.
Belleği de CPU gibi fazla dağıtmak. CPU zaman paylaşımıyla bölünebilir, bellek bölünemez. Bellekte aşırı dağıtım takas ve balon mekanizmalarını devreye sokar; sonuç CPU aşırı dağıtımından çok daha sert bir performans çöküşüdür. Bellekte ihtiyatlı ol.
Tepe yüklerin örtüştüğünü hesaba katmamak. Ortalama kullanıma göre planlarsan, herkesin aynı anda çalıştığı sabah dokuzda host tıkanır. Planı ortalamaya değil, örtüşen tepe yüke göre yap.
Her makineye rezervasyon vermek. Bu, aşırı dağıtımı tamamen iptal eder ve host kapasitesini kâğıt üzerinde tüketir. Rezervasyonu yalnızca gerçekten kritik ve gecikmeye duyarlı makinelerde kullan.
Ölçüm geçmişi tutmamak. Bugünkü steal time değeri tek başına bir şey söylemez. Eğilimi görmek için sürekli toplanan bir izleme kurgusuna ihtiyacın var; sorun ortaya çıktığında geriye dönüp bakabilmek teşhis süresini günlerden dakikalara indirir.
Sıkça Sorulan Sorular#
Overcommit oranı kaç olmalı#
Tek bir doğru sayı yok; iş yükünün karakterine bağlı. Gecikmeye duyarlı veritabanı sunucularında 1:1 ile 2:1 arasında kalmak, genel amaçlı üretim sunucularında 2:1 – 4:1, geliştirme ve test ortamlarında 5:1 – 8:1 makul başlangıç noktalarıdır. Ama asıl kural şu: oranı değil, ölçtüğün bekleme metriklerini takip et. Ready ve steal değerleri düşükse oran senin ortamın için uygundur.
Steal time yüksekse ne yapmalıyım#
Steal time, host'un fazla dolu olduğunun göstergesidir ve kendi sunucunun içinde çözebileceğin bir şey değildir. Kendi host'unun sahibiysen makine sayısını azaltman, vCPU dağıtımını küçültmen ya da kritik makinelere daha yüksek pay vermen gerekir. Sanal sunucu kiralıyorsan ölçtüğün değerleri sağlayıcına bildir; kalıcı olarak yüksekse daha az yoğun bir host'a taşınma ya da ayrılmış kaynak sunan bir ürüne geçme zamanı gelmiştir.
vCPU sayısını artırmak makineyi hızlandırır mı#
Yalnızca uygulaman gerçekten paralel çalışıyorsa ve mevcut vCPU'lar sürekli doluysa. Aksi hâlde çok vCPU'lu makineler, hipervizörün aynı anda o kadar boş çekirdek bulmasını gerektirdiği için daha uzun bekler ve yavaşlar. Yeni bir makineyi az vCPU ile başlatıp ölçerek artırmak, en baştan bol vCPU vermekten neredeyse her zaman daha iyi sonuç verir.
Hyper-threading çekirdek sayısına dahil edilir mi#
Mantıksal iş parçacıkları zamanlama açısından fazladan kapasite sağlar ama fiziksel bir çekirdeğe eşdeğer değildir; ek kazanç iş yüküne göre değişir ve genellikle mütevazıdır. Aşırı dağıtım oranını hesaplarken fiziksel çekirdek sayısını temel almak seni gerçeğe daha yakın tutar. İş parçacıklarını tam çekirdek sayarsan kâğıt üzerinde güvenli görünen bir oran, pratikte tıkanan bir host üretir.
Bulut sunucularında bu sorun var mı#
Paylaşımlı kaynak modelinde çalışan her üründe aşırı dağıtım vardır — sanallaştırmanın ekonomisi buna dayanır. Fark, sağlayıcının oranı ne kadar sıkı tuttuğunda ve ayrılmış (dedicated) kaynak seçeneği sunup sunmadığındadır. Kiracı olarak yapman gereken, steal time'ı düzenli ölçmek ve sürekli yüksekse harekete geçmektir. Kaynak modelleri arasındaki farkı bulut sunucu mu VDS mi yazısında karşılaştırdım.
CPU sınırı koymak iyi bir fikir mi#
Komşularını ezen tek bir makineyi frenlemek için işe yarar, ama genel bir politika olarak kullanma. Sınıra takılan bir makine, host tamamen boşken bile hızlanamaz; kullanıcı "sunucu yavaş" der, sen host'a bakarsın ve her şey boş görünür. Teşhisi en zor performans sorunlarından biri budur. Önce pay ayarlarını dene, sınırı son çare olarak ve mutlaka belgeleyerek uygula.
Kapanış#
CPU overcommit, sanallaştırmanın ekonomisini mümkün kılan şeydir ve doğru yönetildiğinde kimse varlığını fark etmez. Aklında kalması gereken dört şey: zararı CPU kullanım yüzdesinde değil, ready ve steal metriklerinde ara; sanal makinelere gerçekten kullandıkları kadar vCPU ver, çünkü fazla vCPU makineyi yavaşlatır; belleği asla CPU gibi fazla dağıtma; ve planlamayı ortalama kullanıma değil, örtüşen tepe yüke göre yap.
Ölçtüğün steal time sürekli yüksekse ya da iş yükün kaynak paylaşımına tahammül etmiyorsa, ayrılmış kaynağa geçmenin zamanı gelmiş demektir. VDS paketlerimiz size özel ayrılmış kaynakla gelir, tam donanım kontrolü istiyorsan dedicated sunucu tarafına bakabilirsin. Dalgalı yükler için esnek ölçeklenen bulut sunucu seçeneğimiz uygundur; performans izlemesini ve kapasite planlamasını bize bırakmak istersen sunucu yönetimi hizmetimiz bu işi üstlenir.