Sanal Sunucuda CPU Ready Değeri Neden Yükselir? Teşhis ve Çözüm Rehberi

Sanal sunucuda CPU ready değeri, sanal makinenin çalışmaya hazır bir vCPU’su olduğu hâlde fiziksel CPU zamanlayıcısından sıra beklediğini gösterir. Değerin yükselmesi; uygulama gecikmeleri, yavaş yanıtlar ve anlık performans düşüşleri olarak hissedilebilir. Sorun çoğunlukla konuk işletim sisteminden değil, ESXi host üzerindeki CPU çekişmesinden, gereğinden büyük vCPU yapılandırmasından veya hatalı kaynak politikalarından kaynaklanır. Bu rehber, VMware vSphere/ESXi ortamında CPU ready artışını güvenli biçimde ölçmek, nedenini ayırmak ve uygun düzeltmeyi uygulamak için hazırlanmıştır.

CPU ready tek başına bir hata kodu değildir. Sağlıklı yorum için ölçüm aralığı, VM’nin vCPU sayısı, host yükü, CPU limitleri ve aynı anda görülen co-stop gibi metrikler birlikte değerlendirilmelidir.

CPU ready yükselmesi ne anlama gelir?

ESXi, aynı fiziksel işlemci kaynaklarını çok sayıda sanal makine arasında zamanlar. Bir VM’nin vCPU’su işlemci kullanmaya hazırdır ancak host o anda fiziksel çekirdek/iş parçacığı veremiyorsa bu bekleme süresi CPU ready olarak kaydedilir. Bu nedenle CPU kullanımının düşük olması, CPU ready sorunu olmadığı anlamına gelmez.

Örneğin uygulama içindeki istekler kısa CPU patlamaları üretiyor olabilir. VM’nin ortalama CPU kullanımı düşük görünse bile yoğun anlarda işlemci zamanlayıcısı bekleme yaratabilir.

Hızlı teşhis özeti

• Önce vCenter Performance Charts veya esxtop üzerinden VM bazında %RDY değerini inceleyin.
• Ölçümü 5 dakikalık ortalamadan ziyade sorun anındaki kısa aralıklarla karşılaştırın.
• Aynı hosttaki CPU kullanımını, CPU contention durumunu, VM CPU limitlerini ve vCPU sayısını kontrol edin.
• Yüksek %RDY ile birlikte %CSTP de yükseliyorsa fazla vCPU ataması olasılığını önceliklendirin.
• Tek VM yerine host üzerindeki birçok VM etkileniyorsa host kapasitesi, DRS dengesi veya kaynak havuzu politikalarını inceleyin.

Sanal sunucuda CPU ready değeri için pratik eşikler

CPU ready değerlendirmesi örnekleme süresine bağlıdır. Bu yüzden tek bir evrensel eşik yerine sürekli gözlem, iş yükü etkisi ve karşılaştırmalı analiz gerekir. Yine de kısa süreli zirveler dışında sürekli yüksek değerler araştırılmalıdır.

Gözlem	Olası yorum	İzlenecek yol
Tek tük kısa ready zirveleri	Geçici işlem yükü veya zamanlama dalgalanması olabilir.	Uygulama gecikmesi yoksa trendi izleyin.
Belirli saatlerde düzenli artış	Zamanlanmış iş, yedekleme, raporlama veya yoğun toplu işlem olabilir.	İş zamanlamasını ve hosttaki eşzamanlı yükleri karşılaştırın.
Bir hosttaki çok sayıda VM’de artış	Host CPU çekişmesi, DRS dengesizliği veya kapasite yetersizliği olasıdır.	Host ve küme seviyesinde yerleşim ile kaynak politikalarını inceleyin.
Yüksek ready ve yüksek co-stop	VM’ye gereğinden fazla vCPU atanmış olabilir.	İş yükünü doğrulayıp vCPU sayısını kontrollü azaltmayı değerlendirin.
Yalnızca tek VM’de sürekli artış	CPU limiti, affinity kuralı, kaynak havuzu kısıtı veya VM’ye özgü yapılandırma olabilir.	VM ayarlarını, rezervasyon/limit değerlerini ve yerleşimi kontrol edin.

vCenter grafiklerindeki ready ölçümü genellikle milisaniye toplamı olarak sunulabilir; esxtop ise doğrudan yüzde değerleri gösterir. Aynı ölçü birimini kullanmadan sonuçları karşılaştırmayın.

CPU ready neden yükselir?

Host üzerinde CPU oversubscription ve eşzamanlı yoğunluk

Hosta, fiziksel CPU kapasitesinin kaldırabileceğinden fazla aktif vCPU yerleştirildiğinde tüm VM’ler aynı anda işlemci istemeye başlayabilir. vCPU/pCPU oranı tek başına kesin karar verdirmez; veritabanı, derleme, şifreleme veya yüksek istekli uygulamalar gibi eşzamanlı CPU tüketen iş yükleri daha erken çekişme oluşturabilir.

Gereğinden fazla vCPU atanması

Bir VM’ye ihtiyaçtan fazla vCPU vermek her zaman performansı artırmaz. Çok vCPU’lu VM’lerde zamanlayıcının uygun kaynakları koordine etmesi zorlaşabilir. Özellikle CPU kullanımı düşük kalmasına rağmen co-stop yükseliyorsa, VM boyutlandırması iş yüküyle uyumsuz olabilir.

CPU limitleri, shares ve kaynak havuzu kısıtları

VM veya resource pool üzerinde tanımlı CPU limiti, hostta boş kapasite bulunsa dahi VM’yi yapay olarak kısıtlayabilir. Shares değerleri ise çekişme anında önceliklendirmeyi etkiler. Düşük share değeri tek başına sorun değildir; ancak yoğunluk altında kritik iş yüklerinin yeterli pay alamamasına neden olabilir.

DRS yerleşimi, affinity kuralları ve dengesiz host yükü

Küme genelinde boş kapasite varken belirli hostun dolu kalması, DRS ayarları, bakım durumu, VM/host affinity kuralları veya manuel yerleşimden kaynaklanabilir. VM’yi zorla belirli bir hostta tutan kurallar, dengeleme seçeneklerini daraltır.

Fiziksel host veya güç yönetimi etkileri

Host BIOS/UEFI ve ESXi güç yönetimi politikaları işlemci frekansını ve gecikmeye tepkiyi etkileyebilir. Ayrıca hosttaki donanım uyarıları, termal sınırlama veya diğer altyapı sorunları araştırılmalıdır. Ancak bu ayarları değiştirmeden önce üretici dokümantasyonu, kurum standardı ve bakım planı dikkate alınmalıdır.

Log ve teşhis: ESXi üzerinde CPU ready nasıl ölçülür?

Yapılandırma değiştirmeden önce en az bir sorun dönemi için kanıt toplayın. ESXi Shell veya SSH erişimini kurum güvenlik politikanıza uygun olarak geçici biçimde kullanın. Komutlar VMware ESXi host üzerinde çalıştırılır; konuk Linux ya da Windows işletim sisteminde esxtop bulunmaz.

esxtop ile anlık VM görünümü

Hosta bağlandıktan sonra aşağıdaki komutu çalıştırın:

esxtop

CPU ekranına geçmek için c tuşuna basın. VM satırlarında özellikle %RDY, %CSTP, %USED ve %MLMTD alanlarını inceleyin. Gerekli alanlar görünmüyorsa f ile alan seçimini açın. Birkaç saniyelik tek kare yerine, sorun yaşanırken birkaç dakika gözlem yapın.

%MLMTD sıfırdan yüksekse CPU limitinin VM’yi sınırladığını gösterir. Bu durumda doğrudan vCPU eklemek doğru çözüm değildir; önce limiti ve bu limitin neden tanımlandığını inceleyin.

Batch çıktı ile zaman damgalı kayıt alma

İnceleme için sınırlı süreli bir örnek toplamak isterseniz ESXi hostta aşağıdaki komut kullanılabilir:

esxtop -b -d 2 -n 300 > /tmp/esxtop-cpu.csv

Bu örnek 2 saniye aralıkla 300 kayıt alır ve yaklaşık 10 dakika sürer. /tmp geçici bir alandır; host yeniden başlatıldığında veya geçici dosyalar temizlendiğinde çıktı kaybolabilir. Analizden sonra dosyayı kurumunuzun güvenli yönetim istasyonuna taşıyın ve erişim kayıtları ile saklama politikanıza uyun.

Host CPU kullanımını doğrulama

ESXi Shell üzerinde genel CPU durumunu görmek için:

esxcli hardware cpu global get

Bu çıktı CPU topolojisi ve kullanılabilir mantıksal işlemci sayısı hakkında bilgi verir; anlık çekişmeyi tek başına göstermez. Anlık analizde esxtop, geçmiş eğilimlerde ise vCenter performans grafikleri esas alınmalıdır.

Güvenli adım adım çözüm planı

VM donanımı, DRS kuralları, kaynak havuzu ve güç politikası değişiklikleri hizmet davranışını etkileyebilir. Üretim ortamında değişiklik öncesinde güncel yedek veya geri dönüş planını doğrulayın, değişikliği bakım penceresinde uygulayın ve sorumlu ekipleri bilgilendirin. Snapshot, uzun süre tutulduğunda performans ve alan riski yaratabileceğinden genel amaçlı yedek yerine geçmez.

1. Sorunu iş yüküyle ilişkilendirin

CPU ready zirvelerinin zamanını uygulama yanıt süresi, işletim sistemi CPU kuyrukları, toplu işler, yedekleme pencereleri ve izleme alarmlarıyla eşleştirin. Konuk işletim sisteminde CPU kullanımı yüksek görünmese bile host kaynak çekişmesi yaşanabilir. Amaç, sorun anının gerçekten kullanıcı etkisi oluşturup oluşturmadığını belirlemektir.

2. CPU limiti ve kaynak havuzu ayarlarını denetleyin

vSphere Client içinde VM yapılandırmasındaki CPU limitini ve VM’nin üyesi olduğu resource pool ayarlarını kontrol edin. Gerekçesi olmayan bir limit varsa, değişikliğin etkisini planlayarak kaldırın veya iş yükünün ihtiyacına uygun değere getirin. Kritik bir VM’nin shares ayarını yükseltmek, yalnızca çekişme sırasında öncelik sağlar; fiziksel kapasite oluşturmaz.

3. vCPU sayısını ölçerek doğru boyutlandırın

Yüksek co-stop, düşük gerçek CPU kullanımı ve sürekli ready birlikte görülüyorsa VM’nin vCPU sayısını değerlendirin. Örneğin uygulama çoğu zaman az sayıda iş parçacığı kullanıyorsa, büyük vCPU yapılandırması gereksiz zamanlama maliyeti doğurabilir.

vCPU azaltma çoğu işletim sistemi ve sanal donanım yapılandırmasında VM kapalıyken yapılır. Bu nedenle önce uygulama bağımlılıklarını, bakım penceresini ve geri dönüş adımını planlayın. Değişikliği küçük bir kademe ile yapın; ardından aynı iş yükünde ready, co-stop ve uygulama gecikmesini karşılaştırın. Kanıt olmadan CPU eklemekten veya büyük ölçekli azaltım yapmaktan kaçının.

4. Host ve küme dengesini düzeltin

Birden çok VM aynı hostta etkileniyorsa DRS önerilerini, host CPU kullanım eğilimlerini ve affinity kurallarını gözden geçirin. Uygunsa VM’yi daha az yoğun bir hosta vMotion ile taşımak kısa vadeli rahatlama sağlayabilir. vMotion öncesinde ağ, lisans, paylaşımlı depolama ve uyumluluk koşullarının ortamınızda sağlandığını doğrulayın.

Affinity kurallarını kaldırmak ya da değiştirmek, yüksek erişilebilirlik ve uygulama mimarisi tasarımını etkileyebilir. Kuralın hangi bağımlılık için konduğunu anlamadan değişiklik yapmayın.

5. Kapasite yetersizse kalıcı plan oluşturun

Hostların çoğu uzun süre yoğun çalışıyor ve DRS anlamlı bir dengeleme yapamıyorsa sorun ayardan çok kapasite olabilir. İş yüklerini farklı hostlara dağıtmak, kümeye kapasite eklemek veya CPU yoğun iş yükünü uygun fiziksel altyapıya taşımak değerlendirilmelidir. Bu aşamada CPU modeli, çekirdek sayısı, frekans davranışı ve lisans etkileri birlikte planlanmalıdır.

Çözümü nasıl doğrularsınız?

Her değişiklikten sonra aynı yoğunluk döneminde aşağıdaki karşılaştırmayı yapın:

• esxtop içinde etkilenen VM’nin %RDY, %CSTP ve %MLMTD değerlerini yeniden kaydedin.
• vCenter geçmiş grafiklerinde değişiklik öncesi ve sonrası aynı zaman aralığını karşılaştırın.
• Uygulamanın yanıt süresi, zaman aşımı, iş kuyruğu ve işletim sistemi performans sayaçlarını kontrol edin.
• Hosttaki diğer VM’lerde yeni bir ready artışı oluşmadığından emin olun.
• Değişiklik beklenen sonucu vermezse, belgelenmiş geri dönüş planını uygulayın.

Sanal sunucuda CPU ready değeri düşerken uygulama gecikmesi sürüyorsa kök neden ağ, depolama gecikmesi, bellek baskısı veya uygulama/veritabanı katmanı olabilir. Bu durumda CPU metriklerini tek başına kesin neden kabul etmeyin.

CPU ready artışını önleme

• Yeni VM’leri varsayılan olarak büyük vCPU sayısıyla kurmak yerine, iş yükü ölçümüne göre boyutlandırın.
• Host ve küme için CPU kullanımını, ready ve co-stop eğilimlerini düzenli izleyin.
• CPU limiti, shares, rezervasyon ve affinity kurallarını gerekçesiyle birlikte kayıt altında tutun.
• Yedekleme, antivirüs taraması, raporlama ve toplu işlem gibi CPU yoğun görevleri mümkün olduğunda farklı zamanlara dağıtın.
• Kapasite planlamasını ortalama kullanıma değil, eşzamanlı tepe yüküne ve uygulamanın gecikme hassasiyetine göre yapın.

Sonuç

Sanal sunucuda CPU ready değeri yükseldiğinde ilk hedef daha fazla vCPU atamak olmamalıdır. Önce ready değerini doğru ölçün; CPU limiti, co-stop, host çekişmesi ve küme yerleşimini birlikte değerlendirin. Kanıta dayalı küçük değişiklikler, bakım penceresi ve değişiklik sonrası doğrulama; performans sorununu yeni bir kesinti oluşturmadan azaltmanın en güvenli yoludur.

Sık sorulan sorular

CPU ready ile CPU usage arasındaki fark nedir?

CPU usage, VM’nin fiilen kullandığı işlemci süresidir. CPU ready ise VM çalışmaya hazır olduğu hâlde fiziksel CPU için beklediği süredir. Bu nedenle düşük usage ile yüksek ready aynı anda görülebilir.

CPU ready yüksekse VM’ye daha fazla vCPU eklemeli miyim?

Hayır. Fazla vCPU, zamanlama baskısını ve co-stop değerini artırabilir. Önce CPU limiti, host çekişmesi, mevcut vCPU kullanımı ve co-stop ölçülmelidir.

Yüksek CPU ready yalnızca VM içinden anlaşılabilir mi?

Hayır. Konuk işletim sistemi gecikme belirtileri gösterebilir ancak CPU ready hypervisor zamanlama metriğidir. Kesin ölçüm için vCenter performans grafikleri veya ESXi üzerindeki esxtop kullanılmalıdır.

CPU ready ile co-stop aynı şey midir?

Hayır. CPU ready, çalışmaya hazır vCPU’nun fiziksel CPU beklemesidir. Co-stop ise çok vCPU’lu VM’lerde vCPU’ların eşgüdümüyle ilişkili bekleme göstergesidir. Birlikte yükselmeleri, vCPU boyutlandırmasının incelenmesi gerektiğine işaret edebilir.

CPU limitini kaldırmak her zaman güvenli midir?

Hayır. Limit, başka iş yüklerini korumak veya lisans/kapasite politikası için tanımlanmış olabilir. Kaldırmadan önce nedenini, host kapasitesini ve diğer VM’lere etkisini değerlendirin.