Když řeším problémy s výkonem CPU na virtualizovaných SQL serverech běžících na VMware, jednou z prvních věcí, které dělám, je ověřit, že konfigurace virtuálního stroje není faktorem přispívajícím k problému s výkonem. Tam, kde má fyzický server 100 % dostupných zdrojů vyhrazených pro operační systém, virtuální počítač nikoli, takže pohled na několik základních položek dopředu eliminuje řešení nesprávného problému a plýtvání časem. V minulosti jsem blogoval o tom, jak je důležité, aby správci databází měli přístup pouze pro čtení do Virtual Center for VMware pro základní řešení problémů s výkonem. I bez přístupu do Virtual Center je však stále možné zjistit některé základní informace ve Windows, které by mohly vést k potenciálním problémům na úrovni hostitele, které ovlivňují výkon.
Každý virtuální stroj VMware má ve Windows dvě skupiny čítačů výkonu, které jsou přidány, když jsou nástroje VMware nainstalovány v hostovi; Procesor VM a paměť VM. Tyto čítače výkonu jsou jednou z prvních věcí, na které se podívám, kdykoli pracuji s virtuálním počítačem na VMware, protože vám dávají pohled na to, jaké prostředky VM dostává od hypervizoru. Skupina procesorů VM má následující čítače:
- % času procesoru
- Efektivní rychlost VM v MHz
- Rychlost hostitelského procesoru v MHz
- Limit v MHz
- Rezervace v MHz
- Sdílí
U hosta virtuálního počítače, který ve Správci úloh nebo perfmon vykazuje vysokou hodnotu procesoru\% času procesoru, poskytne kontrola čítačů procesoru virtuálního počítače přesný účet skutečných alokací prostředků, které host virtuálního počítače přijímá. Pokud je rychlost hostitelského procesoru v MHz 3 000 a host má přiděleno 8 virtuálních CPU, pak maximální efektivní rychlost pro VM je 24 000 MHz a počítadlo efektivní rychlosti VM v MHz bude odrážet, zda VM skutečně získává zdroje z hostitel. Obvykle v tomto případě budete muset začít hledat informace na úrovni hostitele, abyste mohli dále diagnostikovat hlavní příčinu problému. Ale při nedávném zapojení klienta se to neukázalo.
Klientský virtuální počítač v tomto případě odpovídal konfiguraci popsané výše a měl maximální efektivní rychlost 24 000 MHz, ale počítadlo efektivní rychlosti virtuálního počítače v MHz dosahovalo pouze průměrné hodnoty kolem 6 900 MHz s dobou VM Windows Percent Processor fixovanou na téměř 100 %. Pohled těsně pod počítadlo efektivní rychlosti virtuálního počítače v MHz odhalil příčinu problému:limit v MHz byl 7 000, což znamená, že virtuální počítač měl nakonfigurovaný limit využití CPU na 7 000 MHz v ESX, takže byl neustále omezován hypervizorem pod zatížení.
Vysvětlením pro to bylo, že tento konkrétní virtuální počítač byl použit pro účely testování v rámci proof of concept a byl původně umístěn na zaneprázdněném hostiteli virtuálního počítače; Správci virtuálních počítačů nechtěli, aby neznámá zátěž způsobovala problémy s výkonem na tomto hostiteli. Aby se zajistilo, že to nebude mít negativní dopad na skutečnou produkční zátěž hostitele během POC, bylo omezeno na povolení pouze 7000 MHz CPU nebo ekvivalent 2 1/3 fyzických jader na hostiteli. V konečném důsledku odstranění limitu CPU VM v ESX eliminovalo velké problémy s CPU ve Windows a problémy s výkonem, se kterými se klient potýkal, zmizely.
Skupina čítačů paměti virtuálního počítače je stejně důležitá jako skupina procesorů virtuálního počítače pro identifikaci potenciálních problémů s výkonem pro SQL Server. Skupina čítačů paměti virtuálního počítače obsahuje následující čítače:
- Aktivní paměť v MB
- Velikost paměti v MB
- Limit paměti v MB
- Paměť mapována v MB
- Režie paměti v MB
- Rezervace paměti v MB
- Paměť sdílená v MB
- Sdílená paměť Uloženo v MB
- Sdílení paměti
- Vyměněna paměť v MB
- Využitá paměť v MB
Z těchto čítačů se konkrétně dívám na Memory Ballooned v MB a Memory Swapped v MB, přičemž oba by měly být nulové pro zátěže SQL Serveru. Čítač Memory Ballooned in MB říká, kolik paměti bylo uvolněno z hostujícího virtuálního počítače ovladačem bubliny kvůli přetížení paměti na hostiteli, což způsobí, že SQL Server sníží využití paměti, aby reagoval na tlak paměti ve Windows způsobený ovladačem bubliny. nafouknutí k odebrání paměti z VM. Počítadlo Memory Swapped in MB sleduje, kolik paměti bylo stránkováno na disk hostitelským hypervizorem kvůli přetížení paměti na hostiteli, které nebylo možné vyřešit přidáním hostů virtuálního počítače do bubliny s ovladačem bubliny. Průvodce osvědčenými postupy od VMware pro SQL Server doporučuje používat rezervace, aby bylo zaručeno, že SQL Server nebude z důvodu výkonu zvětšen nebo odvolán, ale mnoho správců virtuálních počítačů váhá s nastavením statických rezervací, protože to snižuje flexibilitu prostředí.
Pomoci mohou také monitorovací nástroje, jako je SentryOne V Sentry. Zvažte případ, kdy možná nemáte přímý přístup k vCenter, ale někdo může vaším jménem nastavit sledování. Nyní můžete získat skvělou vizualizaci a vhled do problémů CPU, paměti a dokonce i disku – na úrovni hosta i hostitele – a také veškeré historie, která s tím přichází. Na hlavním panelu níže vidíte metriky hostitele vlevo (včetně rozdělení CPU pro co-stop a dobu připravenosti) a metriky hosta vpravo:
Chcete-li vyzkoušet tuto a další funkce od SentryOne, můžete si stáhnout bezplatnou zkušební verzi.
Závěr
Při odstraňování problémů s výkonem na virtualizovaných serverech SQL ve VMware je důležité podívat se na problém z holistického hlediska, místo toho, abyste dělali „kolenní“ odstraňování problémů s použitím pouze omezených informací. Čítače specifické pro VMware v nástroji Performance Monitor mohou být skvělým způsobem, jak rychle ověřit, že virtuální počítač získává základní alokace zdrojů od hostitele, než podniknete další kroky k řešení problému.