Virtualisatie is erg populair voor organisaties:het stelt hen in staat hardware beter te gebruiken door meerdere servers op één host te combineren, biedt HA-mogelijkheden en geeft een verlaging van verschillende kosten, zoals verwarming/koeling, SQL Server-licenties en hardware. Ik ben betrokken geweest bij tal van projecten met organisaties om hen te helpen migreren van fysieke naar virtuele omgevingen en heb hen geholpen deze voordelen te ervaren.
Wat ik in dit artikel met u wil delen, is een eigenaardig probleem dat ik tegenkwam tijdens het werken met Hyper-V op Windows Server 2012 R2 met behulp van dynamisch geheugen. Ik moet toegeven dat de meeste van mijn kennis van virtualisatie bij VMware was, maar dat verandert nu.
Bij het werken met SQL Server op VMware raad ik altijd aan om geheugenreserves in te stellen, dus toen ik deze Dynamic Memory-functie met Hyper-V tegenkwam, moest ik wat onderzoek doen. Ik heb een artikel gevonden (Hyper-V Dynamic Memory Configuration Guide) waarin veel van de voordelen en systeemvereisten voor het gebruik van Dynamic Memory worden uitgelegd. Deze functie is best cool in hoe je een virtuele machine van meer of minder geheugen kunt voorzien zonder dat deze hoeft te worden uitgeschakeld.
Spelen met Hyper-V Ik heb gemerkt dat het inrichten van virtuele machines eenvoudig en gemakkelijk te leren is. Met weinig moeite kon ik een laboratoriumomgeving bouwen om de ervaring van mijn klant te simuleren. Krediet gaat naar mijn baas voor het verstrekken van geweldige hardware om mee te werken. Ik gebruik een Dell M6800 met een i7-processor, 32 GB RAM en twee SSD's van 1 TB. Dit beest is beter dan veel servers waar ik aan heb gewerkt.
Met behulp van VMware Workstation 11 op mijn laptop heb ik een Windows Server 2012 R2-gast gemaakt met 4 vCPU's, 24 GB RAM en 100 GB opslagruimte. Nadat de gast was gemaakt en gepatcht, heb ik de Hyper-V-rol toegevoegd en een gast ingericht onder Hyper-V. De nieuwe guest is gebouwd met Windows Server 2012 R2 met 2 vCPU's, 22GB RAM en 60GB opslag met SQL Server 2014 RTM.
Ik heb drie sets tests uitgevoerd, elk met dynamisch geheugen. Voor elke test gebruikte ik Red Gate's SQL Data Generator tegen de AdventureWorks2014-database om de bufferpool te vullen. Voor de eerste test begon ik met 512 MB voor de opstart-RAM-waarde, aangezien dat de minimale hoeveelheid geheugen is om Windows Server 2012 R2 te starten en de bufferpool stopte met toenemen rond de 8 GB.
Voor elke test zou ik mijn testtabel afkappen, de guest afsluiten, de geheugeninstellingen wijzigen en de guest opnieuw opstarten. Voor de tweede test heb ik het opstart-RAM verhoogd tot 768 MB en de bufferpool is slechts toegenomen tot iets meer dan 12 GB.
Voor de derde en laatste test verhoogde het opstart-RAM naar 1024 MB, liet de datagenerator draaien en kon de bufferpool toenemen tot iets minder dan 16 GB.
Een beetje rekenen met deze waarden laat zien dat de bufferpool niet meer dan 16 keer het opstart-RAM kan groeien. Dit kan zeer problematisch zijn voor SQL Server als het opstart-RAM minder is dan 1/16 van het maximale geheugen. Laten we eens denken aan een Hyper-V-gast met 64 GB RAM met SQL Server en een opstart-RAM-waarde van 1 GB. We hebben geconstateerd dat de bufferpool met deze configuratie niet meer dan 16 GB zou kunnen gebruiken, maar als we de opstart-RAM-waarde instellen op 4096 MB, zou de bufferpool 16 keer kunnen toenemen, waardoor we alle 64 GB kunnen gebruiken.
De enige referenties die ik kon vinden over waarom de bufferpool beperkt is tot 16 keer de opstart-RAM-waarde, stonden op pagina's 8 en 16 in de whitepaper Best Practices for Running SQL Server with HVDM. Dit document legt uit dat, aangezien de buffercachewaarde wordt berekend bij het opstarten, het een statische waarde is en niet groeit. Als SQL Server echter detecteert dat Hot Add Memory wordt ondersteund, wordt de grootte die is gereserveerd voor de virtuele adresruimte voor de bufferpool met 16 keer het opstartgeheugen vergroot. In dit document staat ook dat dit gedrag van invloed is op SQL Server 2008 R2 en eerder, maar mijn test is uitgevoerd op Windows Server 2012 R2 met SQL Server 2014, dus ik zal contact opnemen met Microsoft om het document met best practices te laten bijwerken.
Aangezien de meeste productie-DBA's geen virtuele machines voorzien of zwaar in die ruimte werken, en virtualisatie-ingenieurs niet de nieuwste en beste SQL Server-technologie bestuderen, kan ik begrijpen hoe deze belangrijke informatie over hoe de bufferpool omgaat met dynamisch geheugen, voor velen onbekend is. van mensen.
Zelfs het volgen van de artikelen kan misleidend zijn. In het artikel Hyper-V Dynamic Memory Configuration Guide luidt de beschrijving voor opstart-RAM:
Specificeert de hoeveelheid geheugen die nodig is om de virtuele machine te starten. De waarde moet hoog genoeg zijn om het gastbesturingssysteem te laten starten, maar moet zo laag mogelijk zijn voor optimaal geheugengebruik en mogelijk hoge consolidatieverhoudingen.Optimaal geheugengebruik voor wie, de host of de gast? Als een virtualisatiebeheerder dit zou lezen, zouden ze waarschijnlijk vaststellen dat dit het minimale geheugen betekent dat is toegestaan om het besturingssysteem te starten.
Verantwoordelijk zijn voor SQL Server betekent dat we kennis moeten hebben van andere technologieën die onze omgeving kunnen beïnvloeden. Met de introductie van SAN's en virtualisatie moeten we volledig begrijpen hoe dingen in die omgevingen een negatieve invloed kunnen hebben op SQL Server en, nog belangrijker, hoe zorgen effectief kunnen worden gecommuniceerd aan de mensen die verantwoordelijk zijn voor die systemen. Een DBA hoeft niet per se te weten hoe opslag in een SAN moet worden ingericht of hoe een VMWare- of Hyper-V-omgeving moet worden ingericht of beheerd, maar ze moeten wel de basis kennen van hoe dingen werken.
Door de basis te kennen over hoe een SAN werkt met opslagarrays, opslagnetwerken, multi-pathing enzovoort, evenals hoe de hypervisor werkt met de planning van CPU's en opslagtoewijzing binnen virtualisatie, kan een DBA beter communiceren en problemen oplossen wanneer zich problemen voordoen . Door de jaren heen heb ik met succes samengewerkt met een aantal SAN- en virtualisatiebeheerders om standaarden voor SQL Server te bouwen. Deze standaarden zijn uniek voor SQL Server en zijn niet noodzakelijk van toepassing op web- of applicatieservers.
DBA's kunnen niet echt vertrouwen op SAN- en virtualisatiebeheerders om de best practices voor SQL Server volledig te begrijpen, hoe leuk dat ook zou zijn, dus we moeten onszelf zo goed mogelijk informeren over hoe hun expertisegebieden ons kunnen beïnvloeden.
Tijdens mijn tests gebruikte ik een query uit de blogpost van Paul Randal, Prestatieproblemen van verspild bufferpoolgeheugen, om te bepalen hoeveel bufferpool de AdventureWorks2014-database gebruikte. Ik heb de onderstaande code toegevoegd:
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]; Deze code is ook geweldig voor het oplossen van problemen welke van uw databases het grootste deel van uw bufferpool in beslag nemen, zodat u weet op welke database u zich moet concentreren op het afstemmen van de dure query's. Als u een Hyper-V-winkel bent, neem dan contact op met uw beheerder om te zien of Dynamic Memory zo kan worden geconfigureerd dat het een negatieve invloed heeft op uw server.