MS-SQL Memory Min Max - Versionsgeschichte

David: /* Lock Pages in Memory */

2015-06-18T10:33:49Z

‎Lock Pages in Memory

David: /* SQL */

2015-06-18T10:33:19Z

‎SQL

David: /* Default */

2015-06-18T10:32:34Z

‎Default

David: /* Default */

2015-06-18T10:32:18Z

‎Default

David: /* Kontrolle */

2015-06-18T10:13:47Z

‎Kontrolle

David am 18. Juni 2015 um 09:17 Uhr

2015-06-18T09:17:55Z

David: /* Allgemein */

2015-06-18T08:54:12Z

‎Allgemein

David: Die Seite wurde neu angelegt: „= Allgemein = Achtung: Erste Version, müsste ich noch was Ausarbeiten. == Default == Die Default Einstellungen beim Microsoft SQL Server für Min und Max Me…“

2015-06-18T08:52:48Z

Die Seite wurde neu angelegt: „= Allgemein = Achtung: Erste Version, müsste ich noch was Ausarbeiten. == Default == Die Default Einstellungen beim Microsoft SQL Server für Min und Max Me…“

Neue Seite

= Allgemein =

Achtung: Erste Version, müsste ich noch was Ausarbeiten.

== Default ==
Die Default Einstellungen beim Microsoft SQL Server für Min und Max Memory betragen 0 und 2147483647 in MB. D.h. es gibt faktisch keine Grenze für die Menge an RAM, die sich der SQL Server zieht.

Das Ergebnis führt bei Systemen, die mehr RAM brauchen könnten, als der Server zur Verfügung hat, dass exzessive in die Swap Datei aus und eingelagert wird. Dadurch bricht die Performance des SQL Servers sowie des ganzen SQL Servers zusammen.

== Planung ==
Als Faustregel kann vom Verfügbaren RAM im Server einfach 20% abgezogen werden und als Max Wert konfiguriert werden. Achtung, dass muss aber nicht stimmen. Laufen weitere Prozesse auf dem System, die RAM verbrauchen, müssen diese auch in die Planung einbezogen werden. Oder aber hat der Server sehr viel RAM zur Verfügung kann 20% zu viel sein.

Der Min Wert ist bei mir leider noch etwas kontrovers. Durch einen Call bei Microsoft habe ich die Info bekommen, dass der max Wert ein vielfaches(n) des min Wertes sein soll, wobei n eine natürliche Zahl sein sollte. Warum, habe ich leider noch nicht herausbekommen, besonders da die Informationen im Web andere Empfehlungen geben.

Ich selber kommen mit einem Wert zwischen 1 und 1000 ganz gut zurecht.

== Kontrolle ==
Wichtig ist hier eine Kontrolle mittels Performance Monitor über einen längeren Zeitraum.

Eine Wiederholung der Messung sollte in definierten Abständen erfolgen, da Änderungen des Schemas oder der Datenmengen oder der Client Anwendung zu einer unterschiedlichen Auslastung führen kann.

=== Windows ===
Hier die allgemeinen Memory Counter interessant, d.h. wird das Swap File genutzt, wie viel RAM ist noch frei, wie viel RAM ist für den Filecache in Verwendung,...

=== SQL ===

Entweder ich nutze den Memory Report unter der SQL Server Instanz oder die entsprechende DMV. Eine grobere Kontrolle über den Performance Monitor ist auch möglich. Entsprechende Counter werden durch die Installation des SQL Server dort angelegt (Instanz Name).

Hier ist für einen ersten groben Überblick der PLE (Page Life Expectancy) interessant. Er beschreibt die Zeit in Sekunden, die die Pages im Cache/Buffer maximal verbleiben. Ist dieser Wert zu klein wird die IO Last des SQL Server stark steigen. Hier sollte eine separate Messung der DB IO's für die einzelnen Files erfolgen.

Desweiteren kann ich in dem Memory Report oder über die DMV's erkennen, wie der Speicher aufgeteilt ist, bzw. wie viel von dem Speicher reserviert oder commited ist.

Mögliche Probleme sind hier z.B. ein sehr großer Query Plan Cache im Vergleich zum Pagebuffer -> Analyse der Queries (DMV's)

@@ Zeile 37: / Zeile 37: @@
 == Lock Pages in Memory ==
-Läuft der SQL Server unter dem Network Service Account ist nicht weiteres nötig, mal abgesehen von dem Sicherheitsaspekt.
+Läuft der [[SQL Server]] unter dem Network Service Account ist nicht weiteres nötig, mal abgesehen von dem Sicherheitsaspekt.
-Läuft der SQL Server unter einem AD Service Account hat dieser nicht das Recht seinen Speicher vor der Auslagerung zu schützten. Das entsprechende Recht muss manuell gesetzt werden.
+Läuft der [[SQL Server]] unter einem AD Service Account hat dieser nicht das Recht seinen Speicher vor der Auslagerung zu schützten. Das entsprechende Recht muss manuell gesetzt werden.
-Dies erfolgt in der Local Security Policie, wo der entsprechende AD Account in der Policy "Lock Pages in Memory" hinzugefügt werden muss. Nach einem Neustart der SQL Server Instanz greift dieses Recht. Kontrolliert werden kann das über einen entsprechenden Eintrag im SQL Server Log.
+Dies erfolgt in der Local Security Policie, wo der entsprechende AD Account in der Policy "Lock Pages in Memory" hinzugefügt werden muss. Nach einem Neustart der [[SQL Server]] Instanz greift dieses Recht. Kontrolliert werden kann das über einen entsprechenden Eintrag im [[SQL Server]] Log.

@@ Zeile 6: / Zeile 6: @@
 Die Default Einstellungen beim Microsoft [[SQL Server]] für Min und Max Memory betragen 0 und 2147483647 in MB. D.h. es gibt faktisch keine Grenze für die Menge an RAM, die sich der [[SQL Server]] zieht.
-Das Ergebnis führt bei Systemen, die mehr RAM brauchen könnten, als der Server zur Verfügung hat, dass exzessive in die Swap Datei aus und eingelagert wird. Dadurch bricht die Performance des [[SQL Servers]] sowie des ganzen SQL Servers zusammen.
+Das Ergebnis führt bei Systemen, die mehr RAM brauchen könnten, als der Server zur Verfügung hat, dass exzessive in die Swap Datei aus und eingelagert wird. Dadurch bricht die Performance des [[SQL Server|SQL Servers]] sowie des ganzen SQL Servers zusammen.
 == Planung ==

← Nächstältere Version		Version vom 18. Juni 2015, 10:13 Uhr
Zeile 19:		Zeile 19:

	Eine Wiederholung der Messung sollte in definierten Abständen erfolgen, da Änderungen des Schemas oder der Datenmengen oder der Client Anwendung zu einer unterschiedlichen Auslastung führen kann.		Eine Wiederholung der Messung sollte in definierten Abständen erfolgen, da Änderungen des Schemas oder der Datenmengen oder der Client Anwendung zu einer unterschiedlichen Auslastung führen kann.
		+
		+	Prinzipiell sollte eine komplette [[MS-SQL Baseline\|Baseline]] über definierte Abläufe (typischer Tag, typisches Monatsende,...) erstellt werden.

	=== Windows ===		=== Windows ===

← Nächstältere Version		Version vom 18. Juni 2015, 09:17 Uhr
Zeile 32:		Zeile 32:

	Mögliche Probleme sind hier z.B. ein sehr großer Query Plan Cache im Vergleich zum Pagebuffer -> Analyse der Queries (DMV's)		Mögliche Probleme sind hier z.B. ein sehr großer Query Plan Cache im Vergleich zum Pagebuffer -> Analyse der Queries (DMV's)
		+
		+	== Lock Pages in Memory ==
		+
		+	Läuft der SQL Server unter dem Network Service Account ist nicht weiteres nötig, mal abgesehen von dem Sicherheitsaspekt.
		+
		+	Läuft der SQL Server unter einem AD Service Account hat dieser nicht das Recht seinen Speicher vor der Auslagerung zu schützten. Das entsprechende Recht muss manuell gesetzt werden.
		+
		+	Dies erfolgt in der Local Security Policie, wo der entsprechende AD Account in der Policy "Lock Pages in Memory" hinzugefügt werden muss. Nach einem Neustart der SQL Server Instanz greift dieses Recht. Kontrolliert werden kann das über einen entsprechenden Eintrag im SQL Server Log.

@@ Zeile 27: / Zeile 27: @@
 === SQL ===
-Entweder ich nutze den Memory Report unter der SQL Server Instanz oder die entsprechende DMV. Eine grobere Kontrolle über den Performance Monitor ist auch möglich. Entsprechende Counter werden durch die Installation des SQL Server dort angelegt (Instanz Name).
+Entweder ich nutze den Memory Report unter der [[SQL Server]] Instanz oder die entsprechende DMV. Eine grobere Kontrolle über den Performance Monitor ist auch möglich. Entsprechende Counter werden durch die Installation des SQL Server dort angelegt (Instanz Name).
-Hier ist für einen ersten groben Überblick der PLE (Page Life Expectancy) interessant. Er beschreibt die Zeit in Sekunden, die die Pages im Cache/Buffer maximal verbleiben. Ist dieser Wert zu klein wird die IO Last des SQL Server stark steigen. Hier sollte eine separate Messung der DB IO's für die einzelnen Files erfolgen.
+Hier ist für einen ersten groben Überblick der PLE (Page Life Expectancy) interessant. Er beschreibt die Zeit in Sekunden, die die Pages im Cache/Buffer maximal verbleiben. Ist dieser Wert zu klein wird die IO Last des [[SQL Server]] stark steigen. Hier sollte eine separate Messung der DB IO's für die einzelnen Files erfolgen.
 Desweiteren kann ich in dem Memory Report oder über die DMV's erkennen,  wie der Speicher aufgeteilt ist, bzw. wie viel von dem Speicher reserviert oder commited ist.

@@ Zeile 4: / Zeile 4: @@
 == Default ==
-Die Default Einstellungen beim Microsoft SQL Server für Min und Max Memory betragen 0 und 2147483647 in MB. D.h. es gibt faktisch keine Grenze für die Menge an RAM, die sich der SQL Server zieht.
+Die Default Einstellungen beim Microsoft [[SQL Server]] für Min und Max Memory betragen 0 und 2147483647 in MB. D.h. es gibt faktisch keine Grenze für die Menge an RAM, die sich der [[SQL Server]] zieht.
-Das Ergebnis führt bei Systemen, die mehr RAM brauchen könnten, als der Server zur Verfügung hat, dass exzessive in die Swap Datei aus und eingelagert wird. Dadurch bricht die Performance des SQL Servers sowie des ganzen SQL Servers zusammen.
+Das Ergebnis führt bei Systemen, die mehr RAM brauchen könnten, als der Server zur Verfügung hat, dass exzessive in die Swap Datei aus und eingelagert wird. Dadurch bricht die Performance des [[SQL Servers]] sowie des ganzen SQL Servers zusammen.
 == Planung ==

@@ Zeile 1: / Zeile 1: @@
 = Allgemein =
-Achtung: Erste Version, müsste ich noch was Ausarbeiten.
+Achtung: Erste Version, müsste ich noch besser Ausarbeiten.
 == Default ==