MS-SQL Memory Min Max

Aus Software Entwicklung Projekte
Wechseln zu: Navigation, Suche

Allgemein

Achtung: Erste Version, müsste ich noch besser 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.

Prinzipiell sollte eine komplette Baseline über definierte Abläufe (typischer Tag, typisches Monatsende,...) erstellt werden.

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)

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.