Riziko při používání dynamické paměti v rámci Hyper-V

Virtualizace je pro organizace velmi oblíbená:umožňuje jim lépe využívat hardware spojením více serverů do jednoho hostitele, poskytuje funkce HA a přináší snížení různých nákladů, jako je vytápění/chlazení, licence SQL Server a hardware. Podílel jsem se na mnoha projektech s organizacemi, které jim pomohly migrovat z fyzického do virtuálního prostředí, a pomohl jsem jim zažít tyto výhody.

V tomto článku se s vámi chci podělit o zvláštní problém, na který jsem narazil při práci s Hyper-V v systému Windows Server 2012 R2 pomocí dynamické paměti. Musím přiznat, že většina mých znalostí virtualizace byla s VMware, ale to se nyní mění.

Při práci s SQL Serverem na VMware vždy doporučuji nastavit rezervace paměti, takže když jsem se setkal s touto funkcí dynamické paměti u Hyper-V, musel jsem udělat nějaký průzkum. Našel jsem článek (Hyper-V Dynamic Memory Configuration Guide), který vysvětluje mnoho výhod a systémových požadavků pro používání dynamické paměti. Tato funkce je docela skvělá v tom, jak můžete virtuálnímu stroji poskytnout více či méně paměti, aniž byste jej museli vypnout.

Při hraní s Hyper-V jsem zjistil, že poskytování virtuálních strojů je jednoduché a snadno se učí. S malým úsilím jsem byl schopen vybudovat laboratorní prostředí, které simulovalo zkušenosti, které měl můj zákazník. Poděkování patří mému šéfovi za to, že mi poskytl úžasný hardware, se kterým mohu pracovat. Používám Dell M6800 s procesorem i7, 32GB RAM a dvěma 1TB SSD. Tato bestie je lepší než spousta serverů, na kterých jsem pracoval.

Pomocí VMware Workstation 11 na svém notebooku jsem vytvořil hosta Windows Server 2012 R2 se 4 vCPU, 24 GB RAM a 100 GB úložiště. Jakmile byl host vytvořen a opraven, přidal jsem roli Hyper-V a zřídil jsem hosta pod Hyper-V. Nový host byl vytvořen se systémem Windows Server 2012 R2 se 2 vCPU, 22 GB RAM a 60 GB úložiště se systémem SQL Server 2014 RTM.

Provedl jsem tři sady testů, každý s použitím dynamické paměti. Pro každý test jsem použil Red Gate's SQL Data Generator proti databázi AdventureWorks2014, abych naplnil zásobník vyrovnávací paměti. U prvního testu jsem začal s 512 MB pro hodnotu Startup RAM, protože to je minimální množství paměti pro spuštění systému Windows Server 2012 R2 a fond vyrovnávacích pamětí se přestal zvyšovat na přibližně 8 GB.

Pro každý test bych zkrátil svou testovací tabulku, vypnul hosta, upravil nastavení paměti a spustil hosta zálohovat. Při druhém testu jsem zvýšil Startup RAM na 768 MB a velikost vyrovnávací paměti se zvětšila jen na něco málo přes 12 GB.

Při třetím a posledním testu se zvýšila spouštěcí RAM na 1024 MB, spustil se generátor dat a fond vyrovnávací paměti se mohl zvětšit na necelých 16 GB.

Trocha počítání s těmito hodnotami ukazuje, že fond vyrovnávacích pamětí nemůže narůst více než 16krát oproti spouštěcí paměti RAM. To může být pro SQL Server velmi problematické, pokud je spouštěcí RAM menší než 1/16 velikosti maximální paměti. Představme si hosta Hyper-V s 64 GB RAM se systémem SQL Server s hodnotou Startup RAM 1 GB. Zjistili jsme, že s touto konfigurací by fond vyrovnávacích pamětí nemohl využít více než 16 GB, ale pokud nastavíme hodnotu Startup RAM na 4096 MB, pak by se fond vyrovnávacích pamětí mohl zvětšit 16krát, což nám umožní využít všech 64 GB.

Jediné odkazy, které jsem našel o tom, proč je fond vyrovnávacích pamětí omezen na 16násobek hodnoty spouštěcí RAM, byly na stránkách 8 a 16 v dokumentu, Best Practices for Running SQL Server with HVDM. Tento dokument vysvětluje, že jelikož se hodnota mezipaměti vypočítává při spuštění, je to statická hodnota a neroste. Pokud však SQL Server zjistí, že je podporována paměť Hot Add Memory, zvětší velikost vyhrazenou pro virtuální adresní prostor pro fond vyrovnávacích pamětí 16krát oproti spouštěcí paměti. Tento dokument také uvádí, že toto chování ovlivňuje SQL Server 2008 R2 a starší, nicméně můj test byl proveden na Windows Server 2012 R2 s SQL Server 2014, takže budu kontaktovat společnost Microsoft, abych aktualizoval dokument o doporučených postupech.

Protože většina produkčních správců databází neposkytuje virtuální stroje nebo v tomto prostoru intenzivně nepracuje a virtualizační inženýři nestudují nejnovější a nejlepší technologii SQL Server, chápu, že tyto důležité informace o tom, jak fond vyrovnávacích pamětí zachází s dynamickou pamětí, je mnoha neznámým. lidí.

I sledování článků může být zavádějící. V článku Průvodce konfigurací dynamické paměti Hyper-V popis spouštěcí paměti RAM zní:

Pro koho, pro hostitele nebo hosta, optimální využití paměti? Pokud by toto četl správce virtualizace, pravděpodobně by zjistil, že to znamená minimální povolenou paměť pro spuštění operačního systému.

Zodpovědnost za SQL Server znamená, že potřebujeme vědět o dalších technologiích, které mohou ovlivnit naše prostředí. Se zavedením sítí SAN a virtualizace musíme plně porozumět tomu, jak mohou věci v těchto prostředích negativně ovlivnit SQL Server, a co je důležitější, jak efektivně komunikovat problémy s lidmi odpovědnými za tyto systémy. DBA nutně nemusí vědět, jak zřídit úložiště v SAN nebo jak zřídit či umět spravovat prostředí VMWare nebo Hyper-V, ale měl by znát základy toho, jak věci fungují.

Díky znalosti základů o tom, jak SAN funguje s úložnými poli, úložnými sítěmi, multi-pathing a tak dále, a také o tom, jak hypervizor pracuje s plánováním CPU a alokací úložiště v rámci virtualizace, může DBA lépe komunikovat a odstraňovat problémy, když nastanou problémy. . V průběhu let jsem úspěšně spolupracoval s řadou správců SAN a virtualizace na vytváření standardů pro SQL Server. Tyto standardy jsou jedinečné pro SQL Server a nemusí se nutně vztahovat na webové nebo aplikační servery.

DBA se opravdu nemohou spolehnout na správce SAN a virtualizace, aby plně porozuměli osvědčeným postupům pro SQL Server, bez ohledu na to, jak hezké by to bylo, takže se musíme co nejlépe vzdělávat o tom, jak nás jejich oblasti odborných znalostí mohou ovlivnit.

Během testování jsem použil dotaz z blogového příspěvku Paula Randala, Problémy s výkonem z plýtvání pamětí fondu vyrovnávacích pamětí, abych určil, kolik fondu vyrovnávacích pamětí databáze AdventureWorks2014 používala. Zahrnul jsem kód níže:

SELECT
    (CASE WHEN ([database_id] = 32767)
        THEN N'Resource Database'
        ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
    COUNT (*) * 8 / 1024 AS [MBUsed],
    SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id];

Tento kód je také skvělý pro odstraňování problémů, která z vašich databází spotřebovává většinu vašeho fondu vyrovnávacích pamětí, takže můžete vědět, na kterou databázi byste se měli zaměřit na ladění vysoce nákladných dotazů. Pokud provozujete Hyper-V obchod, zeptejte se svého administrátora, zda nelze dynamickou paměť nakonfigurovat tak, aby měla negativní dopad na váš server.