Назад | Перейти на главную страницу

Однопоточное приложение на VMware X5650 на 50% медленнее, чем физическое E5450

Наше приложение на Xeon X5650 под ESX работает на 50% медленнее, чем на E5450 без покрытия.

Тестовое задание на физических серверах занимает 17 минут.

Та же задача на виртуальных серверах занимает 25 минут: на 50% больше.

Из всего, что я могу сказать, это должно быть невозможно; Предполагается, что серия 5600 на 10-20% быстрее, чем серия 5400 для однопоточных процессов при той же тактовой частоте, а накладные расходы виртуализации должны быть столь же низкими для однопоточных рабочих нагрузок, связанных с процессором. Производительность должна быть на наименее безубыточность, не так ли? Но вместо того, чтобы иметь такую ​​же или лучшую производительность, производительность снижается на 1/3.


ОБНОВЛЕНИЕ: решено. Та же задача на (фиксированных) виртуальных серверах занимает 14 минут: на 15% быстрее.

Это была конфигурация RAM. Падение производительности на 50% произошло из-за того, что системная память хоста ESX установлена ​​неправильно и обеспечивает только половину всей возможной пропускной способности. Для процесса, связанного с процессором и памятью, эта потеря пропускной способности привела к снижению производительности на 50%, чем ожидалось.

Производительность приложений сейчас находится посредине ожидаемого улучшения на 10-20%.


Существуют две физические системы Windows Server 2003 R2, в которых выполняется приложение, состоящее из однопоточных вычислений, выполняемых на одном сервере (32-разрядном), с обменом данными с базой данных SQL Server 2005 на другом (64-разрядном).

Оба физических блока - однопроцессорные E5450 с 4 ГБ оперативной памяти при 800 МГц. Вычислительный сервер никогда не использует более 1,5 ГБ физической памяти, а SQL Server никогда не использует более 2,5 ГБ. Загрузка ЦП на вычислительном сервере никогда не превышает ~ 15% (около 50% от одного ядра). Загрузка ЦП на сервере БД никогда не превышает ~ 25% (полностью загруженное одно ядро).

Физические хосты ESX 4.1 представляют собой двухпроцессорный X5650 с 64 ГБ ОЗУ при 1333 МГц. Виртуальным машинам выделяется 4 ядра и 4 ГБ ОЗУ каждой для зеркалирования физической среды. Тест проводился с одной виртуальной машиной, работающей на каждом физическом хосте, а также с обеими на одном и том же хосте.

Интересно, что мы получаем почти такие же результаты 25-минутного тестирования на другой паре серверов ESX с процессорами X5550 и RAM @ 1066Mhz.

Кроме того, результаты тестирования в виртуальных системах не различаются более чем на 10% в любом случае, если виртуальным машинам предоставляется 1, 2 или 4 ЦП или 1, 2, 4 или 8 ГБ ОЗУ. Сетевая или дисковая активность очень мала, и, насколько я могу судить, процесс должен зависеть от ЦП.

Тесты проводились с использованием как локальных дисков SAS 15 КБ на отдельных хостах, так и гигабитного iSCSI SAN, также с дисками 15 КБ. Для разных хранилищ результаты незначительны.

Из всего, что я могу сказать, серия Xeon 5600 должна быть на 20-50% быстрее, чем серия 5400 для однопоточных рабочих нагрузок. Даже с учетом того, что X5650 - это часть с частотой 2,67 ГГц, а E5450 - с частотой 3 ГГц, если бы производительность на ядро ​​была одинаковой при одинаковой тактовой частоте, вы все равно ожидали бы увидеть не менее 90% производительности вместо 67%. Это даже не учитывает тот факт, что частота памяти почти вдвое превышает скорость.

Следует сказать, что в прошлом я реализовал несколько проектов виртуализации и никогда не видел падения производительности, близкого к 50%, даже при использовании ОДИНАКОВЫХ физических ядер ЦП, не говоря уже о ядрах на два поколения новее с более быстрой памятью.

Есть идеи по поводу возможных причин или каких-либо настроек конфигурации, которые я должен проверить?

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

Имейте в виду, что это может зависеть от очень многих факторов. Виртуализация, как правило, увеличивает задержку между дисками и гостевой ОС. Это увеличит время ожидания ввода-вывода и, следовательно, среднюю нагрузку, сохраняя при этом довольно низкую загрузку процессора. Если ваше хранилище находится на нижней стороне шкалы IOPS, это будет иметь очень большое влияние. Если вы используете сетевое хранилище, это почти всегда увеличивает задержку из-за необходимости доступа к сети для каждого ввода-вывода вместо простого доступа к внутренней шине.

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

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

Из-за однопоточной природы вашего приложения увеличение количества ядер не приведет к значительному повышению производительности. Оба процессора имеют схожие частоты, но вы заметите, что X5650 имеет более низкую частоту без "Turbo Boost". Вы можете проверить, совместима ли эта функция / включена с вашей настройкой.

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