С новыми процессорами Xeon, поддерживающими Hyper-threading, каковы текущие соображения относительно его использования (или нет) на хост-машине Hyper-V?
Первоначально у меня создалось впечатление, что включение его в среде виртуального хоста может быть вредным, поскольку «лишние» процессоры не являются настоящими ядрами. Однако я также читал (неподтвержденные) комментарии о том, что MS проделывает некоторую тяжелую работу, чтобы Hyper-V работал хорошо в среде Hyper-threading.
Есть ли у кого-нибудь надежная информация или опыт в этом отношении? Ура!
Согласно Windows IT Pro, вы хотите оставить его включенным:
A. Новый четырехъядерный процессор Intel Core i7 обеспечивает гиперпоточность, которая разделяет каждое ядро процессора на два виртуальных ядра для (потенциально) повышения производительности.
Проблема с Hyper-V и гиперпоточностью заключается в том, что вы назначаете несколько ядер процессора каждой виртуальной машине (ВМ). Представьте, что вы назначаете по одному процессору каждой из двух гостевых виртуальных машин из консоли управления Hyper-V, думая, что каждая будет использовать отдельное ядро. Что, если гипервизор назначит каждую виртуальную машину одному и тому же физическому ядру, при этом каждая получит виртуальное ядро? Вы потенциально можете получить паршивую производительность и три физических ядра, которые мало что делают, тогда как вам бы хотелось, чтобы каждая виртуальная машина имела собственное физическое ядро.
К счастью, это не так. Microsoft проделала большую работу над Hyper-Threading и Hyper-V. По сути, хотя Hyper-Threading иногда улучшает производительность, она никогда не снижает производительности, поэтому следует включить Hyper-Threading.
Старая проблема с Hyper-Threading в Virtual Server 2005, если не вдаваться в технические подробности, заключалась в том, что кэш ЦП был отравлен, то есть почти ничего не кэшировалось, потому что контексты того, что происходило в каждом потоке, не были связаны, что заставляло их конкурировать за кэш на кристалле.
Новые чипы имеют более крупный и умный кэш, поэтому это не проблема.
Идеально - включить или выключить? Это действительно зависит от загруженности. Если бы оба потока выполняли одну и ту же виртуальную машину и одну и ту же задачу, это почти наверняка было бы БОЛЬШИМ преимуществом. Если бы они делали несвязанные вещи с большим количеством случайных операций ввода-вывода в ОЗУ (например, несколько разных виртуальных машин), это привело бы к тому, что для каждой из них была бы доступна только половина кеш-памяти чипа - что теоретически могло бы быть медленнее - на самом деле это редко бывает больше.
Если у вас есть чипы более старого поколения, вы можете проверить размеры кеша чипа: в виртуализации чем больше кеш, тем лучше. ОЗУ действительно НАМНОГО медленнее, чем процессоры - только не так плохо, как диски.
ПРИМЕЧАНИЕ. То, что вы читаете с надписью «выключить», было обнаружено в отношении одноядерных микросхем с Hyper-Threading - например, это был официальный ответ в свое время (2005/2006?) - http://www.VirtualServerFAQ.com/tiki-index.php?page=VirtualServerHostDualCore
Стив Радич http://www.VirtualServerFAQ.com
Программы, которые знают о гиперпоточности, могут различать физическое ядро и логическое (виртуальное) ядро и соответственно выделять ресурсы.
Гиперпоточность снижает стоимость переключения контекста, позволяя сохранять состояния двух процессов в любой момент времени, а не только одно состояние за раз. Переключение контекста обычно считается очень дорогостоящим, потому что вам нужно загружать все состояние процесса в ЦП. Это означает, что если у вас запущен процесс, интенсивно использующий ЦП, гиперпоточный ЦП может часто переключаться между этим процессом и другими, не оказывая значительного снижения производительности.
Преимущество работы виртуальных серверов заключается в том, что вы можете создать большой пул ресурсов, который можно оперативно распределять между разными серверами по мере необходимости. Это включает в себя перераспределение ядер ЦП и балансировку нагрузки по всем доступным ядрам. Если гипервизор не знает разницы между физическим ядром и логическим ядром, тогда вы правы - некоторые физические ядра могут простаивать, в то время как другие привязаны к 100% загрузке ЦП, в то время как оба их логических ядра конкурируют за ЦП. время. Однако, если гипервизор может отличить физические ядра от логических, он попытается сбалансировать нагрузку на ЦП между физическими ЦП перед распределением нескольких процессов между двумя логическими ядрами, принадлежащими одному и тому же физическому ядру.
Я не изучал эту проблему подробно, но Microsoft не рекомендует использовать гиперпоточность с Exchange 2010 из-за проблем «планирования и мониторинга емкости». Возможно, вы захотите протестировать свои собственные рабочие нагрузки, прежде чем выбирать ту или иную конфигурацию.
Гиперпоточность: Ух ты, бесплатные процессоры!
Выключи это. Хотя современные реализации одновременной многопоточности (SMT), также известной как гиперпоточность, могут полностью улучшить пропускную способность ЦП для большинства приложений, преимущества Exchange 2013 не перевешивают негативных последствий. Оказывается, что использование гиперпоточности может существенно повлиять на использование памяти на серверах Exchange из-за того, как сборщик мусора .NET-сервера выделяет кучи. Сборщик мусора на сервере проверяет общее количество логических процессоров при запуске приложения и выделяет кучу для каждого логического процессора. Это означает, что использование памяти при запуске для одной из наших служб, использующих серверный сборщик мусора, будет почти удвоено при включенной гиперпоточности по сравнению с ее выключением. Это значительное увеличение памяти, а также анализ фактического увеличения пропускной способности ЦП для рабочих нагрузок Exchange 2013 во внутренних лабораторных тестах привели нас к передовой рекомендации, согласно которой гиперпоточность следует отключить для всех серверов Exchange 2013. Преимущества не перевешивают негативного воздействия.
Скопировано с: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx