Виртуальная машина медленнее, чем базовая физическая машина?

Этот вопрос довольно общий, но в особенности мне интересно узнать, будет ли виртуальная машина с Ubuntu Enterprise Cloud работать медленнее, чем та же физическая машина без какой-либо виртуализации. Сколько (1%, 5%, 10%)?

Кто-нибудь измерял разницу в производительности веб-сервера или db-сервера (виртуальный виртуальный VS)?

Если это зависит от конфигурации, давайте представим два четырехъядерных процессора, 12 ГБ памяти и набор SSD-дисков, на которых работает 64-битный Ubuntu Enterprise Server. Кроме того, только 1 виртуальная машина позволила использовать все доступные ресурсы.

Типичная нагрузка на серверную рабочую нагрузку общего назначения на гипервизоре типа «голый металл» составляет около 1–5% загрузки ЦП и 5–10% нагрузки на память, при этом некоторые дополнительные издержки зависят от общей нагрузки ввода-вывода. Это в значительной степени согласуется с моим опытом для современных гостевых ОС, работающих под управлением VMware ESX \ ESXi, Microsoft Hyper-V и Xen, где соответствующее оборудование было соответствующим образом спроектировано. Для 64-битных операционных систем сервера, работающих на оборудовании, которое поддерживает самые современные аппаратные расширения виртуализации ЦП, я ожидал бы, что все гипервизоры типа 1 будут стремиться к этому 1% служебного числа. На данный момент зрелость KVM не совсем соответствует Xen (или VMware), но я не вижу причин думать, что это будет заметно хуже, чем они, для примера, который вы описываете.

Однако для конкретных случаев использования общая \ совокупная «производительность» виртуальной среды может превышать «голые железные» \ дискретные серверы. Вот пример обсуждения того, как внедрение VMware Clustered может быть быстрее, лучше, дешевле, чем RAC Oracle. Методы управления памятью VMware (особенно прозрачный общий доступ к страницам) могут почти полностью устранить издержки памяти, если у вас достаточно виртуальных машин, которые достаточно похожи. Важным моментом во всех этих случаях является то, что преимущества производительности / эффективности, которые может обеспечить виртуализация, будут реализованы только в том случае, если вы объединяете несколько виртуальных машин на хосты, ваш пример (1 виртуальная машина на хосте) всегда будет в некоторой степени медленнее, чем «голое железо». ,

Хотя это все полезно, реальные проблемы с точки зрения виртуализации серверов, как правило, связаны с управлением, технологиями высокой доступности и масштабируемостью. Запас производительности процессора в 2-5% не так важен, как возможность эффективного масштабирования до 20, 40 или любого количества виртуальных машин, необходимых для каждого хоста. Вы можете справиться с падением производительности, выбрав немного более быстрый ЦП в качестве базового уровня или добавив больше узлов в кластеры, но если хост не может масштабировать количество виртуальных машин, которые он может запустить, или среда сложна в управлении или ненадежен, то бесполезен с точки зрения виртуализации серверов.

«Производительность» имеет много аспектов. N00bs измеряют время загрузки ОС и говорят, например, что Windows 2012 настолько хороша, потому что она загружается за 12 секунд на реальном HD, может быть, 1 секунду на SSD.
Но такая мера не очень полезна: производительность равна времени загрузки ОС, но ОС загружается раз в месяц, поэтому такая оптимизация не имеет особого смысла.

Поскольку это мое ежедневное дело, я мог бы выделить 4 следующие части, которые составили «производительность»

1. Загрузка ЦП
   Это должно быть сопоставимо, то есть задача, занимающая 1000 мс на «голом железе», будет выполняться за 1000 мс времени процесса и, возможно, 1050 мс тактового времени в среде бездействующей виртуальной машины на том же оборудовании (некоторые подробности позже). Поищите в Google MSDN время обработки и queryperformancecounter, и вы сможете показать, сколько виртуальной машины съедает ваше процессорное время.

2. Производительность SQL
   Производительность SQL во многом зависит от ввода-вывода в хранилище данных, где хранятся данные SQL. Я видел разницу в 300% между ISCSI 1-го поколения, который вы можете найти на домашнем NAS-сервере Buffalo, затем ISCSI с DCE и реальной средой старой школы на всех уровнях. FC все еще выигрывает в наше время, потому что задержка FC является самой низкой в ​​архиве, что приводит к «копированию» протокола FC для улучшений центра данных TCP / IP. Здесь очень важны операции ввода-вывода и задержки, а также пропускная способность ввода-вывода от серверного процесса к носителю - зависит от того, стремится ли приложение к No-SQL или к хранилищу данных или находится в середине этого, как системы ERP ... Sage KHK для малых предприятий, SAP для огромных.

3. Доступ к файловой системе
   Некоторые приложения, такие как потоковое видео, зависят от гарантированной минимальной пропускной способности, другие полагаются на максимальную пропускную способность ввода-вывода, например, просто открывают большие файлы в шестнадцатеричном редакторе, загружая видеопроект в свою любимую программу создания фильмов. Не типичная ситуация для VM .... IOps также могут быть важны для разработчиков. Разработчики часто используют виртуальные машины, потому что среда разработки очень чувствительна, и поэтому соблазн сделать это в виртуальной машине высок. Компиляция большого проекта часто означает чтение тонны небольших файлов, выполнение компиляции и сборку EXE и соответствующих компонентов.

4. Сетевая задержка для клиента
   Здесь удобство использования таких программ WYSIWIG, как Word 2010, Openoffice Writer, LaTEX, GSView и других, в значительной степени зависит от скорости - от того, насколько быстро действие мыши передается от клиента к серверу. Это особенно важно в приложениях САПР, но это не проблема локальной сети, а удаленный доступ через глобальную сеть, где это важно.

Но - и я говорю с точки зрения многолетнего консалтинга - есть пользователи, имеющие пароль администратора (и они часто являются сотрудниками БОЛЬШОЙ компании с БОЛЬШИМ бюджетом и БОЛЬШОЙ записной книжкой), которые жалуются на это и то, но это необходимо уточнить какой компонент производительности важен для них, а какой важен с точки зрения приложения, которое они используют.
Скорее всего, это не блокнот, а очень сложное приложение для разработки того и другого, которое также было очень дорогостоящим и должно быть перенесено на VMware, HyperV или Xenapp и не работает должным образом.

Но они не имеют в виду, что он может работать на 1,5 ГГц Xeon на блейдах, не предназначенных для чистой производительности процессора, они рассчитаны на среднее значение, скажем, «оптимизировано для $ на цикл ЦП» или «циклов ЦП на Ватт» ,

И когда мы говорим о компромиссах и экономиях - это в основном приводит к чрезмерным обязательствам. Чрезмерные коммиты приводят к нехватке ресурсов, при которых процессор может обрабатываться довольно хорошо, но нехватка памяти ведет к подкачке страниц, нехватка ввода-вывода в основных маршрутизаторах приводит к увеличению времени ответа на все, а транзакционная перегрузка в любом виде хранилища может остановить все полезное приложение от слишком быстрого реагирования. Здесь необходим мониторинг, но многие поставщики программного обеспечения не могут предоставить такую ​​информацию .... с другой стороны, хост с ресурсами 3 физических сервера, скорее всего, может обрабатывать 8 виртуальных машин той же структуры, что и физические ...

Компромиссы ЦП в незанятых системах часто приводят к тому, что системы работают на 50% медленнее, чем физические системы, с другой стороны, никто не может установить «реальный мир» и приложение «реального мира», которые ИТ-специалисты заказчика хотят перенести в ВМ коробка. Требуются дни (может быть, недели, но наверняка 42 встречи), чтобы понять, что технология VM может предложить гибкость, торгуя с чистой скоростью процессора. Это просто встроено в процессоры этих блейд-систем, в которых в настоящее время размещаются более крупные виртуальные среды. Кроме того, память не будет сопоставимой, также применяются некоторые компромиссы. DDR3 1600 CL10 будет иметь более высокую пропускную способность памяти, чем DDR2 800 ECC LLR - и все знают, что процессоры Intel выигрывают от этого иначе, чем процессоры AMD. Но они редко используются в продуктивной среде, больше в «белых ящиках» или в центрах обработки данных, расположенных в странах третьего мира, которые предлагают услуги центра обработки данных за 10% от цены, которую центр обработки данных на вашей родной территории может выставить вам счет. Благодаря Citrx центр обработки данных может быть везде, если между конечным пользователем и центром обработки данных задержка составляет менее 150 мс.

И перспектива домашних пользователей ....

И последнее, но не менее важное: некоторые люди хотят выбросить Win7 или XP и обменять их на Linux, а затем возникает игровой вопрос, потому что на самом деле для Linux и Windows доступно всего несколько игр. Игры в значительной степени зависят от 3D-ускорения. Рабочая станция VMWare 6.5 и подключенный бесплатный плеер могут работать с DirectX 9, что означает, что Doom3 в виртуальной машине может работать на графической карте хоста в полноэкранном режиме. Игры - это в основном 32-битные приложения, поэтому они не будут поглощать более 3 ГБ и в основном не более 3 процессоров (видно на Crysis). Новые VM-плееры и WS могут работать с более высокими версиями DirectX и, возможно, также с OpenGL ... Я играл в UT и UT2004 на VMware 6.5, хост имел мобильный телефон ATI Radeon 2600 и процессор T5440. Он был стабильным при разрешении 1280x800 и воспроизводим даже в сетевых играх ....

Да. Но это не вопрос. Разница обычно пренебрежимо мала (от 1% до 5%).

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

Я проводил некоторые тестовые сравнения одного и того же программного обеспечения, выполняющего тот же тест (веб-приложение на основе .NET с большими объемами веб-трафика и значительным доступом к SQL Server). Вот что я видел:

• Физическая машина лучше справляется с созданием классов (что приводит к выделению памяти на системном уровне) - для меня это имеет смысл, потому что физические машины делают это с помощью оборудования для управления памятью, а виртуальные машины - с помощью программного обеспечения (с частичной аппаратной поддержкой) (на виртуальной машине приложение потратило значительное количество времени на свои конструкторы (где выделена память (и больше ничего не делается), на физической машине конструкторы даже не были включены в топ-1000)
• Когда вы находитесь в середине метода, они примерно эквивалентны - это, вероятно, то, как построено большинство тестов, которые показывают, что два «одинаковы»
• Когда вы получаете доступ к сетевому контроллеру, физическое немного отбивает виртуальную машину - опять же, физическое не очень сильно сидит между процессом .NET и оборудованием. VM добавляет добавляет другие «вещи», через которые должна пройти каждая транзакция.
• Действительно, то же самое применимо к доступу к диску (SQL Server был на другом компьютере) - разница очень мала, но когда вы добавляете их все вместе, это заметно. Это могло быть вызвано более медленным доступом к сети или более медленным доступом к диску.

Я легко вижу, как кто-то может построить эталонные тесты, которые доказывают, что они отличаются на 1% или одинаковы или где виртуальные машины работают быстрее. Не включайте ничего, где ваш процесс использует преимущества локальной поддержки оборудования, когда виртуальная машина должна имитировать его в программном обеспечении.

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

Лучшим примером здесь является рассмотрение двух (или более!) Старых серверов в вашем центре обработки данных. Ищите серверы, которые работают достаточно хорошо, но уже устарели и подходят к циклу обновления. Эти серверы уже хорошо работают на старом оборудовании, и поэтому, благодаря закону Мура, все новое, что вы получите, станет намного сверхспециализированным.

Ну так что ты делаешь? Это просто. Вместо того, чтобы покупать два новых сервера, вы покупаете только один, а затем переносите оба старых сервера на одно и то же физическое новое устройство. Готовясь к покупке нового сервера, вы планируете, чтобы у вас было достаточно мощности, чтобы справиться не только с нагрузкой от обоих старых серверов, но и с любой нагрузкой от гипервизора (и, возможно, немного больше, чтобы вы все еще могли получить прирост производительности и может учесть рост).

Итак, виртуальные машины обеспечивают «достаточно хорошую» производительность для большинства ситуаций и помогают вам лучше использовать свои серверы, чтобы избежать «напрасной» вычислительной мощности.

Теперь давайте расширим это немного дальше. Поскольку это старые серверы, возможно, вы заменили их на пару простых серверов для пиццерий за 1500 долларов. Скорее всего, даже одна из этих коробок для пиццы все еще может легко справиться с нагрузкой с обеих гипотетических старых машин ... но допустим, вы решили вместо этого потратить 7500 долларов или больше на какое-то реальное оборудование. Теперь у вас есть устройство, которое может легко обрабатывать до десятка существующих серверов (в зависимости от того, как вы работаете с хранилищем и сетью), с первоначальной стоимостью всего 5. У вас также есть преимущества, связанные с управлением только одним физическим сервером, развязкой ваше программное обеспечение от вашего оборудования (т. е. для обновления оборудования теперь менее вероятно потребуется новая лицензия на windows или простои), вы экономите массу энергии и ваш гипервизор может дать вам более подробную информацию о производительности, чем вы ». В прошлом. Получите два из них, и в зависимости от того, насколько вы велики, возможно, весь ваш центр обработки данных урезан всего до двух машин, или, возможно, вы захотите использовать второй сервер в качестве горячего резерва, чтобы рассказать о высокой доступности.

Моя точка зрения заключается в том, что речь идет не только о производительности. Я бы никогда не взял совершенно хороший производственный сервер и виртуализировал бы его один на эквивалентное оборудование только потому, что. Это больше об экономии средств и других преимуществах, которые вы можете получить от консолидации, таких как высокая доступность. Реализация этих преимуществ означает, что вы перемещаете серверы на другое оборудование, а это, в свою очередь, означает, что вам необходимо уделить время для того, чтобы подобрать соответствующее оборудование, включая учет штрафов гипервизора. Да, вам может потребоваться чуть больше вычислительной мощности, чем если бы каждая из этих машин была на своем физическом устройстве (подсказка: вам, вероятно, понадобится гораздо меньше общей вычислительной мощности ), но это будет намного дешевле, более энергоэффективно, и проще в обслуживании запустить один физический сервер, чем запустить много.

Я только что перешел на SSD (OCZ Vertex 2) и на нем запущена среда разработки XP VM, я разработчик программного обеспечения. Одна вещь, которую я заметил, заключается в том, что когда я запускаю программу (достаточно большую, чтобы загружаться), одно ядро ​​виртуального ЦП отключается. Это происходит и при загрузке IE. Поскольку процессор не работает, я предполагаю, что узким местом является процессор, а не SSD. Но это кажется странным, у меня есть ощущение, что если бы то же самое было сделано на физической машине, то она бы загружалась быстрее, и я чувствую, что есть некоторые дополнительные издержки обработки, которые выполняет VMWare, потребляя процессор при доступе к диску.

Например, я использую Delphi, и на физической машине с обычным жестким диском запуск с холодной загрузки может занять 20 секунд. В виртуальной машине, работающей на SSD, она загружается за 19 секунд после холодного запуска. Не большая разница, держу пари, если бы SSD был на физической машине, он бы загружался быстрее. Однако я не проверял загрузку ЦП на физической машине, возможно, узким местом были и ЦП.

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

Очевидно, что виртуальная машина медленнее, чем физическая машина. Но когда вы находитесь в этом сценарии, вы должны оценить, что является оптимальным для удовлетворения ваших потребностей. Если вам нужна только одна система и она должна быть быстрой, установите ее непосредственно на оборудование. С другой стороны, если вам нужна гибкость, масштабируемость (и все другие преимущества виртуализации: P), разверните виртуальную машину. Это будет медленнее, но ИМХО в некоторых случаях это оправдано, а производительность не значительно медленная.

Похоже, что Microsoft провела некоторое тестирование производительности с использованием сервера BizTalk и SQL Server в различных конфигурациях в этом отношении. Смотрите ссылку ниже:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

В идеале производительность Virtual PC составляет:

Процессор: 96-97% хоста

Сеть: 70-90% хоста

Диск: 40-70% хоста

Извините, что не согласен с TomTom.

Некоторое время я использовал VMware Workstation, в основном на Windows XP, Windows Vista, а теперь и на собственных системах Windows Seven для запуска различных версий Windows, а также Ubuntu.

Да, виртуализированная среда медленнее, чем собственная система, и она может находиться в диапазоне от 5 до 100%.

Основная проблема не столько в загрузке процессора, сколько в недостатке физической памяти.

Допустим, у вас Windows Seven 64 Ultimate, работающая в системе 4 Гб, которая в режиме ожидания требует почти 1,5 Гб и использует ~ 10% процессорного времени. Запуск дополнительного слоя VMware обойдется вам в ~ 300 Кб, а загрузка процессора вырастет до ~ 20%. Затем при запуске виртуальной системы в VMware будет запрашиваться минимальный объем памяти, определенный для этой виртуальной машины, который составляет минимум 1 Гб для любой приличной системы. Тогда вы увидите нагрузку на процессор ~ 60%, если на виртуальной машине установлена ​​Ubuntu, и ~ 80% для любой разновидности недавней ОС Windows.

Теперь вы будете запускать различные приложения на этой виртуальной машине.

Если объем памяти, установленный для этой виртуальной машины, недостаточен, виртуализированная система начнет перестановку, что резко снизит ее общую производительность и быстродействие.

Если сумма объема памяти, которую вы установили для этой виртуальной машины, плюс объем памяти, необходимой для вашей родной системы, превышает объем памяти вашей родной системы, то ваша собственная система будет заменяться, замедляя как родная, так и виртуализированная система.

Итак, сначала это зависит от баланса памяти, необходимой как для нативных, так и для виртуализированных машин.

Теперь это почти то же самое с нагрузкой на процессор. Если виртуализированному приложению требуется огромная загрузка ЦП, а нативному приложению также требуется огромная загрузка ЦП, вашей нативной системе придется управлять приоритетом и балансировать нагрузку на ЦП между различными приложениями, а виртуализированная система - это не что иное, как приложение, но явление - это классическая проблема загрузки процессора, которую можно обмануть приоритетами приложения.

Итак, мой первый совет, если вам нужно использовать виртуализацию, это разместить кучу памяти на вашей машине, независимо от того, какую операционную систему вы используете изначально или внутри виртуальной машины.

Просто мои 2 цента.

С уважением.

По моему опыту, виртуальные машины всегда намного медленнее, чем физические.

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

Конечно, правильно настроенная виртуальная машина может достигать 80% (я не знаю реального числа) или любой другой скорости физической машины, но вам в конечном итоге придется по-настоящему углубиться в то, что делает приложение и как виртуальная машина работает. Так что я думаю, что это уравнение стоимости того, насколько ценно ваше время для настройки виртуальных машин, а просто для покупки и размещения нового сервера.

Для меня виртуальные машины - это НЕ ПРОИЗВОДИТЕЛЬНОСТЬ, а то, что ими проще управлять, и, конечно, для размещения нескольких низкопроизводительных виртуальных машин.