Автономный однопоточный оптимизированный сервер и виртуальная машина, работающая на VMWare
Прошу прощения за объем моего сообщения.
Недавно мы преобразовали нашу бизнес-систему в продукт, лицензированный по количеству ядер. Мы приобрели лицензию на 2 ядра и в настоящее время запускаем ее на VMWare. Переход на следующий уровень лицензии обходится довольно дорого.
У нас есть довольно серьезные проблемы с производительностью. Мы устранили ОЗУ как узкое место, а также доступ к сети, базе данных и дискам. Времена, когда у нас возникают проблемы, не всегда характеризуются высокой загрузкой процессора. Иногда загрузка ЦП составляет менее 20%, но уровень готовности ЦП высок.
Я размышляю о возможности запустить его непосредственно на отдельном физическом сервере. Поскольку я ограничен двумя ядрами, я бы выбрал самый быстрый процессор с однопоточной производительностью, который я мог получить, вероятно, 4 ядра. Затем я бы настроил бизнес-систему на использование двух ядер и позволил бы ОС использовать другие 2.
Моя логика выглядит примерно так. Прямо сейчас виртуальная машина получает два потока или vCPU. На самом деле это только один pCPU. Даже если бы я переместил его в тот же ящик без гиперпоточности, он получил бы 2 полных ядра вместо 2 vCPU. Но если я выберу микросхему, которая работает намного быстрее на одном потоке, я смогу получить значительно больше. Я также, вероятно, получил бы небольшой выигрыш, так как больше не буду его виртуализировать.
Наш текущий 6-ядерный процессор получил следующие оценки в соответствии с Passmark. Марка процессора: 8570 Однопоточная производительность: 1403
4-ядерный процессор, который мне нужен, получил эти оценки. Марка процессора: 10231 Однопоточная производительность: 2287
Имеет ли смысл строить сервер специально, чтобы добиться максимальной производительности однопоточного приложения для такого приложения? Есть ли минусы, о которых мне нужно беспокоиться? Будет ли новая ОС иметь большое значение?
Текущий хост-сервер имеет следующие характеристики: Proliant DL380 G7 2 физических процессора: Intel (R) Xeon (R) X5675 @ 3,07 ГГц 6 ядер каждое для 24 логических процессоров (vCPU) всего Гиперпоточность включена. 144 ГБ ОЗУ
Хранилище находится в более новой сети SAN, и я уверен, что это не играет роли в наших проблемах с производительностью.
Виртуальная машина бизнес-системы настроена с 2 виртуальными ЦП и 24 ГБ ОЗУ. Операционная система - Windows Server 2008 R2. Программное обеспечение бизнес-системы оптимизировано для работы на 4–6 ГБ ОЗУ в пуле приложений в IIS. Я никогда не видел, чтобы объем используемой виртуальной машины превышал 16 ГБ.
Мы также запускаем 3 другие виртуальные машины на хосте. Один действительно сейчас очень мало делает и, вероятно, будет отключен в самом ближайшем будущем. Он имеет 2 виртуальных ЦП и 8 ГБ ОЗУ.
На втором работает наша база данных MS Sql. У него 8 виртуальных ЦП и 64 ГБ оперативной памяти. У нас был администратор баз данных, который изучил это, и он не считает, что это причина наших проблем, по крайней мере, не со стороны производительности базы данных.
На третьей виртуальной машине работает наш общедоступный веб-сайт. В среднем он использует менее 25 процентов процессора. Он имеет 3 виртуальных ЦП и 16 ГБ ОЗУ.
Еще раз, любая помощь или мудрость, которые вы можете предоставить, будут замечательными и очень ценными.
Спасибо!
Пара вещей:
1) Постарайтесь ограничить себя тем количеством виртуальных ЦП, которое действительно необходимо вашей виртуальной машине. Это связано с планировщиком ресурсов в VMware ESXi: если у вас есть виртуальная машина с 8 виртуальными ЦП, он должен найти временной интервал на физическом процессоре, у которого в данный момент есть 8 свободных ядер, чтобы запустить тактовый цикл виртуальной машины. Таким образом, если у вас 6 ядер на процессор, планировщик должен найти временной интервал на обоих процессорах, что в основном приостанавливает все остальное. Виртуальные машины не работают постоянно, как физические машины, они «заморожены» между тактовыми циклами, и если у планировщика возникнут проблемы с поддержанием ваших виртуальных машин, все больше и больше времени будут «заморожены». Если вы не используете огромную базу данных на виртуальной машине SQL, попробуйте снизить количество виртуальных ЦП до 6 и посмотрите, не улучшит ли это ситуацию. Обычно я использую 1 виртуальный ЦП по умолчанию, 2 для больших виртуальных машин и до 4 для некоторых более крупных баз данных. Я никогда не видел необходимости добавлять больше.
2) Забудьте о HyperThreading в VMware, это дает вам немного больше производительности, около 10% согласно некоторым тестам VMware, так что оставьте это включенным, но не в счет при увеличении производительности в 2 раза при выборе оборудования.
3) ЦП с более высокой тактовой частотой обеспечивают более высокую производительность одного потока, но меньшее количество ядер дает меньше возможностей для запуска большего количества виртуальных машин. Есть причина, по которой VMware показывает вам совокупную скорость всех ядер на хосте, по сути, так ESXi рассматривает ЦП как совокупный пул вычислительной мощности.
Вы правы в своих предположениях. Для вашего конкретного случая правильным решением будет укладка Mhz вместо vCore. Взгляните на этот процессор : (включает 4 физических ядра 3,5–3,7 ГГц + HT).
Однако я не могу увидеть реальную проблему из того, что вы описали, если вы не можете предоставить ваше фактическое значение "CPU Ready".