З новими процесорами Xeon, що підтримують Hyper-Threading, яка сучасна мудрість щодо його використання (чи ні) на хост-машині Hyper-V?
Я спочатку мав враження, що включення його у віртуальному хост-середовищі може бути згубним, оскільки «зайві» процесори не були справжніми ядрами. Однак я також читав (непідтверджені) коментарі за принципами MS, які роблять важку роботу, щоб Hyper-V добре працював у середовищі Hyper-Threading.
Хтось має якусь ґрунтовну інформацію чи досвід щодо цього? Ура!
Відповіді:
Стара проблема з Hyper-Threading у віртуальному сервері 2005 року, не надто технічно, це те, що кеш процесора був отруєний, тобто він кешував майже нічого, оскільки контексти того, що відбувалося в кожній нитці, не були пов'язані - змушуючи їх конкурувати за кеш-пам'ять.
Нові чіпи мають більші та розумніші кеші, тому це менше проблеми.
Ідеально включати чи вимикати? Це дійсно залежить від завантаженості. Якщо обидва потоки мають один і той же VM та одне і те ж завдання, то майже напевно було б великою перевагою. Якби вони робили непов’язані речі з великою кількістю випадкових вводу / виводу оперативної пам’яті (наприклад, декілька різних VM), це спричинило б доступність лише половини кешу мікросхеми для кожного - що теоретично може бути повільніше - насправді це рідко вже є.
Якщо у вас є чіпи старшого покоління, хоча ви можете перевірити розміри кешу чіпів: При віртуалізації більшого кешу ви можете отримати краще. Оперативна пам’ять справді набагато повільніше, ніж процесори - тільки НЕ БУДЕ так погано, як дисководи.
ПРИМІТКА. Те, що ви читаєте, що говорить про "вимкнути", було виявлено щодо мікросхем, які були одноядерними з Hyper-Threading - Наприклад, це було офіційною відповіддю ще в той день (2005/2006?) - http: //www.VirtualServerFAQ .com / tiki-index.php? page = VirtualServerHostDualCore
Стів Радич http://www.VirtualServerFAQ.com
Відповідно до Windows IT Pro, ви хочете залишити його на:
A. Новий чотирьохядерний процесор Intel Core i7 забезпечує гіпер-нарізку, що розбиває кожне ядро процесора на два віртуальних ядра, щоб (потенційно) підвищити продуктивність.
Піклування щодо Hyper-V та гіпер-ниток полягає в тому, що ви присвоюєте декілька процесорних ядер кожній віртуальній машині (VM). Уявіть, що ви присвоюєте один процесор кожному двом запрошеним VM з консолі управління Hyper-V, думаючи, що кожен збирається використовувати окреме ядро. Що робити, якщо гіпервізор присвоює кожному з ВМ одного і того ж фізичного ядра, при цьому кожен отримує віртуальне ядро? Ви потенційно могли б отримати слабку продуктивність, і три фізичні ядра не дуже роблять, де вам би хотілося, щоб кожен VM отримав своє фізичне ядро.
На щастя, це не так. Microsoft провела багато роботи навколо Hyper-Threading та Hyper-V. По суті, хоча Hyper-Threading іноді сприятиме продуктивності, це ніколи не зашкодить продуктивності, тому Hyper-Threading слід включити.
Програми, які знають про гіпертодування, здатні розрізняти фізичне ядро та логічне (віртуальне) ядро та відповідно розподіляти ресурси.
Hyperthreading зменшує вартість перемикання контексту, дозволяючи зберігати стани двох процесів у будь-який момент часу, а не лише один стан за один раз. Контекстна комутація, як правило, вважається дуже дорогою, тому що вам доведеться завантажити весь стан процесу в процесор. Це означає, що якщо у вас запущений процесор, інтенсивний процесор, процесор із гіперпотоком може часто перемикатися між цим процесом та іншими, не зазнаючи значної віддачі від продуктивності.
Перевага роботи віртуальних серверів полягає в тому, що ви можете створити великий пул ресурсів, який при необхідності можна буде розподілити на різні сервери. Це включає перерозподіл ядер процесора та врівноваження навантаження по всіх наявних ядрах. Якщо гіпервізор не знає різниці між фізичним ядром та логічним ядром, то ви маєте рацію - деякі фізичні ядра можуть сидіти в режимі очікування, а інші прив’язані до 100% використання процесора, тоді як обидва їх логічних ядра змагаються за процесор час. Однак якщо гіпервізор зможе визначити різницю між фізичними та логічними ядрами, він спробує збалансувати навантаження ЦП через фізичні процесори, перш ніж розподілити кілька процесів на два логічних ядра, що належать до одного фізичного ядра.
Я детально не вивчив цю проблему, але Microsoft не рекомендує використовувати гіперточення з Exchange 2010 через проблеми з плануванням та моніторингом потужностей. Можливо, ви захочете протестувати власні навантаження перед вибором тієї чи іншої конфігурації.
Hyperthreading: Нічого собі, безкоштовні процесори!
Вимкнути. Хоча сучасні впровадження одночасної багатопотокової передачі (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