Когато отстранявам проблеми с производителността на процесора на виртуализирани SQL сървъри, работещи на VMware, едно от първите неща, които правя, е да проверя дали конфигурацията на виртуалната машина не е фактор, допринасящ за проблема с производителността. Когато физическият сървър има 100% от наличните ресурси, посветени на операционната система, виртуалната машина няма, така че разглеждането на няколко основни елемента отпред елиминира отстраняването на грешен проблем и загубата на време. В миналото писах в блог за важността на DBA да имат достъп само за четене до Виртуален център за VMware за основно отстраняване на проблеми с производителността. Въпреки това, дори без достъп до Виртуален център, все още е възможно да се намери основна информация в Windows, която може да доведе до потенциални проблеми на ниво хост, които влияят на производителността.
Всяка виртуална машина на VMware има две групи броячи на производителност в Windows, които се добавят, когато инструментите на VMware са инсталирани в гост; VM процесор и VM памет. Тези броячи на производителността са едно от първите неща, които гледам, когато работя с виртуална машина на VMware, защото ви дават поглед върху това какви ресурси VM получава от хипервизора. Групата VM процесор има следните броячи:
- % процесорно време
- Ефективна скорост на VM в MHz
- Скорост на хост процесора в MHz
- Ограничение в MHz
- Резервация в MHz
- Споделяния
На гост на VM, който показва високо процесорно\% процесорно време в диспечера на задачите или perfmon, проверката на броячите на VM процесора ще даде точен отчет за действителните разпределения на ресурсите, които гостът на VM получава. Ако скоростта на хост процесора в MHz е 3000 и гостът има 8 виртуални CPU, разпределени към него, тогава максималната ефективна скорост за VM е 24000 MHz и броячът на ефективната VM скорост в MHz ще отразява дали VM действително получава ресурсите от домакинът. Обикновено, когато случаят е такъв, ще трябва да започнете да разглеждате информацията на ниво хост, за да диагностицирате по-нататък основната причина за проблема. Но при скорошен ангажимент с клиенти това не се оказа така.
Клиентската VM в този случай отговаряше на конфигурацията, описана по-горе и имаше максимална ефективна скорост от 24 000 MHz, но ефективната VM скорост в MHz брояч беше средно само около 6900 MHz с процентно време на VM Windows, фиксирано на почти 100%. Поглеждането точно под брояча на ефективната VM скорост в MHz разкри причината за проблема:ограничението в MHz беше 7000, което означава, че VM имаше конфигурирано ограничение на използване на процесора на 7000MHz в ESX, така че постоянно се ограничаваше от хипервизора под натоварване.
Обяснението за това беше, че тази конкретна VM е била използвана за целите на тестване в доказателство за концепция и първоначално е била разположена съвместно на зает VM хост; администраторите на VM не искаха неизвестно работно натоварване, което да причинява проблеми с производителността на този хост. Така че, за да се гарантира, че няма да повлияе негативно на реалните производствени натоварвания на хоста по време на POC, беше ограничено да позволи само 7000 MHz CPU или еквивалента на 2 1/3 физически ядра на хоста. В крайна сметка премахването на лимита за CPU на VM в ESX елиминира високите проблеми с процесора в Windows и проблемите с производителността, които клиентът изпитваше, изчезнаха.
Групата брояч на VM памет е също толкова важна, колкото и групата VM процесор за идентифициране на потенциални проблеми с производителността за SQL Server. Групата броячи на VM памет съдържа следните броячи:
- Паметта е активна в MB
- Паметта се увеличава в MB
- Ограничение на паметта в MB
- Памет, картографирана в MB
- Разход на паметта в MB
- Резервация на памет в MB
- Споделена памет в MB
- Споделена памет, запазена в MB
- Споделяне на паметта
- Паметта е разменена в MB
- Използвана памет в MB
От тези броячи, тези, които специално разглеждам, са Memory Ballooned in MB и Memory Swapped in MB, като и двете трябва да са нула за натоварвания на SQL Server. Броячът Memory Ballooned в MB показва колко памет е била възстановена от гост VM от драйвера на балона поради прекомерно поемане на памет на хоста, което ще накара SQL Server да намали използването на паметта, за да отговори на натиска на паметта в Windows, причинен от балонния драйвер надуване, за да отнеме паметта от VM. Броячът Memory Swapped in MB проследява колко памет е изпратена на диск от хипервизора на хоста поради свръхкомплектиране на паметта на хоста, което не може да бъде разрешено чрез балониране на гостите на VM с балонния драйвер. Ръководството за най-добри практики на VMware за SQL Server препоръчва използването на резервации, за да се гарантира, че SQL Server няма да бъде раздуван или изтеглен поради причини за производителност, но много администратори на VM се колебаят да зададат статични резервации, тъй като това намалява гъвкавостта на околната среда.
Инструментите за наблюдение, като SentryOne V Sentry, също могат да помогнат. Помислете за случая, когато може да нямате директен достъп до vCenter, но някой може да настрои наблюдение срещу него от ваше име. Сега можете да получите страхотна визуализация и поглед върху проблемите с процесора, паметта и дори диска – както на ниво гост, така и на ниво хост – и цялата история, която идва с това. На таблото за управление по-долу можете да видите показателите за хост отляво (включително разбивки на процесора за време за съвместно спиране и готовност) и показатели за гости вдясно:
За да изпробвате тази и други функции от SentryOne, можете да изтеглите безплатна пробна версия.
Заключение
Когато отстранявате проблеми с производителността на виртуализирани SQL сървъри на VMware, е важно да погледнете на проблема от цялостна гледна точка, вместо да правите отстраняване на неизправности на коляно, като използвате само ограничена информация. Специфичните за VMware броячи в Performance Monitor могат да бъдат чудесен начин бързо да проверите дали VM получава основните разпределения на ресурси от хоста, преди да предприемете допълнителни стъпки за отстраняване на проблема.
