Прошу прощения за объем моего сообщения.
Недавно мы преобразовали нашу бизнес-систему в продукт, который лицензируется по количеству ядер. Мы приобрели лицензию на 2 ядра и в настоящее время запускаем ее на VMWare. Переход на следующий лицензионный уровень обходится довольно дорого.
У нас есть довольно серьезные проблемы с производительностью. Мы устранили ОЗУ как узкое место, а также доступ к сети, базе данных и дискам. Времена, когда у нас возникают проблемы, не всегда характеризуются высокой загрузкой процессора. Иногда загрузка ЦП составляет менее 20%, но готовность ЦП высока.
Я обдумываю возможность запуска его непосредственно на отдельном физическом сервере. Поскольку я ограничен двумя ядрами, я бы выбрал самый быстрый процессор с однопоточной производительностью, который я мог получить, вероятно, 4 ядра. Затем я бы настроил бизнес-систему на использование двух ядер и позволил бы ОС использовать два других.
Моя логика выглядит примерно так. Прямо сейчас виртуальная машина получает два потока или 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), всего включена Hyperthreading. 144 ГБ оперативной памяти
Хранилище находится в более новой сети SAN, и я уверен, что это не играет роли в наших проблемах с производительностью.
Виртуальная машина бизнес-системы сконфигурирована с 2 виртуальными ЦП и 24 ГБ ОЗУ. Операционная система - Windows Server 2008 R2. Программное обеспечение бизнес-системы оптимизировано для работы на 4–6 ГБ ОЗУ в пуле приложений в IIS. Я никогда не видел, чтобы размер виртуальной машины превышал 16 ГБ.
Мы также запускаем 3 другие виртуальные машины на хосте. Один действительно сейчас очень мало делает и, вероятно, будет отключен в самом ближайшем будущем. Он имеет 2 виртуальных процессора и 8 ГБ оперативной памяти.
На втором работает наша база данных MS Sql. У него 8 виртуальных ЦП и 64 ГБ оперативной памяти. У нас был администратор баз данных, который изучил это, и он не считает, что это причина наших проблем, по крайней мере, со стороны производительности базы данных.
На третьей виртуальной машине работает наш общедоступный веб-сайт. В среднем он использует менее 25 процентов процессора. Он имеет 3 виртуальных процессора и 16 ГБ оперативной памяти.
Еще раз, любая помощь или мудрость, которые вы можете предоставить, будут замечательными и очень ценными.
Спасибо!
Вы правы в своих предположениях. Для вашего конкретного случая правильным решением будет укладка Mhz вместо vCore. Взгляните на это процессор: (включает 4 физических ядра 3,5-3,7 ГГц + HT).
Однако я не могу увидеть реальную проблему из того, что вы описали, если вы не можете предоставить свое фактическое значение «CPU Ready».
Пара вещей;
1) Постарайтесь ограничить себя тем количеством виртуальных ЦП, которое действительно необходимо вашей виртуальной машине. Это связано с планировщиком ресурсов в VMware ESXi: если у вас есть виртуальная машина с 8 виртуальными ЦП, он должен найти временной интервал на физическом процессоре, у которого в данный момент есть 8 свободных ядер, чтобы запустить тактовый цикл виртуальной машины. Таким образом, если у вас есть 6 ядер на процессор, планировщик должен найти временной интервал на обоих процессорах, что в основном приостанавливает все остальное. Виртуальные машины не работают постоянно, как физические машины, они «заморожены» между тактовыми циклами, и если у планировщика возникнут проблемы с поддержанием ваших виртуальных машин, все больше и больше времени будут «заморожены». Если вы не используете огромную базу данных на виртуальной машине SQL, попробуйте снизить количество виртуальных ЦП до 6 и посмотрите, не улучшит ли это ситуацию. Обычно я использую 1 виртуальный ЦП по умолчанию, 2 для более крупных виртуальных машин и до 4 для некоторых более крупных баз данных. Я никогда не видел необходимости добавлять больше.
2) Забудьте о HyperThreading в VMware, это дает вам немного больше производительности, около 10% согласно некоторым тестам VMware, поэтому оставьте его включенным, но не рассчитывайте на увеличение производительности в 2 раза при выборе оборудования.
3) ЦП с более высокой тактовой частотой обеспечивают более высокую производительность одного потока, но меньшее количество ядер дает меньше возможностей для запуска большего количества виртуальных машин. Есть причина, по которой VMware показывает вам совокупную скорость всех ядер на хосте, по сути, так ESXi рассматривает ЦП как совокупный пул вычислительной мощности.