Der „Gesamtserverspeicher“ von SQL Server stagniert monatelang, und es sind mindestens 64 GB verfügbar

Ich bin auf ein seltsames Problem gestoßen, bei dem sich die 64-Bit-Version von SQL Server 2016 Standard Edition anscheinend auf genau die Hälfte des ihr zugewiesenen Gesamtspeichers beschränkt hat (64 GB von 128 GB).

Die Ausgabe von @@VERSIONist:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22. Dezember 2017 11:25:00 Urheberrecht (c) Microsoft Corporation Standard Edition (64-Bit) unter Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hypervisor)

Die Ausgabe von sys.dm_os_process_memoryist:

Wenn ich frage sys.dm_os_performance_counters, sehe ich, dass der bei Target Server Memory (KB)ist 131072000und Total Server Memory (KB)knapp die Hälfte davon bei ist 65308016. In den meisten Szenarien würde ich dies als normales Verhalten verstehen, da SQL Server noch nicht festgelegt hat, dass es weiteren Speicher für sich selbst reservieren muss.

Es ist jedoch seit über 2 Monaten bei ~ 64 GB "hängen geblieben". In diesem Zeitraum haben wir eine erhebliche Menge speicherintensiver Vorgänge für einige der Datenbanken ausgeführt und der Instanz fast 40 weitere Datenbanken hinzugefügt. Insgesamt verfügen wir über 292 Datenbanken, von denen jede vorab zugewiesene Datendateien mit 4 GB und einer automatischen Wachstumsrate von 256 MB sowie 2 GB Protokolldateien mit einer automatischen Wachstumsrate von 128 MB enthält. Ich führe einmal pro Nacht um 00:00 Uhr eine vollständige Sicherung durch und beginne die Transaktionsprotokollsicherungen von Montag bis Freitag zwischen 6:00 Uhr und 20:00 Uhr im Abstand von jeweils 15 Minuten. Diese Datenbanken weisen einen relativ geringen Gesamtdurchsatz auf, aber ich bin skeptisch, dass etwas nicht stimmt, da sich SQL Server noch nicht auf den Server eingeschlichen hatTarget Server Memory Natürlich durch neue Datenbankzusätze, normale Abfrageausführungen sowie speicherintensive ETL-Pipelines, die ausgeführt wurden.

Die SQL Server-Instanz selbst befindet sich auf einem virtualisierten Windows Server 2012R2-Server (VMware) mit 12 CPU, 144 GB Arbeitsspeicher (128 GB für SQL Server, 16 GB für Windows reserviert) und 4 virtuellen Festplatten, die sich auf einem vSAN mit 15 KB SAS-Laufwerken befinden . Windows befindet sich natürlich auf einer 64 GB C: -Diskette mit einer Auslagerungsdatei von 32 GB. Die Datendateien befinden sich auf einer 2-TB-D: -Diskette, die Protokolldateien auf einer 2-TB-L: -Diskette und tempdb auf einer 256-GB-T: -Diskette mit 8 x 16-GB-Dateien ohne automatisches Wachstum.

Ich habe überprüft, dass auf dem Server keine anderen Instanzen von SQL Server ausgeführt werden MSSQLSERVER.

Dieser Server ist ausschließlich für die SQL Server-Instanz reserviert, sodass keine anderen Anwendungen oder Dienste ausgeführt werden, die möglicherweise Speicher belegen.

Ich verwende RedGate SQL Monitor für die Analyse, und unten ist eine Geschichte der letzten 18 Tage von Total Server Memory. Wie Sie sehen, ist die Speicherauslastung bis auf einen einzigen Anstieg von ~ 300 MB Anfang April völlig stagniert.

Was könnte die Ursache dafür sein? Worauf kann ich näher eingehen, um festzustellen, warum SQL Server die ihm zugewiesenen zusätzlichen 64 GB Arbeitsspeicher nicht verwenden möchte?

Die Ausgabe des Laufens sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Priorität 50: Leistung :

• CPU-Scheduler offline - Auf einige CPU-Kerne kann SQL Server aufgrund von Affinitätsmaskierungs- oder Lizenzierungsproblemen nicht zugreifen.

• Speicherknoten offline - Aufgrund von Affinitätsmaskierungs- oder Lizenzproblemen ist möglicherweise ein Teil des Speichers nicht verfügbar.

Priorität 50: Zuverlässigkeit :

• Remote-DAC deaktiviert - Der Remote-Zugriff auf die Dedicated Admin Connection (DAC) ist nicht aktiviert. Der DAC kann die Remote-Problembehandlung erheblich vereinfachen, wenn SQL Server nicht reagiert.

Priorität 100: Leistung :

• Viele Pläne für eine Abfrage - 300 Pläne sind für eine einzelne Abfrage im Plan-Cache vorhanden. Dies bedeutet, dass wahrscheinlich Parametrisierungsprobleme vorliegen.

• Server-Trigger aktiviert

  • Server-Trigger [RG_SQLLighthouse_DDLTrigger] ist aktiviert. Stellen Sie sicher, dass Sie verstehen, was dieser Auslöser tut - je weniger Arbeit er leistet, desto besser.

  • Server-Trigger [SSMSRemoteBlock] ist aktiviert. Stellen Sie sicher, dass Sie verstehen, was dieser Auslöser tut - je weniger Arbeit er leistet, desto besser.

Priorität 150: Leistung :

• Abfragen, die Verknüpfungshinweise erzwingen - Seit dem Neustart wurden 1480 Instanzen von Verknüpfungshinweisen aufgezeichnet. Dies bedeutet, dass Abfragen das SQL Server-Optimierungsprogramm beherrschen, und wenn sie nicht wissen, was sie tun, kann dies mehr schaden als nützen. Dies kann auch erklären, warum die DBA-Optimierungsbemühungen nicht funktionieren.

• Abfragen, die Bestellhinweise erzwingen - 2153 Fälle von Bestellhinweisen wurden seit dem Neustart aufgezeichnet. Dies bedeutet, dass Abfragen das SQL Server-Optimierungsprogramm beherrschen, und wenn sie nicht wissen, was sie tun, kann dies mehr schaden als nützen. Dies kann auch erklären, warum die DBA-Optimierungsbemühungen nicht funktionieren.

Priorität 170: Dateikonfiguration :

• Systemdatenbank auf Laufwerk C

  • master - Die master-Datenbank enthält eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz vorhanden ist.

  • model - Die Modelldatenbank enthält eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz vorhanden ist.

  • msdb - Die msdb-Datenbank enthält eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz vorhanden ist.

Priorität 200: Information :

• Gleichzeitiges Starten von Agentenaufträgen - Mehrere SQL Server-Agentenaufträge werden so konfiguriert, dass sie gleichzeitig gestartet werden. Detaillierte Zeitplanauflistungen finden Sie in der Abfrage in der URL.

• Tabellen in der Master-Datenbank master - Die CommandLog-Tabelle in der Master-Datenbank wurde von Endbenutzern am 30. Juli 2017 um 17:22 Uhr erstellt. Tabellen in der Masterdatenbank werden im Katastrophenfall möglicherweise nicht wiederhergestellt.

• TraceFlag Ein

  • Das Ablaufverfolgungsflag 1118 ist global aktiviert.

  • Das Ablaufverfolgungsflag 1222 ist global aktiviert.

  • Das Ablaufverfolgungsflag 2371 ist global aktiviert.

Priorität 200: Nicht standardmäßige Serverkonfiguration :

• Agent XPs - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

• backup checksum default - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

• Backup-Komprimierungsstandard - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

• Kostenschwelle für Parallelität - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 5 und er wurde auf 48 gesetzt.

• Maximaler Parallelitätsgrad - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 12 gesetzt.

• max server memory (MB) - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 2147483647 und er wurde auf 128000 eingestellt.

• Für Ad-hoc-Workloads optimieren - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

• show advanced options - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

• xp_cmdshell - Diese sp_configure-Option wurde geändert. Sein Standardwert ist 0 und er wurde auf 1 gesetzt.

Priorität 200: Zuverlässigkeit :

• Erweiterte gespeicherte Prozeduren im Master

• master - Die erweiterte gespeicherte Prozedur [sqbdata] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbdir] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbmemory] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbstatus] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbtest] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbtestcancel] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbteststatus] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqbutility] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

  • master - Die erweiterte gespeicherte Prozedur [sqlbackup] befindet sich in der master-Datenbank. Möglicherweise wird CLR verwendet, und die Masterdatenbank muss jetzt Teil Ihrer Sicherungs- / Wiederherstellungsplanung sein.

Priorität 210: Nicht standardmäßige Datenbankkonfiguration :

• Read Committed Snapshot Isolation Enabled - Diese Datenbankeinstellung ist nicht die Standardeinstellung.

  • RedGate

  • RedGateMonitor

• Snapshot-Isolation aktiviert - Diese Datenbankeinstellung ist nicht die Standardeinstellung.

  • RedGate

  • RedGateMonitor

Priorität 240: Wartestatistik :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 Stunden Wartezeit, 115,9 Minuten durchschnittliche Wartezeit pro Stunde, 100,0% Signalwartezeit, 1419212079 Warteaufgaben, 4,5 ms durchschnittliche Wartezeit.

Priorität 250: Information :

• SQL Server wird unter einem NT-Dienstkonto ausgeführt. Ich verwende NT Service \ MSSQLSERVER. Ich wünschte, ich hätte stattdessen ein Active Directory-Dienstkonto.

Priorität 250: Serverinfo :

• Standard-Trace-Inhalt - Der Standard-Trace enthält 36 Stunden Daten zwischen dem 14. April 2018, 23:21 Uhr und dem 16. April 2018, 11:13 Uhr. Die Standardablaufverfolgungsdateien befinden sich in: C: \ Programme \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Laufwerk C Space - 196816.00MB frei auf Laufwerk C

• Drive D Space - 894823.00MB frei auf E-Laufwerk

• Laufwerk L Speicherplatz - 1361367.00MB frei auf Laufwerk F

• Drive T Space - 114441.00MB frei auf G-Laufwerk

• Hardware - Logische Prozessoren: 12. Physischer Speicher: 144 GB.

• Hardware - NUMA Konfig

  • Knoten: 0 Status: ONLINE Online-Scheduler: 4 Offline-Scheduler: 2 Prozessorgruppe: 0 Speicherknoten: 0 Speicher VAS Reserviert GB: 186

  • Knoten: 1 Status: OFFLINE Online-Scheduler: 0 Offline-Scheduler: 6 Prozessorgruppe: 0 Speicherknoten: 0 Speicher VAS Reserviert GB: 186

• Instant File Initialization Enabled (Sofortige Dateiinitialisierung aktiviert) - Das Dienstkonto verfügt über die Berechtigung "Datenträgerwartungsaufgaben ausführen".

• Energiesparplan - Ihr Server verfügt über 2,60-GHz-CPUs und befindet sich im ausgeglichenen Energiesparmodus - Äh ... Sie möchten, dass Ihre CPUs mit voller Geschwindigkeit laufen, oder?

• Letzter Neustart des Servers - 9. März 2018 07:27 Uhr

• Servername - [redigiert]

• Dienstleistungen

  • Dienst: SQL Server (MSSQLSERVER) wird unter dem Dienstkonto NT Service \ MSSQLSERVER ausgeführt. Letzte Startzeit: 9. März 2018 07:27. Starttyp: Automatisch, derzeit ausgeführt.

  • Dienst: Der SQL Server-Agent (MSSQLSERVER) wird unter dem Dienstkonto LocalSystem ausgeführt. Letzte Startzeit: nicht angezeigt. Starttyp: Automatisch, wird gerade ausgeführt.

• Letzter Neustart von SQL Server - 9. März 2018, 06:27 Uhr

• SQL Server-Dienst - Version: 13.0.4466.4. Patch-Level: SP1. Kumulatives Update: CU7. Edition: Standard Edition (64-Bit). Verfügbarkeitsgruppen aktiviert: 0. Status des Verfügbarkeitsgruppen-Managers: 2

• Virtueller Server - Typ: (HYPERVISOR)

• Windows-Version - Sie verwenden eine ziemlich moderne Version von Windows: Server 2012R2, Version 6.3

Priorität 254: Rundate :

• Logbuch des Kapitäns: etwas und etwas sternenklar ...

Ich wette, Sie haben die virtuellen CPUs so konfiguriert, dass einige der CPU-Knoten und / oder Speicherknoten offline sind.

Laden Sie sp_Blitz herunter (Haftungsausschluss: Ich bin einer der Autoren dieses kostenlosen Open Source-Skripts) und führen Sie es aus:

sp_Blitz @CheckServerInfo = 1;

Suchen Sie nach Warnungen zu CPU- und / oder Speicherknoten, die offline sind. In SQL Server Standard Edition werden nur die ersten 4 CPU-Sockel angezeigt, und Sie haben die VM möglicherweise als 6 Dual-Core-CPUs konfiguriert. Am Ende wird ein Problem auftreten, das der Begrenzung des verfügbaren Arbeitsspeichers durch die 20-Kern-Beschränkungen der Enterprise Edition ähnelt .

Wenn Sie die Ausgabe von sp_Blitz hier freigeben möchten, können Sie sie folgendermaßen ausführen, um sie in Markdown auszugeben. Anschließend können Sie sie kopieren und in Ihre Frage einfügen:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Update 16.04.2018 - bestätigt. Sie haben die Ausgabe von sp_Blitz angehängt (danke dafür!) Und es zeigt in der Tat, dass Sie CPU- und Speicherknoten offline haben. Wer auch immer die VM erstellt hat, hat sie als 12 Single-Core-CPUs konfiguriert, sodass in SQL Server Standard Edition nur die ersten 4 Sockets (Kerne) und der damit verbundene Speicher angezeigt werden.

Fahren Sie die VM herunter, konfigurieren Sie sie als 2-Socket- und 6-Core-VM, und SQL Server Standard Edition erkennt alle Kerne und den gesamten Arbeitsspeicher. Dadurch wird auch die Wartezeit von SOS_SCHEDULER_YIELD verringert. Im Moment hämmert Ihr SQL Server die ersten 4 Kerne, aber das war's. Nach diesem Fix kann es auf allen 12 Kernen arbeiten.

Als Ergänzung zu Brent Ozars Aktionsplan wollte ich die Ergebnisse mitteilen. Wie Brent bemerkte, hatten wir innerhalb von VMware die virtuelle Maschine nicht ordnungsgemäß mit 12 Single-Core-CPUs konfiguriert. Dies führte dazu, dass SQL Server auf die verbleibenden 8 Kerne nicht zugreifen konnte, was zu dem in meiner ursprünglichen Frage beschriebenen Speicherproblem führte. Wir haben unsere Services gestern Abend in den Wartungsmodus versetzt, um die VM entsprechend neu zu konfigurieren. Wir sehen nicht nur, wie sich der Speicher auf normale Weise erhöht, sondern auch, wie Brent angedeutet hat, dass die Anzahl der Wartezeiten exponentiell gesunken ist und die Gesamtleistung von SQL Server in die Höhe geschossen ist. Die vNUMA-Konfigurationen sind nun glückliche kleine Komponenten, die unsere Workloads aufteilen.

Für diejenigen, die VMware vSphere 6.5 verwenden, sind die folgenden kurzen Schritte erforderlich, um das von Brent beschriebene Aktionselement auszuführen.

1. Melden Sie sich beim vSphere Web Client für Ihren VMware-Cluster an und navigieren Sie zu der virtuellen Maschine, die SQL Server hostet. Ihre VM muss offline sein, um die CPU- und Speicherkonfigurationen anzupassen.

2. Im Primärbereich zu gehen Configure > VM hardware, klicken Sie auf die EditSchaltfläche in der rechten oberen Ecke. Sie öffnen ein Kontextmenü, das hat Edit Settings. Als Referenz ist das folgende Bild die falsche Konfiguration. Beachten Sie, dass ich Cores per Socketeingestellt habe 1. Angesichts der Einschränkungen von SQL Server Standard Edition ist dies eine schlechte Konfiguration.

   

3. Die Korrektur ist so einfach wie das Anpassen des Cores per SocketWerts. In unserem Fall setzen wir es 6so, dass wir haben 2 Sockets. Dadurch kann SQL Server alle 12 Prozessoren verwenden.

   

Ein wichtiger Hinweis: Seien Sie nicht den Wert auf , wenn entweder das Number of Coresoder die Socketswürde eine ungerade Zahl sein. NUMA liebt das Gleichgewicht und muss per Faustregel durch 2 teilbar sein. Beispielsweise würde eine Konfiguration von 4 Kernen zu 3 Sockeln unausgeglichen sein. Wenn Sie sp_Blitzmit dieser Art von Konfiguration arbeiten, wird eine entsprechende Warnung ausgegeben.

In Abschnitt 3.3 in Microsoft SQL Server-Architektur für VMware vSphere (PDF-Warnung) wird dies ausführlich beschrieben. Die im Whitepaper beschriebenen Vorgehensweisen gelten für die meisten On-Premise-Virtualisierungen von SQL Server.

Hier sind ein paar weitere Ressourcen, die ich nach Brents Beitrag durch meine Recherchen zusammengestellt habe:

• Virtualisierung großer Datenbanken - VMware-CPU-Kapazitätsplanung

• Virtual Machine vCPU und vNUMA Rightsizing - Faustregeln

• Entkopplung von Kernen pro Socket von der virtuellen NUMA-Topologie in vSphere 6.5

Ich werde mit einer Aufzeichnung von RedGate SQL Monitor in den letzten 24 Stunden enden. Das wichtigste Kriterium ist die CPU-Auslastung und die Anzahl der Wartezeiten. Während unserer gestrigen Spitzenzeiten waren wir mit einer starken CPU-Auslastung und Wartezeiten konfrontiert. Nach dieser einfachen Korrektur haben wir unsere Leistung verzehnfacht. Sogar unser Festplatten-I / O hat sich deutlich reduziert. Dies ist eine scheinbar leicht übersehene Einstellung, die die virtuelle Leistung um eine Größenordnung verbessern kann. Wenigstens wurde von unseren Ingenieuren und einem kompletten übersehen d'oh Moment.

Laut MSDN ist der SQL Server-Standard auf 64 GB RAM beschränkt. Wir haben dieses Problem gelöst, indem wir die Datenbank in mehrere Instanzen aufgeteilt haben. In Ihrer Situation ist dies jedoch möglicherweise nicht möglich.

Hmm 2016 scheint 128 GB als Limit zu haben, aber der Instance-Split könnte noch eine Option sein.