Risiko ved brug af dynamisk hukommelse i Hyper-V

Virtualisering er meget populært for organisationer:det giver dem mulighed for bedre at udnytte hardware ved at kombinere flere servere på en enkelt vært, giver HA-funktioner og giver en reduktion i forskellige omkostninger såsom opvarmning/afkøling, SQL Server-licenser og hardware. Jeg har været involveret i adskillige projekter med organisationer for at hjælpe dem med at migrere fra fysiske til virtuelle miljøer og har hjulpet dem med at opleve disse fordele.

Det, jeg vil dele med dig i denne artikel, er et ejendommeligt problem, jeg stødte på, mens jeg arbejdede med Hyper-V på Windows Server 2012 R2 ved hjælp af Dynamic Memory. Jeg må indrømme, at det meste af min viden om virtualisering har været med VMware, men det ændrer sig nu.

Når jeg arbejder med SQL Server på VMware, anbefaler jeg altid at indstille reservationer for hukommelse, så da jeg stødte på denne Dynamic Memory-funktion med Hyper-V, var jeg nødt til at lave noget research. Jeg fandt en artikel (Hyper-V Dynamic Memory Configuration Guide), der forklarer mange af fordelene og systemkravene for at bruge Dynamic Memory. Denne funktion er ret cool i, hvordan du kan give en virtuel maskine mere eller mindre hukommelse, uden at den skal slukkes.

Når jeg leger med Hyper-V, har jeg fundet ud af, at det er ligetil og let at lære at klargøre virtuelle maskiner. Med en lille indsats var jeg i stand til at bygge et laboratoriemiljø for at simulere den oplevelse, min kunde havde. Æren går til min chef for at have givet mig fantastisk hardware at arbejde med. Jeg kører en Dell M6800 med en i7-processor, 32 GB RAM og to 1TB SSD'er. Dette udyr er bedre end mange servere, jeg har arbejdet på.

Ved at bruge VMware Workstation 11 på min bærbare computer oprettede jeg en Windows Server 2012 R2-gæst med 4 vCPU'er, 24 GB RAM og 100 GB lagerplads. Da gæsten var oprettet og lappet, tilføjede jeg Hyper-V-rollen og klargjorde en gæst under Hyper-V. Den nye gæst blev bygget med Windows Server 2012 R2 med 2 vCPU'er, 22 GB RAM og 60 GB lagerplads, der kører SQL Server 2014 RTM.

Jeg kørte tre sæt test, som hver især brugte dynamisk hukommelse. Til hver test brugte jeg Red Gates SQL Data Generator mod AdventureWorks2014-databasen til at fylde bufferpuljen op. Til den første test startede jeg med 512MB for Startup RAM-værdien, da det er den mindste mængde hukommelse til at starte Windows Server 2012 R2, og bufferpuljen stoppede med at stige ved omkring 8GB.

For hver test ville jeg afkorte min testtabel, lukke gæsten ned, ændre hukommelsesindstillingerne og starte gæsten op igen. Til den anden test øgede jeg opstarts-RAM til 768 MB, og bufferpuljen steg kun til lidt over 12 GB i størrelse.

Til den tredje og sidste test øgede Startup RAM til 1024 MB, kørte datageneratoren og bufferpuljen var i stand til at øges til lige under 16 GB.

At lave lidt matematik på disse værdier viser, at bufferpuljen ikke kan vokse mere end 16 gange opstarts-RAM. Dette kan være meget problematisk for SQL Server, hvis opstarts-RAM er mindre end 1/16 størrelsen af ​​den maksimale hukommelse. Lad os tænke på en Hyper-V-gæst med 64 GB RAM, der kører SQL Server med en start-RAM-værdi på 1 GB. Vi har observeret, at bufferpuljen ikke ville være i stand til at bruge mere end 16 GB med denne konfiguration, men hvis vi indstiller Startup RAM-værdien til 4096MB, vil bufferpuljen være i stand til at stige 16 gange, hvilket giver os mulighed for at bruge alle 64 GB.

De eneste referencer, jeg kunne finde om, hvorfor bufferpuljen er begrænset til 16 gange Startup RAM-værdien, var på side 8 og 16 i whitepaperet, Best Practices for Running SQL Server with HVDM. Dette dokument forklarer, at da buffercacheværdien beregnes ved opstartstidspunktet, er den en statisk værdi og vokser ikke. Men hvis SQL Server opdager, at Hot Add Memory er understøttet, øger den størrelsen, der er reserveret til det virtuelle adresserum til bufferpuljen med 16 gange starthukommelsen. Dette dokument angiver også, at denne adfærd påvirker SQL Server 2008 R2 og tidligere, men min test blev udført på Windows Server 2012 R2 med SQL Server 2014, så jeg vil kontakte Microsoft for at få opdateret dokumentet for bedste praksis.

Da de fleste produktions-DBA'er ikke leverer virtuelle maskiner eller arbejder tungt i det rum, og virtualiseringsingeniører ikke studerer den nyeste og bedste SQL Server-teknologi, kan jeg forstå, hvordan denne vigtige information om, hvordan bufferpuljen håndterer Dynamic Memory, er ukendt for mange af folk.

Selv at følge artiklerne kan være vildledende. I artiklen Hyper-V Dynamic Memory Configuration Guide lyder beskrivelsen af ​​Startup RAM:

Optimal hukommelsesudnyttelse for hvem, værten eller gæsten? Hvis en virtualiseringsadministrator læste dette, ville de sandsynligvis bestemme, at det betyder, at det er den mindste hukommelse, der er tilladt til at starte operativsystemet.

At være ansvarlig for SQL Server betyder, at vi skal kende til andre teknologier, der kan påvirke vores miljø. Med introduktionen af ​​SAN'er og virtualisering er vi nødt til fuldt ud at forstå, hvordan ting i disse miljøer kan påvirke SQL Server negativt, og endnu vigtigere, hvordan man effektivt kommunikerer bekymringer til de personer, der er ansvarlige for disse systemer. En DBA behøver ikke nødvendigvis at vide, hvordan man klargør lager i et SAN, eller hvordan man klargør eller kan administrere et VMWare- eller Hyper-V-miljø, men de bør kende det grundlæggende i, hvordan tingene fungerer.

Ved at kende det grundlæggende om, hvordan et SAN fungerer med storage-arrays, storage-netværk, multi-pathing og så videre, samt hvordan hypervisoren arbejder med planlægning af CPU'er og lagerallokering inden for virtualisering, kan en DBA bedre kommunikere og fejlfinde, når der opstår problemer . Gennem årene har jeg med succes arbejdet med en række SAN- og virtualiseringsadministratorer for at bygge standarder til SQL Server. Disse standarder er unikke for SQL Server og gælder ikke nødvendigvis for web- eller applikationsservere.

DBA'er kan ikke rigtig stole på, at SAN- og virtualiseringsadministratorer fuldt ud forstår bedste praksis for SQL Server, uanset hvor godt det ville være, så vi skal uddanne os selv bedst muligt om, hvordan deres ekspertiseområder kan påvirke os.

Under min test brugte jeg en forespørgsel fra Paul Randals blogindlæg, Performance issues from wasted buffer pool memory, for at bestemme, hvor meget bufferpool AdventureWorks2014-databasen brugte. Jeg har inkluderet koden nedenfor:

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];

Denne kode er også fantastisk til at fejlfinde, hvilken af ​​dine databaser der bruger størstedelen af ​​din bufferpulje, så du kan vide, hvilken database du skal fokusere på at justere de dyre forespørgsler. Hvis du er en Hyper-V-butik, skal du tjekke med din administrator for at se, om Dynamic Memory kan konfigureres på en sådan måde, at det påvirker din server negativt.