У нас возникла проблема с производительностью, которую мы не можем объяснить в нашей среде VMWare, и я надеюсь, что кто-то здесь сможет нам помочь. У нас есть веб-приложение, которое использует бэкэнд баз данных. У нас есть настройка кластера SQL 2005 на Windows 2003 R2 между физическим узлом и виртуальным узлом. Оба физических сервера идентичны 2950 с 2x Xeaon x5460 Quad Core CPU и 64 ГБ памяти, 16 ГБ выделено для ОС. Мы используем iSCSI San для всех дисков кластера. Проблема в том, что при использовании приложения в условиях повторного стресс-тестирования, которое добавляет CPU к узлам кластера, физический узел масштабируется с 1 pCPU до 8 pCPU, то есть мы видим постоянное увеличение производительности. При тестировании узла, работающего под управлением Vsphere, у нас ожидаемое падение производительности на 12% из-за виртуализации, но мы все еще масштабируемся с 1 vCPU до 4 vCPU, как и физический, но за пределами этого производительность падает, к тому времени, как мы доходим до 8 vCPU, мы видим показатели производительности хуже, чем при 4 vCPU. Опять же, оба узла настроены одинаково с точки зрения оборудования, гостевой ОС, конфигураций SQL и т. д., и нет никакого трафика, кроме тестового в системе. На виртуальном сервере нет других виртуальных машин, поэтому не должно быть никакой конкуренции за ресурсы. Мы обратились за помощью в VMWare, но они на самом деле не предложили ничего вроде настройки SQL Processor Affinity, которая, хотя и была бы полезной, имела бы тот же чистый эффект на каждом блоке и не должна была бы изменить наши результаты ни в малейшей степени. Мы просмотрели все руководства VMWare по настройке SQL в отношении VSphere, но безрезультатно, пожалуйста, помогите!
решение1
Я не решаюсь вводить это как ответ, потому что у меня нет конкретной поддержки этого, но это может быть причиной проблемы, которую вы видите. Я слышал раньше (иэтотстраница вроде как поддерживает это), что планирование ЦП VMWare затрудняется, когда у ВМ несколько ЦП. Для ВМ с одним ЦП необходимо запланировать только один хост-процессор. Однако, когда у ВМ их больше одного, VMWare приходится планировать несколько процессоров, чтобы они были доступны для ВМ, что может занять больше времени. Планировать это будет все сложнее по мере увеличения количества ЦП ВМ, что означает, что ВМ фактически видит худшую производительность, поскольку ей сложнее получить выделенное ей процессорное время.
Кроме того, я перечитал ваш последний комментарий, и у меня тоже в последнее время возникли проблемы с конкуренцией в vSphere. Еще одна вещь, которую вы можете попробовать (если вы еще этого не сделали), — это увеличить выделение ресурсов для этой виртуальной машины, даже если это единственная виртуальная машина там на данный момент.
решение2
У вас тут довольно аккуратная установка ;-)
Используются ли vCPU на максимальную мощность? О чем говорят графики ожидания CPU, готовности CPU и использования CPU?
Чем больше vCPU вы добавляете в VM, тем больше накладных расходов генерируется на хост-системе для управления vCPU и сопоставления их с физическим. В какой-то момент вы не сможете получить большую производительность от VM, просто добавляя больше vCPU.
Вы проверили, есть ли проблемы с производительностью в iSCSI SAN? Проверьте графики запросов на чтение и запись на диск и, конечно, скорости чтения и записи на диск и сравните их с показателями физического члена кластера.
Возможно, некоторые из ценностей укажут вам правильное направление.
решение3
Просто для ясности: вы используете 8-ядерный (2 x 4) ESX-бокс для размещения одной 8-процессорной виртуальной машины и не видите реального прироста производительности для 5-го и последующих vCPU, верно? Могу ли я спросить, почему вы не используете тот же хост в качестве физического SQL-бокса вместо этого? Вы используете лицензии Enterprise Plus стоимостью ~$5-6k, которые, по-видимому, не приносят никакой выгоды (даже если вы не видите проблем с производительностью) - я не понимаю, извините.