VMware'de ne kadar çekişme var?

Bir süredir, neden iş kritik sistemlerimizden birkaçının neden ılımlılıktan aşırıya kadar değişen “yavaşlık” raporları aldığını bulmaya çalışıyorum. Son zamanlarda gözümü, söz konusu tüm sunucuların barındırıldığı VMware ortamına çevirdim.

SCOM 2012 için Veeam VMware yönetim paketi denemesini indirip kurdum, ancak bana rapor ettiği rakamlara inanmakta zorlanıyorum (ve böylece patronum). Patronumu bana söylediği rakamların doğru olduğuna ikna etmek için, sonuçları doğrulamak için VMware istemcisinin kendisine bakmaya başladım.

Bu VMware KB makalesine baktım ; özel olarak tanımlanan Co-Stop tanımı için:

Bir MP sanal makinesinin çalışmaya hazır olduğu zaman miktarı, ancak birlikte-vCPU zamanlama çekişmesi nedeniyle gecikme yaşandı

Hangi dilde çeviri yapıyorum

Konuk işletim sistemi ev sahibi tarafından zamana ihtiyaç duyar ancak kaynakların kullanılabilir olmasını beklemek zorundadır ve bu nedenle "yanıt vermiyor" olarak kabul edilebilir

Bu çeviri doğru görünüyor mu?

Öyleyse, burada görmekte olduğum şeye inanmakta zorlanıyorum: “Yavaş” olan VM'lerin çoğunluğunu içeren ana bilgisayar şu anda 127.835.94 milisaniyelik bir CPU Co-stop ortalamasını gösteriyor !

Bu, ortalama olarak, bu ana bilgisayardaki VM'lerin CPU zamanı için 2+ dakika beklemesi gerektiği anlamına mı geliyor?

Bu sunucunun üzerinde iki adet 4 çekirdekli işlemci var ve 1x8 CPU ve 14x4 CPU misafirleri var.

Bu alanda yaşadığım bazı deneyimleri anlatabilirim ...

VMware'in müşterileri ( veya yöneticileri ) en iyi uygulamalar hakkında eğitmek için yeterli bir iş yaptığına ve ürünleri geliştikçe eski en iyi uygulamaları güncellediklerine inanmıyorum. Bu soru vCPU tahsisi gibi bir temel kavramın tam olarak nasıl anlaşılmadığının bir örneğidir. En iyi yaklaşım, VM'nin daha fazlasını gerektirdiğini belirleyene kadar tek bir vCPU ile küçükten başlamaktır.

OP için, ESXi ana bilgisayar sunucusunda 8 adet fiziksel çekirdek sağlayan iki adet dört çekirdekli işlemci bulunur.

Tanımlanan sanal makine düzeni toplam 15 kişidir; 1 x 8 vCPU ve 14 x 4 vCPU sistemleri. Bu, özellikle 8 vCPU'lu tek bir misafirin varlığında çok fazla abartılıyor . Hiç bir anlamı yok. Bu kadar büyük bir VM’ye ihtiyacınız varsa, muhtemelen daha büyük bir sunucuya ihtiyacınız olacaktır.

Lütfen sanal makinelerinizi doğru boyutlandırmaya çalışın . Birçoğunun 2 vCPU ile yaşayabildiğinden eminim. Sanal CPU'lar eklemek işlerin daha hızlı çalışmasını sağlamaz, bu nedenle performans sorununa bir çözüm varsa, bu yanlış bir yaklaşımdır.

Çoğu ortamda, RAM en kısıtlı kaynaktır. Ancak çok fazla çekişme varsa CPU sorun olabilir. Buna dair kanıtın var. Bireysel sanal makinelere çok fazla tahsis edildiğinde RAM de bir sorun olabilir .

Bunu izlemek mümkün. Aradığınız ölçüm "CPU Hazır%" dir. Sen VM seçerek ve giderek vSphere istemcisinden bu erişebilirsiniz Performance> Overview> CPU Graph.

• % 5'in altında CPU Hazır - İyisin.
• % 5-10 CPU Hazır - Faaliyete yakından bakın.
• % 10'dan fazla CPU Hazır - İyi değil.

Aşağıdaki grafikteki Sarı çizgiye dikkat edin.

Bunu, sorununuzu sanal makinelerde kontrol edip geri bildirir misiniz?

Çift çekirdekli bir ESXi sunucunuz olduğunu ve yorumlarda bir 8vCPU VM ve on dört 4vCPU VM çalıştırdığınızı belirtiyorsunuz.

Eğer bu benim çevrem olsaydı, fena halde aşırı tedarik edileceğini düşünürdüm . En fazla bu donanıma dört ila altı adet 4vCPU konuğu koyardım. (Bu, söz konusu VM'lerin, bu kadar yüksek bir vCPU sayısına sahip olmalarını gerektiren yüke sahip olduğunu varsaymaktadır.)

Altın kuralı bilmediğinizi farz ediyorum ... VMware ile asla VM'den gerekenden daha fazla çekirdek atamamalısınız. Nedeni? VMware, atanmış olduğu kadar çok çekirdek olmadıkça, VM'lerin CPU zamanı almalarını zorlaştıran biraz katı eş zamanlama kullanır. Yani, bir 4vCPU VM aynı anda açık 4 fiziksel çekirdek olmadıkça 1 iş birimi gerçekleştiremez. Başka bir deyişle,% 90 CPU yüküne sahip bir 1vCPU VM'ye sahip olmak ve daha sonra çekirdek başına% 45 yüke sahip bir 2vCPU VM'ye sahip olmak mimari olarak daha iyidir.

Öyleyse ... HER ZAMAN minimum vCPU'lu VM'ler oluşturun ve yalnızca gerektiğinde belirlendiğinde ekleyin.

Durumunuz için konuklarınızdaki CPU kullanımını izlemek için Veeam kullanın. VCPU sayısını mümkün olduğu kadar azaltın. Neredeyse mevcut tüm 4vCPU misafirleriniz için 2vCPU'ya düşebileceğinizi iddia etmek isterim.

Tüm bu VM'lerin sahip oldukları vCPU sayısını gerektiren bir CPU yüküne sahip olması durumunda, yalnızca ek donanım satın almanız gerekir.

127.835.94 milisaniye bir toplamadır ve doğru% RDY değerlerini elde etmek için örnekleme zamanına göre ayırmanız gerekir. Şimdilik doğru% RDY değerlerini zaten alıyorsunuz. VCPU ile fiziksel cpu oranı arasında oldukça yüksek olabilir ancak yaptığınız şekilde değil.

Çok fazla dörtlü vCPU VM'leriniz ve hatta 8 vCPU VM'niz var. Halihazırda doğru boyutlandırmayı tartışan bazı kalite tepkileri ve döngüleri daha az vCPU'lara sağlamlaştırmamanın bazı sonuçları var. Açıklığa kavuşturmak istediğim tek şey, bir VM'nin herhangi bir talimatın işlenebilmesi için mevcut olması için vCPU sayısına eşit olan fiziksel CPU sayısını beklemesinin gerekmediği durumdur. çok büyüklükteki vCPU VM'lerin fiziksel çekirdeğe oranı ile bu büyüklükte fazla kaynak sağlama. 8 çekirdekteki 64 vCPU maksimum 4 - 1 oranının çok üstünde. Sanırım 16 işlemciye sahip olduğunuz için bu işlemcilerde HT var. Hafif yüke sahip 1 ve 2 vCPU VM'lerde bu sorun olmayabilir, ancak VM'lerde ağır bir yük varsa, bunu gerçekleştirmek zor olacaktır.

FYI HT işlemciler, kullanılan işlemcilerin% CPU'sunda kullanılmaz - yani bir sunucuda 2,4 GHz'de çalışan 32 mantıksal çekirdeğiniz varsa, 38,4 GHz'e bastığınızda% 100 kullanımdasınız demektir. Yani yük ortalamalarının 1,0'dan büyük olduğunu görünce, bu yüzden.

İşte 3.5 ila 1 vCPU - fiziksel CPU (HT çekirdeği dahil) oranını,% 3'lük bir ortalama% RDY ile çalıştıran bir ESXi Sunucusu.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

O zamandan beri, performans sorunlarımızın bulunduğu yere biraz ışık tutan Veeam ONE'ı kurduk. Veeam ONE'daki CPU Darboğazları ekranına bakarak Ardından yanıt vermeyi durduran sanal bir makinede Sorun Giderme'yi kullanarak : referans olarak VMM ve Misafir CPU kullanım karşılaştırması "kabul edilemez" çekişmemizin ne kadar olduğunu belirledik.

Özellikle paylaşmak istediğim küçük bir ipucu, bir durumda VM'deki anlık görüntüyü kaldırana kadar CPU çekişmesini ortadan kaldıramadığımdır. Umarım bu birine yardımcı olur.