SQL Server 2012 x64 - kann nicht sicher mehr als 50% RAM zuweisen

Wir führen SQL Server 2012 SP1 CU4 auf einem 64-Bit-Server mit 12 Kernen und 2 Sockets unter Verwendung eines NUMA-Architektur-Servers aus. Betriebssystem ist Windows Server 2008 R2 x64.

Immer wenn wir mehr als 50% des physischen Arbeitsspeichers dem SQL Server zuweisen, wird der Computer instabil oder reagiert nicht mehr.

Die Symptome sind typisch für den Speichermangel des Betriebssystems - dh der Prozess kann nicht gestartet werden, das GUI-Objekt kann nicht gerendert werden, Anwendungen verhalten sich schlecht, Remotedesktopsitzungen reagieren nicht mehr usw.

Wir haben dies auf 2 verschiedenen Computern gesehen - einer mit 192 GB RAM, der andere mit 256 GB RAM. Sobald SQL mehr als 50% der jeweiligen physischen Gesamtmenge erhält, treten die Symptome auf.

Hat jemand dieses Verhalten gesehen?

--- BEARBEITEN ---

Der SQL-Dienst wird unter einem Konto mit LPIM-Berechtigungen (Seiten im Speicher sperren) ausgeführt.

McAfee Antivirus wird dem Server leider auferlegt, obwohl es zumindest mit Ausschlüssen für alle SQL-Dateien eingerichtet ist.

Wenn die RAM-Auslastung 50% überschreiten darf, sehen wir häufig Folgendes:

Hohe Wartezeiten für RESOURCE_SEMAPHORE.
Unfähigkeit, eine Verbindung zum SQL Server herzustellen oder Abfragen auszuführen.
Bei Ausführung von Abfrage-Workloads wurden alle CPUs mit geringer Festplatten-E / A ausgelastet.

- EDIT 2 ---

Wir haben versucht, SQL (SP1 CU4) neu zu installieren, und haben überprüft, dass der RAM durch nichts anderes beschädigt wird. Im Allgemeinen sind zu jeder Zeit mindestens 100 GB der insgesamt 256 GB frei. Wenn wir LPIM deaktivieren, sehen wir das Problem "Das Betriebssystem hat einen erheblichen Teil des SQL-Speichers ausgelagert", weshalb wir es aktiviert haben.

sql-server memory

— Kennzeichen
quelle

Ja - RAM ist ausgewogen - 128 GB pro Buchse, 2 Steckdosen

— Mark

Ich habe noch ein paar andere Fragen. Was meinst du mit "zuweisen"? Ist das virtuell oder physisch? Ich frage nur, weil die 198 GB RAM eine seltsame Konfiguration sind (es sei denn, Sie haben ein Blade-Gehäuse mit 99 Steckplätzen für 2 GB-Sticks). Wie beschränken Sie SQL Server auf 50%? Haben Sie LPIM aktiviert ? Läuft noch etwas auf diesem Server? Antivirus?

— Swasheck

Zusätzlich zu den Fragen von swashesk kann es auch hilfreich sein zu wissen, um welche Marke und welches Modell es sich bei dem Server handelt. Ist das auch SQL Server 2012 Service Pack 1 CU4 oder 2012 CU4 (vor SP1)? Gerne antworte ich mit den Informationen, die ich zur Diagnose des Problems sammeln würde, aber es ist wahrscheinlich am besten, zuerst weitere Details zu erhalten, um eine Fehlleitung zu vermeiden.

— James L

Ich gehe davon aus, dass 198 GB 192 sein sollen, was für eine Dreikanal-Speicherarchitektur üblich ist (2 Sockel x 6 Speichersteckplätze / Sockel x 16 GB / Steckplatz). Haben Sie auf jeden Fall ein RAM-Testprogramm ausgeführt oder den Speicher durch Ersatzteile ausgetauscht? Klingt so, als ob es ein schlechter Speicherchip oder so sein könnte. Haben Sie diese beiden Maschinen gleichzeitig gekauft?

— Jon Seigel

Ich würde die Perfmon-Metriken auf CPU-CPU-Auslastung sowie die Instanz-Perfmon-Metriken instanzweit und pro NUMA-Knoten auf PLE, Datenbankseiten usw. überprüfen. Zwei aktuelle SQL Server-KBs

Bei einigen Workloads, insbesondere bei höherer Kernanzahl, hoher Anzahl gleichzeitiger Abfragen und vielen Datenbankfestplatten-E / A, werden jedoch die Ablaufverfolgungsflags 8015 (Deaktivieren der NUMA-Unterstützung auf SQL Server-Ebene) und 8048 (Entfernen des Botllenecks für die Speicherzuweisung pro Socket) verwendet Bieten Sie noch bessere Ergebnisse als die in SQL Server 2012 SP1 CU4 enthaltenen Fixes. (Ich habe dies auf unseren Testgeräten mit Simulationen unserer Arbeitsbelastung bestätigt - YMMV)

Das Ablaufverfolgungsflag 8015 verdient vor der Bereitstellung eine gründliche Bewertung. Die Speicheraffinität und die geringere Speicherlatenz werden für die Verwaltung eines einzelnen großen Pools geopfert. Dies führt auch zu einem Lazy Writer anstelle eines pro NUMA-Knoten, und die Idee, einen Verbindungsendpunkt innerhalb einer einzelnen SQL Server-Instanz zu jedem NUMA-Knoten zu affinisieren, verschwindet ebenfalls. Bei einigen Workloads sind die Vorteile jedoch nicht zu leugnen. Verwenden Sie 8015 nicht ohne 8048.

Ich habe noch nie messbare Kosten für das Hinzufügen des Trace-Flags 8048 gesehen oder gehört. Wenn CMEMTHREADWartezeiten und zugehörige Spinlocks durch die Zuweisung des Abfragespeichers ausgelöst werden, ist dies der einzig zuverlässige Weg, diese zu beseitigen.

— sql_sasquatch
quelle

Wir haben die Trace-Flags von sql_sasquatch implementiert, und der Server ist jetzt stabil und leistungsfähig. Vielleicht funktioniert der NUMA-Support in CU4 nicht zu 100%?

— Mark