РЕДАКТИРОВАТЬ 2: Мое приложение использует гиперпоточность
A. Да, я знаю, что это за технология и для чего она нужна.
Б. Да, я знаю разницу между физическим ядром и логическим
C. Да, отключение HT привело к замедлению рендеринга, этого и следовало ожидать!
D. Нет, я не преувеличиваю, когда назначаю все логические (да, логические) ядра одной виртуальной машине, если вы прочитаете официальные документы от VMWare, вы узнаете, что планировщик генерирует карту топологии физического оборудования и использует эту карту при выделении ресурсов, назначение ВСЕХ логических ядер одной виртуальной машине генерирует 16 логических процессоров в Windows, как если бы я установил виртуальную машину на физическом оборудовании. И вот, после 5 тестов эта схема показала самое быстрое (и наиболее эффективное) время рендеринга.
F. Речь идет о приложении 3ds max 2014, использующем backburner и рендерер Mental Ray.
TL | DR: Я (иногда) хочу запустить одну виртуальную машину на vSphere с максимальной эффективностью ЦП, как?
Я надеюсь использовать гипервизор VMWare ESXI / vSphere немного нестандартным образом.
Обычно люди используют гипервизор для одновременного запуска нескольких виртуальных машин в одной системе. Я хочу использовать гипервизор, чтобы позволить мне быстро переключаться между приложениями, но когда-либо действительно запускал только одну виртуальную машину / приложение за раз.
На самом деле это любимый проект, у меня есть 5 узлов рендеринга (например, узел 2x Intel Xeon E5540), который по большей части не работает (когда я не рендеринг, мне не нужно запускать эти машины). Это кажется пустой тратой драгоценного времени вычислений, поэтому я надеялся использовать их для других целей, когда не рендеринг (своего рода вычислительный кластер общего назначения с 40 ядрами / 80 потоками).
Я надеялся, что vSphere позволит мне развернуть виртуальные машины узла рендеринга при рендеринге и других вещах, когда это невозможно. Проблема в том, что мне действительно нужна высокая эффективность, когда дело касается ЦП, когда работает виртуальная машина рендеринга.
Я использую задание рендеринга в качестве эталона и получаю около 88% скорости на виртуальной машине, как я могу получить при настройке без виртуальной машины. Я надеялся приблизиться к 95%, есть идеи, как я могу туда добраться?
Редактировать детали:
Ресурсы, используемые виртуальной машиной рендеринга, я не совсем понимаю, почему эта полоса не заполнена:
Настройки ресурсов для этой виртуальной машины:
Несмотря на то, что виртуальная машина не показывает, что использует 100% ресурсов, хост:
Я не совсем понимаю процентные доли здесь, это когда все эти виртуальные машины включены? Также я не настраивал другие виртуальные машины на резервирование 10%:
Наконец, хост показывает, что он полностью загружен, хотя здесь не показано, использование МГц ниже (IE не на 100%):
Конфигурация ВМ:
Я понимаю, что это интересный случай, но, тем не менее, я считаю, что вопрос правильный и хороший и может помочь другим в подобной ситуации в будущем (хотя я признаю, что этот случай довольно специфичен).
Вы неправильно сконфигурировали свои виртуальные машины и хост.
Что следует учитывать:
Другие дела (в общем) ...
Я думаю, что вы достигли максимума из того, что вы можете получить с этими старыми Xeon, хотя, в отличие от ewwhite, я не верю, что гиперпоточность вызывает у вас какие-либо проблемы. Действительно, по крайней мере, начиная с ESXi 5.0, VMware рекомендует использовать гиперпоточность для большинства рабочих нагрузок., и ваше собственное тестирование, похоже, подтверждает, что вы получаете выгоду от HT. Однако, как правильно замечает ewwhite, использование HT приведет к тому, что некоторые показатели в vSphere будут выглядеть странно.
Я думаю, у вас есть одна очевидная проблема и, возможно, одна неочевидная проблема:
Во-первых, это очевидная проблема, заключающаяся в том, что сама виртуализация требует накладных расходов, которые невозможно полностью устранить. В случае с центральным процессором определенные инструкции должны быть виртуализированы, чтобы гипервизор мог правильно изолировать одну виртуальную машину от другой. Таким образом, вместо того, чтобы выполнять инструкцию напрямую, как в «голом железе», гипервизор перехватит вызов и выполнит вместо него несколько инструкций. Из предыдущего опыта мы видим, что 87-90% - это то, что вы должны ожидать от процессора. Чтобы избавиться от этого, потребуется значительный прогресс в оборудовании. Если вы сейчас видите 91% собственной производительности процессора, это, вероятно, примерно так же хорошо, как и должно быть.
Во-вторых, это неочевидная проблема NUMA. Это проблема многопроцессорных систем, в которых часть памяти работает быстрее при доступе к ближайшему ЦП и медленнее при обращении к другим ЦП. В зависимости от того, как ваше задание рендеринга обрабатывает память, вы мощь увидеть некоторую выгоду, бегая два параллельные рендереры в двух виртуальных машинах, каждая из которых привязана к определенному процессору и всегда обращается к немного более быстрой памяти. (Если вы запускаете две виртуальные машины на одном хосте, каждая из которых использует половину доступных виртуальных ЦП, ESXi должен решить это автоматически для вас.) Хотя, если вы не видите эту проблему на голом железе, вы, вероятно, не выиграете, попробовав это.