CPU Ready, aşina olmayabileceğiniz bir şeydir. İlk izlenimde kulağa iyi bir şey gibi gelebilir ama maalesef öyle değil. CPU Ready, ne olduğunu bildiğimizden daha uzun süredir sanal ortamları rahatsız ediyor. VMware bunu “Sanal makinenin hazır olduğu, ancak fiziksel CPU'da çalışmak üzere programlanamadığı zamanın yüzdesi olarak tanımlar. CPU Hazır süresi, ana bilgisayardaki sanal makinelerin sayısına ve bunların CPU yüklerine bağlıdır. ' Hyper-V kısa süre önce bu sayacı sağlamaya başladı (Hyper-V Hiper Yönetici Sanal işlemci Gönderim başına CPU Bekleme süresi) ve diğer hipervizörler hala bu ölçüyü sağlamayabilir.
CPU Ready'nin ne olduğunu anlamak için, hipervizörlerin sanal CPU'ları (vCPU) fiziksel CPU'lara (pCPU) nasıl programladığını anlamamız gerekecek. Bir sanal makinede vCPU süresi gerektiğinde, komutların / işlemlerin / iş parçacıklarının pCPU'ya karşı çalışabilmesi için vCPU'larının pCPU'lara göre programlanması gerekir. İdeal bir dünyada, bunun olması gerektiğinde kaynak çatışmaları veya darboğazlar yoktur. Tek bir vCPU sanal makinesinin bir pCPU'ya göre zaman planlaması gerektiğinde, bir pCPU çekirdeği kullanılabilir ve bu ideal dünyada CPU Hazır çok azdır. CPU Ready'nin her zaman var olduğunu ancak ideal bir dünyada çok az olduğunu ve fark edilmediğini unutmamak önemlidir.
Gerçek dünyada, sanallaştırmanın avantajlarından biri, VM'lerinizin çoğunun tüm vCPU'larını aynı anda yükseltmeyeceğine bahse girebilmenizdir ve çok düşük kullanımlı VM'ler ise, ne kadar yapabileceğiniz konusunda tahminlerde bile bulunabilirsiniz. Fiziksel ana makinenizi CPU kullanımı ve RAM kullanımına göre yükleyin. Geçmişte, iş yüküne bağlı olarak 4 vCPU'dan 1 pCPU'ya veya hatta 10: 1 oranına sahip olma önerileri yapılmıştır. Örneğin, tek bir dört çekirdekli işlemciniz olabilir, ancak her biri size 16 vCPU ila 4 pCPU veya 4: 1 verecek vCPU'lara sahip 4 VM'niz olabilir. Mühendislerin görmeye başladığı şey, ortamların çok yavaş olduğu ve nedenini çözemedikleriydi. RAM kullanımı iyi görünüyordu, fiziksel ana bilgisayarlarda CPU kullanımı% 20'nin altında çok düşük olabilir. Depolama gecikmesi son derece düşüktü, ancak VM'ler son derece yavaştı.
Bu senaryoda olan şey CPU Ready idi. Programlanmaya hazır vCPU'nun bir kuyruğu oluştu, ancak programlanacak pCPU yok. Hiper yönetici zamanlamayı geciktirir ve konuk VM için gecikmeye neden olur. Son yıllara kadar tespit edilecek çok fazla aracın olmaması sessiz bir katildir. Bir Windows sanal makinesinde, önyükleme yapmak sonsuza kadar sürer ve sonunda başladıktan sonra, başlat menüsünü tıkladığınızda ortaya çıkması sonsuza kadar sürer. Hatta ilk tıklamanızı kabul etmediğini düşünerek tekrar tıklayabilirsiniz ve nihayet yakaladığında çift tıklama alırsınız. Linux'ta, sanal makineniz salt okunur kipte önyüklenebilir veya dosya sistemlerini daha sonra bir noktada salt okunur kipine geçirebilir.
Peki CPU Ready ile nasıl mücadele edeceğiz? Yardımcı olabilecek birkaç yol var. Birincisi, CPU Ready ölçümlerini izlemektir. VMware'de% 10'un üzerine çıkılması tavsiye edilmiyor ancak kişisel deneyimde kullanıcılar, VM'nin türüne ve ne çalıştığına bağlı olarak% 5-7'nin üzerinde fark etmeye başlıyor.
Aşağıda, CPU'ya Hazır olduğunu göstermek için VMware ESXi 5.5'ten bazı örnekler kullanacağım. Komut satırını kullanarak 'esxtop' komutunu çalıştırın. CPU görünümü için 'c' ye basın ve ' % RDY 'CPU Ready için. Büyük harfle basabilirsiniz ' V Yalnızca Sanal Makine görünümü için.
Burada, oldukça kullanılmayan bir ortam için% RDY'nin biraz yüksek olduğunu görebilirsiniz. Bu durumda, ESXi 5.5'im VMware Fusion (Mac hipervizör) üzerinde bir test sanal makinesi çalıştırıyor, bu nedenle bir sanal makine üzerinde başka bir hiper yönetici üzerinde bir sanal makine çalıştırdığımız için üst uçta biraz olması bekleniyor.
VSphere istemcisinde, belirli VM'yi açıp Performans sekmesine tıklayabilirsiniz. Oradan 'Grafik Seçenekleri' ni tıklayın
Grafik Seçenekleri içinde, CPU, Gerçek Zamanlı'yı seçin (vCenter'ınız varsa, gerçek zamandan başka zamanlama seçenekleriniz olabilir). Oradan, Sayaçlarda 'Hazır' ı seçin. Görünüm herhangi bir zamanda yalnızca iki veri türüne izin verdiğinden, farklı bir sayacın seçimini kaldırmanız gerekebilir.
Bu değerin bir yüzdeye karşı hazır değerinin bir özeti olduğunu fark edeceksiniz. Özetlenmiş metriklerin yüzdeye nasıl dönüştürüleceğiyle ilgili bir VMware KB makalesine bağlantı. - https://kb.vmware.com/kb/2002181
Donanım satın alırken, daha fazla çekirdek, CPU Ready'nin etkisini azaltmaya yardımcı olur. Hyperthreading de yardımcı olur. Hyperthreading, her birincil çekirdek için tam bir ikinci çekirdek sağlamazken, genellikle vCPU'nun pCPU'ya planlanmasına izin vermek ve sorunu hafifletmeye yardımcı olmak için yeterlidir. Hipervizörler vCPU'dan pCPU oranı önerisine geçmeye başlasa da, genellikle 4: 1 ile orta derecede kullanılan bir ortamda başarılı olabilir ve oradan gidebilirsiniz. Sanal makineleri yüklemeye başladığınızda CPU gecikmesine, CPU'ya Hazırlığa ve genel his ve performansa bakın. Ağır vuruş yapan sanal makineleriniz varsa, onları diğer kümelere ayırmak ve daha düşük bir oran kullanmak ve hafif tutmak isteyebilirsiniz. Öte yandan, performansın önemli olmadığı ve yavaş çalışmasının uygun olduğu VM'ler için çok daha yüksek abone olabilirsiniz.
VM'leri uygun şekilde boyutlandırmak, CPU Ready ile mücadele etmek için de büyük bir araçtır. Birçok satıcı, sanal makinenin gerçekte ihtiyaç duyabileceği özelliklerin çok üzerinde spesifikasyonlar önerir. Geleneksel olarak daha fazla CPU ve daha fazla çekirdek = daha fazla güç. Sanal bir ortamdaki sorun, hipervizörün tüm vCPU'ları yaklaşık olarak aynı zamanda pCPU'lara programlaması gerektiğidir ve pCPU'ları kilitlemek sorunlu olabilir. 8 vCPU sanal makineniz varsa, aynı anda programlamalarına izin vermek için 8 pCPU'yu kilitlemeniz gerekir. VCPU sanal makineniz herhangi bir zamanda toplam vCPU'ların yalnızca% 10'unu kullanıyorsa, vCPU geri sayımını 2 veya 4'e getirmeniz daha iyi olur. Bir sanal makineyi% 50-80 CPU'da% 10'dan daha az vCPU ile çalıştırmak daha iyidir daha fazla vCPU. Bu sorun kısmen, işletim sistemi CPU zamanlayıcısının olabildiğince çok çekirdek kullanacak şekilde tasarlanmasıdır, oysa daha fazlasını kullanmadan önce çekirdeği en üst düzeye çıkarmak için eğitilmişse, daha az sorun olabilir. Büyük boyutlu bir VM iyi performans gösterebilir, ancak diğer VM'ler için 'gürültülü bir komşu' olabilir, bu nedenle, bazı performans kazanımlarını görmek için genellikle kümedeki tüm VM'leri 'doğru boyutlandırmak' için geçmeniz gereken bir işlemdir.
Çoğu zaman CPU Ready ile çalıştırılırsınız ve VM'leri doğru boyutlandırmaya veya daha fazla çekirdekli işlemcilere yükseltme yapmaya başlamak zordur. Bu durumda iseniz, kümenize daha fazla ana bilgisayar eklemek, yükü daha fazla ana bilgisayara yaymak için buna yardımcı olabilir. Diğerlerinden daha fazla çekirdeğe / işlemciye sahip ana bilgisayarlarınız varsa, yüksek vCPU'lu sanal makinelerin bu yüksek çekirdekli ana makinelere atanması da yardımcı olabilir. Fiziksel ana makinenizin, sanal makineden daha fazla olmasa da en azından aynı sayıda çekirdeğe sahip olduğundan emin olmak istiyorsunuz, aksi takdirde vCPU fazlalığını pCPU'ya planlamak çok yavaş / zor olacaktır çünkü bunlar aşağı yukarı aynı anda kilitlenmelidir. .
Son olarak, hipervizörünüz sanal makinedeki rezervasyonları ve limitleri destekleyebilir. Bazen tezler yanlışlıkla kurulur. Bunların üzerindeki agresif ayarlar, aslında temel kaynaklar mevcut olduğunda CPU'nun hazır olmasına neden olabilir. Rezervasyonları ve limitleri idareli ve yalnızca kesinlikle gerekli olduğunda kullanmak genellikle en iyisidir. Çoğunlukla, uygun şekilde boyutlandırılmış bir küme kaynakları uygun şekilde dengeleyecektir ve bunlar genellikle gerekli değildir.
Özetle, CPU Ready'ye karşı en iyi savunma, var olduğunu ve nasıl kontrol edileceğini bilmektir. Daha sonra, yukarıda verilen ortamınız için en iyi azaltma adımlarını sistematik olarak belirleyebilirsiniz. Ekran görüntüleri ve grafikler özellikle VMware için geçerli olsa da, bu makaledeki bilgiler evrensel olarak herhangi bir hiper yönetici için geçerlidir.
5 dakika okundu
