Сколько накладных расходов имеет виртуализация x86/x64?

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

Это становится более сложным при попытке найти связь между различными тестами. Ни одно из протестированных мной решений не показало хорошую производительность при тестировании микроопераций. Например: Внутри ВМ один единственный вызов gettimeofday() занял в среднем в 11,5 раза больше тактов, чем на аппаратном. Гипервизоры оптимизированы для реальных приложений и плохо работают на микрооперациях. Это может не быть проблемой для вашего приложения, которое может лучше подходить для реального приложения. Под микрооперацией я подразумеваю любое приложение, которое тратит менее 1000 тактов на завершение (для процессора с тактовой частотой 2,6 ГГц 1000 тактов расходуется за 385 наносекунд или 3,85e-7 секунд).

Я провел обширное тестирование производительности четырех основных решений для консолидации центров обработки данных для архитектуры x86. Я провел почти 3000 тестов, сравнивая производительность внутри виртуальных машин с аппаратной производительностью. Я назвал "накладные расходы" разницей максимальной производительности, измеряемой внутри ВМ, с максимальной производительностью, измеряемой на оборудовании.

Решения:

• VMWare ESXi 5
• Microsoft Hyper-V Windows 2008 R2 с пакетом обновления 1
• Citrix XenServer 6
• Red Hat Enterprise Virtualization 2.2

Гостевые ОС:

• Microsoft Windows 2008 R2 64 бит
• Red Hat Enterprise Linux 6.1 64 бит

Тестовая информация:

• Серверы: 2X Sun Fire X4150 каждый с 8 ГБ ОЗУ, 2X процессор Intel Xeon E5440 и четыре гигабитных порта Ethernet
• Диски: 6X 136 ГБ дисков SAS через iSCSI через гигабитный Ethernet

Программное обеспечение Benchmark:

• Процессор и память: тест Linpack для 32 и 64 бит. Это требует много ресурсов процессора и памяти.

• Дисковый ввод-вывод и задержка: Бонни ++

• Сетевой ввод-вывод: Netperf: TCP_STREAM, TCP_RR, TCP_CRR, UDP_RR и UDP_STREAM

• Микрооперации: rdtscbench: системные вызовы, межпроцессное взаимодействие

Средние значения рассчитываются по параметрам:

• Процессор и память: СРЕДНИЙ (HPL32, HPL64)

• Дисковый ввод / вывод: AVERAGE(put_block, rewrite, get_block)

• Сетевой ввод / вывод: AVERAGE(tcp_crr, tcp_rr, tcp_stream, udp_rr, udp_stream)

• Микрооперации AVERAGE(getpid(), sysconf(), gettimeofday(), malloc[1M], malloc[1G], 2pipes[], simplemath[])

Для моего тестового сценария, используя мои метрики, средние результаты четырех решений виртуализации:

Накладные расходы слоя виртуальной машины, гостевой Linux:

• Процессор и память: 14,36%

• Сетевой ввод / вывод: 24,46%

• Дисковый ввод / вывод: 8,84%

• Задержка диска для чтения: в 2,41 раза медленнее

• Время выполнения микроопераций: в 10,84 раза медленнее

Накладные расходы слоя виртуальной машины, гостевой Windows:

• Средняя загрузка процессора и памяти для 32 и 64 бит: 13,06%

• Сетевой ввод / вывод: 35,27%

• Дисковый ввод / вывод: 15,20%

Обратите внимание, что эти значения являются общими и не отражают сценарий конкретных случаев.

Пожалуйста, ознакомьтесь с полной статьей: http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solutions

В вашем вопросе слишком много переменных, однако я мог бы попытаться сузить их. Предположим, что вы работаете с VMware ESX, вы все делаете правильно - новейший процессор с поддержкой виртуализации, инструменты VMware с паравиртуализированным хранилищем и сетевые драйверы, много памяти. Теперь давайте предположим, что на этой установке вы запускаете одну виртуальную машину. По моему опыту, вы должны иметь ~90% скорости процессора для рабочей нагрузки, связанной с процессором. Я не могу рассказать вам много о скорости сети, так как мы используем ссылки 1 Гбит / с, и я могу без проблем насытить ее, она может отличаться от 10 Гбит / с, однако у нас их нет. Пропускная способность хранилища зависит от типа хранилища, при этом я могу получить около 80% пропускной способности хранилища с локальным хранилищем, но для NFS 1 Гбит / с она близка к 100%, так как сетевое подключение здесь является узким местом. Не можете рассказать о других показателях, вам нужно будет поэкспериментировать с вашим собственным кодом.

Эти цифры очень приблизительны и сильно зависят от вашего типа нагрузки, вашего оборудования, вашей сети. Это становится еще более размытым, когда вы запускаете несколько рабочих нагрузок на сервер. Но я хочу сказать, что в идеальных условиях вы должны быть в состоянии достичь как минимум 90% производительности.

Кроме того, по моему опыту, гораздо более серьезной проблемой для высокопроизводительных приложений является задержка, и это особенно актуально для клиент-серверных приложений. У нас есть вычислительный движок, который получает запрос от 30+ клиентов, выполняет короткие вычисления и возвращает результаты. На голом железе он обычно увеличивает нагрузку на процессор до 100%, но тот же сервер на VMware может загружать процессор только на 60-80%, и это в основном из-за задержки в обработке запросов / ответов.

Я не обращал внимания на производительность основных примитивов, таких как переключение контекста и атомарные операции, но вот мои результаты теста грубой силы, который я недавно провел с различными гипервизорами. Это должно указывать на то, что вы можете ожидать, если у вас ограничена пропускная способность ЦП и ОЗУ.

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/