Risiko bei der Verwendung von dynamischem Speicher in Hyper-V

Virtualisierung ist bei Unternehmen sehr beliebt:Sie ermöglicht es ihnen, Hardware besser zu nutzen, indem mehrere Server auf einem einzigen Host kombiniert werden, bietet HA-Funktionen und reduziert verschiedene Kosten wie Heizung/Kühlung, SQL Server-Lizenzen und Hardware. Ich war an zahlreichen Projekten mit Organisationen beteiligt, um ihnen bei der Migration von physischen zu virtuellen Umgebungen zu helfen, und habe ihnen geholfen, diese Vorteile zu nutzen.

Was ich Ihnen in diesem Artikel mitteilen möchte, ist ein besonderes Problem, auf das ich gestoßen bin, als ich mit Hyper-V unter Windows Server 2012 R2 unter Verwendung von Dynamic Memory gearbeitet habe. Ich muss zugeben, dass ich den größten Teil meines Wissens über Virtualisierung bei VMware erworben habe, aber das ändert sich jetzt.

Wenn ich mit SQL Server auf VMware arbeite, empfehle ich immer, Reservierungen für Arbeitsspeicher festzulegen. Als ich also auf diese dynamische Arbeitsspeicherfunktion mit Hyper-V stieß, musste ich etwas recherchieren. Ich habe einen Artikel (Hyper-V Dynamic Memory Configuration Guide) gefunden, in dem viele der Vorteile und Systemanforderungen für die Verwendung von Dynamic Memory erläutert werden. Diese Funktion ist ziemlich cool, da Sie einer virtuellen Maschine mehr oder weniger Speicher zur Verfügung stellen können, ohne dass sie ausgeschaltet werden muss.

Beim Herumspielen mit Hyper-V habe ich festgestellt, dass die Bereitstellung virtueller Maschinen unkompliziert und leicht zu erlernen ist. Mit wenig Aufwand konnte ich eine Laborumgebung aufbauen, um die Erfahrung meines Kunden zu simulieren. Das Verdienst geht an meinen Chef, der mir großartige Hardware zur Verfügung gestellt hat, mit der ich arbeiten kann. Ich verwende einen Dell M6800 mit einem i7-Prozessor, 32 GB RAM und zwei 1-TB-SSDs. Dieses Biest ist besser als viele Server, an denen ich gearbeitet habe.

Mit VMware Workstation 11 auf meinem Laptop habe ich einen Windows Server 2012 R2-Gast mit 4 vCPUs, 24 GB RAM und 100 GB Speicher erstellt. Nachdem der Gast erstellt und gepatcht wurde, fügte ich die Hyper-V-Rolle hinzu und stellte einen Gast unter Hyper-V bereit. Der neue Gast wurde mit Windows Server 2012 R2 mit 2 vCPUs, 22 GB RAM und 60 GB Speicher erstellt, auf dem SQL Server 2014 RTM ausgeführt wird.

Ich habe drei Testreihen durchgeführt, die jeweils dynamischen Speicher verwendeten. Für jeden Test habe ich den SQL-Datengenerator von Red Gate gegen die AdventureWorks2014-Datenbank verwendet, um den Pufferpool zu füllen. Für den ersten Test habe ich mit 512 MB für den Start-RAM-Wert begonnen, da dies die Mindestgröße an Arbeitsspeicher zum Starten von Windows Server 2012 R2 ist und der Pufferpool bei etwa 8 GB aufgehört hat zu wachsen.

Für jeden Test würde ich meine Testtabelle abschneiden, den Gast herunterfahren, die Speichereinstellungen ändern und den Gast neu starten. Für den zweiten Test habe ich den Start-RAM auf 768 MB und den Pufferpool nur auf knapp über 12 GB erhöht.

Für den dritten und letzten Test wurde das Startup RAM auf 1024 MB erhöht, der Datengenerator lief und der Pufferpool konnte auf knapp 16 GB anwachsen.

Wenn Sie diese Werte ein wenig rechnen, zeigt sich, dass der Pufferpool nicht mehr als das 16-fache des Start-RAMs wachsen kann. Dies kann für SQL Server sehr problematisch sein, wenn der Start-RAM weniger als 1/16 der Größe des maximalen Arbeitsspeichers beträgt. Stellen wir uns einen Hyper-V-Gast mit 64 GB RAM vor, auf dem SQL Server mit einem Start-RAM-Wert von 1 GB ausgeführt wird. Wir haben festgestellt, dass der Pufferpool mit dieser Konfiguration nicht mehr als 16 GB verwenden kann, aber wenn wir den Start-RAM-Wert auf 4096 MB festlegen, kann der Pufferpool um das 16-fache erhöht werden, sodass wir alle 64 GB verwenden können.

Die einzigen Hinweise, die ich dazu finden konnte, warum der Pufferpool auf das 16-fache des Start-RAM-Werts begrenzt ist, befanden sich auf den Seiten 8 und 16 im Whitepaper Best Practices for Running SQL Server with HVDM. Dieses Dokument erklärt, dass der Puffer-Cache-Wert, da er beim Start berechnet wird, ein statischer Wert ist und nicht wächst. Wenn SQL Server jedoch erkennt, dass Hot Add Memory unterstützt wird, wird die für den virtuellen Adressraum für den Pufferpool reservierte Größe um das 16-fache des Startspeichers erhöht. In diesem Dokument wird auch angegeben, dass dieses Verhalten SQL Server 2008 R2 und frühere Versionen betrifft. Meine Tests wurden jedoch auf Windows Server 2012 R2 mit SQL Server 2014 durchgeführt, sodass ich mich an Microsoft wenden werde, um das Best Practices-Dokument zu aktualisieren.

Da die meisten Produktions-DBAs keine virtuellen Maschinen bereitstellen oder in diesem Bereich intensiv arbeiten und Virtualisierungsingenieure nicht die neueste und beste SQL Server-Technologie studieren, kann ich verstehen, dass diese wichtigen Informationen darüber, wie der Pufferpool mit dynamischem Speicher umgeht, vielen unbekannt sind von Leuten.

Selbst das Befolgen der Artikel kann irreführend sein. Im Artikel Hyper-V Dynamic Memory Configuration Guide lautet die Beschreibung für Start-RAM:

Optimale Speichernutzung für wen, den Gastgeber oder den Gast? Wenn ein Virtualisierungsadministrator dies lesen würde, würde er wahrscheinlich feststellen, dass es sich um den minimal zulässigen Arbeitsspeicher zum Starten des Betriebssystems handelt.

Für SQL Server verantwortlich zu sein bedeutet, dass wir über andere Technologien Bescheid wissen müssen, die unsere Umgebung beeinflussen können. Mit der Einführung von SANs und Virtualisierung müssen wir vollständig verstehen, wie sich Dinge in diesen Umgebungen negativ auf SQL Server auswirken können, und, was noch wichtiger ist, wie wir Bedenken effektiv an die für diese Systeme verantwortlichen Personen kommunizieren können. Ein DBA muss nicht unbedingt wissen, wie man Speicher in einem SAN bereitstellt oder wie man eine VMWare- oder Hyper-V-Umgebung bereitstellt oder verwaltet, aber er sollte die Grundlagen der Funktionsweise kennen.

Durch Kenntnisse der Grundlagen darüber, wie ein SAN mit Speicherarrays, Speichernetzwerken, Multipathing usw. funktioniert und wie der Hypervisor mit der Planung von CPUs und der Speicherzuweisung innerhalb der Virtualisierung arbeitet, kann ein DBA bei auftretenden Problemen besser kommunizieren und Fehler beheben . Im Laufe der Jahre habe ich erfolgreich mit einer Reihe von SAN- und Virtualisierungsadministratoren zusammengearbeitet, um Standards für SQL Server zu erstellen. Diese Standards gelten nur für SQL Server und gelten nicht unbedingt für Web- oder Anwendungsserver.

DBAs können sich nicht wirklich darauf verlassen, dass SAN- und Virtualisierungsadministratoren die Best Practices für SQL Server vollständig verstehen, egal wie schön das wäre, also müssen wir uns so gut wie möglich darüber informieren, wie sich ihre Fachgebiete auf uns auswirken können.

Während meiner Tests habe ich eine Abfrage aus dem Blogbeitrag von Paul Randal, Leistungsprobleme durch verschwendeten Pufferpoolspeicher, verwendet, um festzustellen, wie viel Pufferpool die AdventureWorks2014-Datenbank verwendet. Ich habe den folgenden Code eingefügt:

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

Dieser Code eignet sich auch hervorragend für die Fehlerbehebung, welche Ihrer Datenbanken den Großteil Ihres Pufferpools belegt, damit Sie wissen, welche Datenbank Sie auf die Optimierung der kostenintensiven Abfragen konzentrieren sollten. Wenn Sie ein Hyper-V-Shop sind, erkundigen Sie sich bei Ihrem Administrator, ob Dynamic Memory so konfiguriert werden könnte, dass es sich negativ auf Ihren Server auswirkt.