Почему наше программное обеспечение работает намного медленнее при виртуализации?

Question

Я пытаюсь выяснить, почему наше программное обеспечение работает намного медленнее, чем при виртуализации.Большинство статистических данных, которые я видел, говорят, что в худшем случае это всего лишь 10% снижения производительности, но на виртуальном сервере Windows снижение производительности может составлять 100-400%.Я пытался профилировать различия, но результаты профиля не имеют большого смысла для меня.Вот то, что я вижу, когда я создаю профиль на своем 32-разрядном компьютере Vista без виртуализации:

А вот один запуск на 64-разрядном сервере Windows 2008 с виртуализацией:

Медленный тратит очень много времени в RtlInitializeExceptionChain, который показывает как 0,0 с на быстром.Есть идеи, что это делает?Кроме того, когда я присоединяю к процессу мою машину, существует только один поток, PulseEvent, однако, когда я подключаюсь к серверу, появляются два потока, GetDurationFormatEx и RtlInitializeExceptionChain.Насколько я знаю, код, в котором мы написали, использует только один поток.Кроме того, чего бы это ни стоило, это только консольное приложение, написанное на чистом C и вообще без пользовательского интерфейса.

Кто-нибудь может пролить свет на что-нибудь из этого для меня?Даже просто информация о том, что делают некоторые из этих вызовов ntdll и kernel32?Я также не уверен, сколько различий связано с 64/32-битными и сколько виртуальных / не виртуальных.К сожалению, у меня нет легкого доступа к другим конфигурациям, чтобы определить разницу.

Answer 1

Полагаю, мы могли бы разделить причины снижения производительности на виртуальной машине на два класса:

1.Перекос конфигурации

Эта категория предназначена для всех вещей, которые не имеют ничего общего с виртуализацией как таковой , но в которых настроенная виртуальная машина не так хороша, как реальная.Очень просто сделать так, чтобы у виртуальной машины было только одно ядро ​​ЦП, а затем сравнить его с приложением, работающим на двухъядерном 8-ядерном 16-гиперпоточном процессоре Intel Core i7.В вашем случае, как минимум, вы не запускаете ту же ОС.Скорее всего, есть и другой перекос.

2.Bad Virtualization Fit

Такие вещи, как базы данных, которые выполняют много блокировок, плохо виртуализируются, и поэтому типичные накладные расходы могут не применяться в тестовом примере.Это не совсем ваш случай, но мне сказали, что для MySQL штраф составляет 30-40%.Я заметил в вашем списке точку входа с именем ... семафор .Это признак того, что виртуализация будет происходить медленно.

Основная проблема заключается в том, что конструкции, которые не могут быть выполнены естественным образом в пользовательском режиме, потребуют прерываний (медленных, сами по себе), а затем дополнительных затрат в коде эмуляции гипервизора.,

Answer 2

Я предполагаю, что вы предоставляете достаточно ресурсов для своих виртуальных машин, преимущество виртуализации заключается в консолидации 5 машин, которые работают с 10-15% ЦП / памяти, на одну машину, которая будет работать на 50-75%. Процессор / память, и которые все еще оставляют вам 25-50% накладных расходов в эти «бурные» времена.

Личный анекдот: 20 машин были виртуализированы, но каждая из них использовала столько ЦП, сколько могла. Это вызывало проблемы, когда одна машина пыталась использовать больше энергии, чем могло обеспечить одно ядро. Поэтому гипервизор виртуализировал одно ядро ​​на несколько ядер, снижая производительность. Как только мы ограничили использование ЦП каждой виртуальной машины до максимального уровня, доступного для любого отдельного ядра, производительность резко возросла.