Это довольно общий вопрос, но, в частности, меня интересует, будет ли виртуальная машина с Ubuntu Enterprise Cloud работать медленнее, чем такая же физическая машина без какой-либо виртуализации. Сколько (1%, 5%, 10%)?
Кто-нибудь измерял разницу в производительности веб-сервера или сервера db (виртуальный VS физический)?
Если это зависит от конфигурации, давайте представим себе два четырехъядерных процессора, 12 ГБ памяти и набор SSD-дисков, на которых работает 64-разрядный корпоративный сервер ubuntu. Кроме того, всего 1 виртуальная машина позволяла использовать все доступные ресурсы.
Типичная рабочая нагрузка сервера общего назначения на «голом железе» гипервизора типа 1 составляет около 1–5% накладных расходов ЦП и 5–10% накладных расходов на память, с некоторыми дополнительными накладными расходами, которые зависят от общей нагрузки ввода-вывода. Это в значительной степени согласуется с моим опытом работы с современными гостевыми ОС, работающими под VMware ESX \ ESXi, Microsoft Hyper-V и Xen, где базовое оборудование было должным образом спроектировано. Для 64-разрядных серверных операционных систем, работающих на оборудовании, которое поддерживает самые современные расширения аппаратной виртуализации ЦП, я ожидал, что все гипервизоры типа 1 будут иметь этот показатель накладных расходов в 1%. Зрелость KVM на данный момент не совсем подходит для Xen (или VMware), но я не вижу причин полагать, что это будет заметно хуже, чем у них в описываемом вами примере.
Для конкретных случаев использования общая \ совокупная "производительность" виртуальной среды может превышать "голые" \ дискретные серверы. Вот пример обсуждения о том, как реализация VMware Clustered может быть быстрее \ лучше \ дешевле, чем Oracle RAC без операционной системы. Методы управления памятью VMware (особенно прозрачное совместное использование страниц) могут почти полностью устранить накладные расходы на память, если у вас достаточно достаточно похожих виртуальных машин. Во всех этих случаях важно то, что преимущества производительности \ эффективности, которые может предоставить виртуализация, будут реализованы только в том случае, если вы консолидируете несколько виртуальных машин на хостах, ваш пример (1 виртуальная машина на хосте) всегда будет в некоторой степени медленнее, чем голый металл. .
Хотя все это полезно, реальные проблемы с точки зрения виртуализации серверов, как правило, связаны с управлением, методами высокой доступности и масштабируемостью. Запас производительности ЦП 2–5% не так важен, как возможность эффективного масштабирования до 20, 40 или любого необходимого количества виртуальных машин на каждом хосте. Вы можете справиться со снижением производительности, выбрав немного более быстрый ЦП в качестве базового уровня или добавив больше узлов в свои кластеры, но если хост не может масштабировать количество виртуальных машин, которые он может запустить, или средой трудно управлять или ненадежный, тогда он бесполезен с точки зрения виртуализации серверов.
«Производительность» имеет много аспектов. N00bs измеряют время загрузки ОС и говорят, например, Windows 2012 оооочень хороша, потому что загружается за 12 секунд на реальном HD, может быть, за 1 секунду на SSD.
Но такая мера не очень полезна: производительность равна времени загрузки ОС, но ОС загружается раз в месяц, поэтому оптимизация не имеет особого смысла.
Поскольку это моя повседневная работа, я могу указать на следующие 4 части, составляющие "производительность"
Загрузка процессора
Это должно быть сопоставимо, что означает, что задача, занимающая 1000 мс на голом железе, будет выполняться за время процесса 1000 мс и, вероятно, 1050 мс тактового времени в среде бездействующей виртуальной машины на том же оборудовании (некоторые подробности позже). Google MSDN для processtime и queryperformancecounter и yu может сделать кое-что, что может показать, насколько виртуальная машина потребляет ваше процессорное время.
Производительность SQL
Производительность SQL сильно зависит от операций ввода-вывода в хранилище данных, в котором хранятся данные SQL. Я видел 300% -ную разницу между ISCSI 1-го поколения, которую вы можете найти на домашнем NAS Buffalo, затем ISCSI с DCE и настоящей старой средой FC на всех уровнях. FC по-прежнему выигрывает в настоящее время, потому что задержка FC является самой низкой из возможных, что приводит к «копии» протокола FC для улучшений центра обработки данных TCP / IP. Здесь важны операции ввода-вывода и задержка, но также и пропускная способность ввода-вывода от серверного процесса до носителя - зависит от того, стремится ли приложение к No-SQL или к хранилищу данных, или находится в середине этого процесса, как системы ERP ... Sage KHK для малых предприятий, SAP для огромных. У обоих есть взгляд генерального директора на финансовую статистику предприятия, и когда генеральный директор нажимает кнопку, он фактически предоставляет отпуск на несколько дней, когда подсистема ввода-вывода базы данных имеет недостатки.
Доступ к файловой системе
Некоторые приложения, такие как потоковое видео, полагаются на гарантированную минимальную пропускную способность, другие полагаются на максимальную пропускную способность ввода-вывода, например, просто открывая большие файлы в шестнадцатеричном редакторе, загружая видеопроект в вашу любимую программу для создания фильмов. Нетипичная ситуация на виртуальной машине .... Операции ввода-вывода также могут быть важны для разработчиков. Разработчики часто используют виртуальные машины, потому что среды разработки очень чувствительны, и поэтому соблазн сделать это в виртуальной машине велик. Компиляция большого проекта часто означает чтение тонны маленьких файлов, выполнение работы с компилятором и создание EXE и сопутствующих компонентов.
Сетевая задержка для клиента
Здесь удобство использования программ WYSIWIG, таких как word 2010, Openoffice Writer, LaTEX, GSView и других, в значительной степени зависит от скорости - от того, насколько быстро действие мыши передается от клиента к серверу. Это важно, особенно в приложениях САПР ... но также не проблема локальной сети, это удаленный доступ через глобальную сеть, где это важно.
Но - и я говорю с точки зрения многолетнего консультирования - есть пользователи, имеющие пароль администратора (и они часто являются сотрудниками БОЛЬШОЙ компании с БОЛЬШИМ бюджетом и БОЛЬШИМ кошельком), жалующиеся на то и это, но это необходимо уточнить какой компонент производительности важен для них, а какой важен с точки зрения приложения, которое они используют.
Скорее всего, это не блокнот, а очень сложное приложение для разработки того и другого, которое также было очень дорогостоящим, и его следует перенести на VMware, HyperV или Xenapp, и оно не работает так, как ожидалось.
Но они не имеют в виду, что он может работать на Xeon с частотой 1,5 ГГц на блейд-серверах, которые не предназначены для чистой производительности ЦП, они созданы для средней производительности, скажем, «оптимизированы для долларов за цикл процессора» или «циклов процессора на ватт» .
А когда мы говорим о компромиссах и экономии - это в основном приводит к чрезмерным обязательствам. Избыточные обязательства приводят к нехватке ресурсов, где ЦП может обрабатываться довольно хорошо, но нехватка памяти приводит к подкачке, отсутствие ввода-вывода в основных маршрутизаторах приводит к увеличению времени ответа на все, а перегрузка транзакций в любом виде хранилища может остановить каждое полезное приложение от слишком быстрого ответа. Здесь требуется мониторинг, но многие поставщики программного обеспечения не могут предоставить такую информацию .... с другой стороны, хост с ресурсами из 3 физических серверов, скорее всего, может обрабатывать 8 виртуальных машин того же макета, что и физические ...
Компромисс между процессорами и простаивающими системами часто приводит к тому, что системы работают на 50% медленнее, чем физические системы, с другой стороны, никто не может установить операционную систему «реального мира» и приложение «реального мира», которое ИТ-специалисты заказчика хотят переместить в виртуальную машину. коробка. И нужны дни (может быть, недели, но наверняка 42 встречи), чтобы понять, что технология виртуальных машин может предложить гибкость, торгуя чистой скоростью процессора. Он просто встроен в процессоры этих блейд-систем, в которых в настоящее время размещаются более крупные виртуальные машины. Также память не будет сопоставима, также есть некоторые компромиссы. 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 Mobile и процессор T5440. Он был стабильным при разрешении 1280x800 и воспроизводился даже в сетевых играх ....
Я хотел бы отметить, что виртуализация может превышать физическую производительность в определенных ситуациях. Поскольку сетевой уровень не ограничен гигабитной скоростью (даже если аппаратная эмуляция относится к определенной сетевой карте), виртуальные машины на одном сервере могут обмениваться данными между собой со скоростью, превышающей скорость нескольких физических серверов со средним сетевым оборудованием.
Да. Но вопрос не в этом. Разница обычно незначительна (от 1% до 5%).
Я проводил несколько тестовых сравнений одного и того же программного обеспечения, выполняющего тот же тест (веб-приложение на основе .NET с большим объемом веб-трафика и значительным доступом к SQL Server). Вот что я видел:
Я легко вижу, как кто-то может построить тесты, которые доказывают, что они на 1% отличаются или одинаковы, или где виртуальные машины работают быстрее. Не включайте ничего, где ваш процесс использует преимущества локальной аппаратной поддержки, если виртуальная машина должна моделировать это в программном обеспечении.
Вы пытаетесь сравнить операционную систему, программное обеспечение и данные, установленные на определенном физическом оборудовании, с той же операционной системой, программным обеспечением и данными, установленными отдельно внутри гипервизора на том же исходном оборудовании. Это сравнение просто неверно, потому что этим почти никто не занимается (по крайней мере, сначала). Конечно, это, вероятно, будет медленнее. К счастью, он полностью упускает из виду самый распространенный момент, почему вы вообще виртуализируете серверы.
Лучшим примером здесь является рассмотрение двух (или более!) Старых серверов в вашем центре обработки данных. Ищите серверы, которые работают достаточно хорошо, но уже устарели и скоро обновятся. Эти серверы уже хорошо работают на старом оборудовании, и поэтому, благодаря закону Мура, все новое, что вы получите, будет сильно завышено.
Ну так что ты делаешь? Это просто. Вместо того, чтобы покупать два новых сервера, вы покупаете только один, а затем переносите оба своих старых сервера на одно и то же новое физическое устройство. При подготовке к покупке нового сервера вы планируете, чтобы у вас было достаточно мощности, чтобы не только справиться с нагрузкой от обоих старых серверов, но и с любой нагрузкой от гипервизора (и, возможно, немного больше, чтобы вы все еще могли повысить производительность и может позволить рост).
Подводя итог: виртуальные машины обеспечивают «достаточно хорошую» производительность для большинства ситуаций и помогают лучше использовать серверы, чтобы избежать «бесполезной траты» вычислительной мощности.
Теперь давайте растянем это немного дальше. Поскольку это старые серверы, возможно, вы искали пару простых серверов для пиццы за 1500 долларов, чтобы заменить их. Скорее всего, даже одна из этих коробок для пиццы может легко справиться с нагрузкой от обеих гипотетических старых машин ... но допустим, вы решили вместо этого потратить 7500 долларов или больше на какое-то реальное оборудование. Теперь у вас есть устройство, которое может легко обрабатывать до дюжины ваших существующих серверов (в зависимости от того, как вы управляете хранилищем и сетью), с начальной стоимостью всего 5. У вас также есть преимущества управления только одним физическим сервером с разделением ваше программное обеспечение с вашего оборудования (то есть: обновление оборудования теперь с меньшей вероятностью потребует новой лицензии Windows или приведет к простоям), вы сэкономите тонну на электроэнергии, а ваш гипервизор может предоставить вам лучшую информацию о производительности, чем в прошлом . Получите два из них, и в зависимости от вашего размера, возможно, весь ваш центр обработки данных ограничен двумя машинами или, возможно, вы захотите использовать второй сервер в качестве горячего резерва, чтобы лучше рассказать историю высокой доступности.
Я хочу сказать, что дело не только в производительности. Я бы никогда не взял идеальный производственный сервер и не виртуализировал его только на эквивалентное оборудование только потому, что. Скорее речь идет об экономии затрат и других преимуществах, которые вы можете получить от консолидации, таких как высокая доступность. Осознание этих преимуществ означает, что вы перемещаете серверы на другое оборудование, а это, в свою очередь, означает, что вам нужно потратить время на то, чтобы правильно определить размер этого оборудования, включая учет штрафов за гипервизор. Да, вам может потребоваться немного больше вычислительной мощности, чем если бы каждая из этих машин была на своем собственном физическом устройстве (подсказка: вам, вероятно, понадобится намного меньше общая вычислительная мощность), но это будет намного дешевле, более энергоэффективно и проще в обслуживании для запуска одного физического сервера, чем для запуска многих.
Я только что обновился до SSD (OCZ Vertex 2) и запускаю на нем свою среду разработки виртуальной машины XP, я разработчик программного обеспечения. Я заметил одну вещь: когда я запускаю программу (достаточно большую, чтобы загружаться), одно ядро виртуального процессора отключается. Это происходит и при загрузке IE. Поскольку ЦП не работает, я предполагаю, что узким местом является ЦП, а не SSD. Но это кажется странным, у меня есть ощущение, что если бы то же самое было сделано на физической машине, она бы загружалась быстрее, и я чувствую, что есть некоторые дополнительные накладные расходы на обработку, которые выполняет VMWare, которые потребляют ЦП при доступе к диску.
Например, я использую Delphi, и на физической машине с обычным жестким диском запуск из «холодной» загрузки может занять 20 секунд. В виртуальной машине, работающей от SSD, она загружается за 19 секунд после холодного запуска. Не большая разница, держу пари, если бы SSD был на физическом компьютере, он бы загружался быстрее. Хотя я не проверял использование ЦП на физической машине, возможно, ЦП был узким местом и там.
Но ощущение от виртуальной машины таково, что доступ к диску требует от виртуальной машины.
Очевидно, что виртуальная машина медленнее, чем физическая. Но когда вы находитесь в этом сценарии, вы должны оценить, что является оптимальным для удовлетворения ваших потребностей. Если вам нужна только одна система и она должна быть быстрой, установите ее прямо на оборудование. С другой стороны, если вам нужна гибкость, масштабируемость (и все другие преимущества виртуализации: P), разверните виртуальную машину. Это будет медленнее, но ИМХО в некоторых случаях это оправдано и производительность не сильно замедляется.
Похоже, что Microsoft провела несколько тестов производительности с использованием BizTalk server и 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% (я не знаю реального числа) или любой другой скорости физической машины, но в конечном итоге вам придется действительно глубоко копаться в том, что делает приложение и как виртуальная машина работает. Так что я предполагаю, что это уравнение стоимости того, насколько ценно ваше время для настройки виртуальных машин, а не просто покупка и размещение нового сервера.
Для меня виртуальные машины - это НЕ О ПРОИЗВОДИТЕЛЬНОСТИ, а о том, чтобы ими было проще управлять и, конечно, для размещения нескольких низкопроизводительных виртуальных машин.