Hyper-thread özelliğini destekleyen yeni Xeon CPU'larda, Hyper-V ana bilgisayarında kullanma (veya kullanmama) konusundaki mevcut bilgelik nedir?
Başlangıçta, sanal bir ev sahibi ortamda açmanın 'ekstra' CPU'lar gerçek çekirdek olmadığından zararlı olabileceği izlenimi altındaydım. Ancak, Hyper-V'nin bir Hyper-threading ortamında iyi çalışmasını sağlamak için bazı zor işleri yapan MS satırları boyunca yorumları da doğrulamamıştım.
Bu konuda sağlam bir bilgisi veya deneyimi olan var mı? Şerefe!
Yanıtlar:
Virtual Server 2005'teki Hyper-Threading ile ilgili eski sorun, aşırı teknik olmadan, CPU önbelleğinin zehirlenmesiydi, yani hemen hemen hiçbir şeyi önbelleğe almıyordu, çünkü her iş parçacığında ne olup bittiğinin bağlamları birbiriyle ilişkili değildi. çipte önbellek.
Yeni yongaların daha büyük ve daha akıllı önbellekleri vardır, bu yüzden bu daha az problemdir.
Açık veya kapalı olması ideal mi? Bu gerçekten iş yüküne bağlı. Her iki iş parçacığı aynı VM ve aynı görevi çalıştırıyor olsaydı, o zaman kesinlikle kesinlikle üzerinde büyük bir avantaj olurdu. Çok fazla rastgele RAM G / Ç (örneğin birkaç farklı VM) ile ilgisiz şeyler yapıyorlarsa çipin önbelleğinin yalnızca yarısının kullanılabilir olmasına neden olur - ki bu teoride daha yavaş olabilir - gerçekte nadiren artık olur.
Daha eski nesil cipsleriniz varsa cips önbellek boyutlarını kontrol etmek isteyebilirsiniz: Sanallaştırmada daha büyük önbellek daha iyi olabilir. RAM gerçekten CPU'lardan çok daha yavaştır - disk sürücüleri kadar kötü değildir.
NOT: Hyper-Threading ile tek çekirdekli yongalarla ilgili "kapat" diyen ne okuyorsunuz - Örneğin, bu resmi geri cevaptı (2005/2006?) - http: //www.VirtualServerFAQ .com / tiki-index.php? page = VirtualServerHostDualCore
Steve Radich http://www.VirtualServerFAQ.com
Windows IT Pro'ya göre, açık bırakmak istersiniz:
Y. Yeni dört çekirdekli Intel Core i7 işlemci, performansı artırmak için (potansiyel olarak) her işlemci çekirdeğini iki sanal çekirdeğe bölen hiper iş parçacığı sağlar.
Hyper-V ve hiper iş parçacıklığındaki endişe, her sanal makineye (VM) bir dizi işlemci çekirdeği atamanızdır. Her birinin ayrı bir çekirdek kullanacağını düşünerek Hyper-V yönetim konsolundan her iki konuk VM'ye bir işlemci atadığınızı hayal edin. Hiper yönetici sanal makinelerin her birini sanal bir çekirdeğe sahip olacak şekilde aynı fiziksel çekirdeğe atadığında ne olur? Her bir VM'yi kendi fiziksel çekirdeğini elde etmeyi seveceğiniz yerde, kötü performans göstermeye ve üç fiziksel çekirdek yapmayacaksınız.
Neyse ki, durum bu değil. Microsoft, Hyper-Threading ve Hyper-V ile ilgili birçok çalışma yaptı. Temel olarak, Hyper-Threading bazen performansa yardımcı olurken, hiçbir zaman performansa zarar vermez, bu nedenle Hyper-Threading etkinleştirilmelidir.
Hyperthreading'in farkında olan programlar, fiziksel bir çekirdek ile mantıksal (sanal) bir çekirdek arasında ayrım yapabilir ve kaynakları buna göre tahsis edebilir.
Hyperthreading, iki işlemin durumlarının bir seferde sadece bir durum yerine herhangi bir zamanda saklanmasına izin vererek bağlam değiştirme maliyetini azaltır. Bağlam-anahtarlamanın genellikle çok pahalı olduğu düşünülür, çünkü işlemin tüm durumunu CPU'ya yüklemeniz gerekir. Bu, çalışan bir CPU yoğun bir işleminiz varsa, hiper iş parçacıklı işlemcinin bir performans isabetine maruz kalmadan sık sık bu işlem ve diğerleri arasında geçiş yapabileceği anlamına gelir.
Sanal sunucuları çalıştırmanın avantajı, gerektiğinde anında farklı sunuculara tahsis edilebilecek büyük bir kaynak havuzu oluşturabilmenizdir. Bu, CPU çekirdeğinin yeniden tahsis edilmesini ve yükün mevcut tüm çekirdekler arasında dengelenmesini içerir. Eğer hipervizör, fiziksel bir çekirdek ile mantıksal bir çekirdek arasındaki farkı bilmiyorsa, o zaman haklısınız - bazı fiziksel çekirdekler boştayken diğerleri% 100 CPU kullanımında sabitlenirken, her ikisi de mantıksal çekirdeklerinin her ikisi de CPU için rekabet ederken saati. Bununla birlikte, eğer hipervizör fiziksel ve mantıksal çekirdekler arasındaki farkı söyleyebiliyorsa, aynı fiziksel çekirdeğe ait iki mantıksal çekirdeğe birden fazla işlem ayırmadan önce CPU yükünü fiziksel CPU'lar arasında dengelemeye çalışacaktır.
Bu konuyu ayrıntılı olarak incelemedim, ancak Microsoft "kapasite planlama ve izleme" sorunları nedeniyle Exchange 2010'a yönelik yüksek taramayı kullanmanızı önermiyor. Bir konfigürasyon veya diğerini seçmeden önce kendi iş yüklerinizi test etmek isteyebilirsiniz.
Hyperthreading: Vay, özgür işlemciler!
Kapatmak. Hiper-iş parçacığı olarak da bilinen eşzamanlı çoklu okuyucunun (SMT) modern uygulamaları çoğu uygulama için CPU verimliliğini kesinlikle artırabilirken, Exchange 2013'ün yararları olumsuz etkilerden ağır basmıyor. .NET sunucusunun çöp toplayıcısının yığınları ayırma biçimi nedeniyle köprü geçirme etkinleştirildiğinde Exchange sunucularında bellek kullanımında önemli bir etkiye sahip olabileceği ortaya çıkıyor. Sunucu çöp toplayıcısı, bir uygulama başlatıldığında ve mantıksal işlemci başına bir yığın ayırdığında toplam mantıksal işlemci sayısına bakar. Bu, sunucu çöp toplayıcısını kullanan hizmetlerimizden biri için başlangıçta bellek kullanımının, hiper iş parçacığı açık durumdayken ve kapatıldığında iki katına yakın olacağı anlamına gelir. Hafızadaki bu önemli artış, Ayrıca, dahili laboratuar testlerinde Exchange 2013 iş yükleri için gerçekleşen CPU verimi artışının bir analizi ile birlikte, tüm Exchange 2013 sunucuları için hiper iş parçacılığın devre dışı bırakılması gerektiği konusunda en iyi uygulama önerisine yol açtı. Avantajlar olumsuz etkiden ağır basmıyor.
Kopyalanan yer: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx