Angemessene Größe der Windows-Betriebssystem-Auslagerungsdatei für SQL Server

Question

Kennt jemand eine gute Faustregel für die geeignete Auslagerungsdateigröße für einen Windows 2003-Server, auf dem SQL Server ausgeführt wird?

Answer 1

Unabhängig von der Größe des RAM benötigen Sie immer noch eine Auslagerungsdatei, die mindestens dem 1,5-fachen des physischen RAM entspricht.Dies gilt selbst dann, wenn Sie über einen 1-TB-RAM-Computer verfügen und 1,5 TB Auslagerungsdatei auf der Festplatte benötigen (klingt verrückt, ist aber wahr).

Wenn ein Prozess über VirtualAlloc/VirtualAllocEx MEM_COMMIT-Speicher anfordert, muss die angeforderte Größe in der Auslagerungsdatei reserviert werden.Dies galt bereits für das erste Win NT-System und gilt auch heute noch Verwalten des virtuellen Speichers in Win32:

Wenn das Gedächtnis festgelegt ist, werden physische Speicherseiten zugewiesen und Platz ist in einer Seite Datei reserviert.

Abgesehen von einigen extremen Sonderfällen fragt SQL Server immer nach MEM_COMMIT-Seiten.Und angesichts der Tatsache, dass SQL a verwendet Dynamische Speicherverwaltung Richtlinie, die im Voraus so viel Pufferpool wie möglich reserviert (Reservierungen und begeht in Bezug auf VAS) fordert SQL Server beim Start eine große Speicherplatzreservierung in der Auslagerungsdatei an.Wenn die Auslagerungsdatei nicht die richtige Größe hat, werden die Fehler 801/802 in der ERRORLOG-Datei und den Vorgängen von SQL angezeigt.

Dies führt immer zu Verwirrung, da Administratoren fälschlicherweise davon ausgehen, dass ein großer Arbeitsspeicher die Notwendigkeit einer Auslagerungsdatei überflüssig macht.In Wahrheit ist das Gegenteil der Fall: Ein großer Arbeitsspeicher erhöht den Bedarf an Auslagerungsdateien, allein aufgrund der internen Abläufe des Windows NT-Speichermanagers.Die reservierte Auslagerungsdatei wird hoffentlich nie verwendet.

Answer 2

Bei allem Respekt vor Remus (den ich sehr respektiere), bin ich entschieden anderer Meinung.Wenn Ihre Auslagerungsdatei groß genug ist, um einen vollständigen Dump zu unterstützen, wird jedes Mal ein vollständiger Dump durchgeführt.Wenn Sie über sehr viel RAM verfügen, kann dies dazu führen, dass ein kleiner Fehler zu einem größeren Ausfall wird.

Sie möchten NICHT, dass Ihr Server 1 TB RAM auf die Festplatte schreiben muss, wenn ein einmaliges vorübergehendes Problem auftritt.Wenn ein wiederkehrendes Problem auftritt, können Sie die Auslagerungsdatei vergrößern, um einen vollständigen Dump zu erfassen.Ich würde damit warten, bis Sie von PSS (oder einer anderen Person, die für die Analyse eines vollständigen Dumps qualifiziert ist) aufgefordert werden, einen vollständigen Dump zu erfassen.Ein äußerst kleiner Prozentsatz der DBAs weiß, wie man einen vollständigen Dump analysiert.Für die Behebung der meisten ohnehin auftretenden Probleme reicht ein Mini-Dump aus.

Und wenn Ihr Server so konfiguriert ist, dass er einen vollständigen Dump von 1 TB zulässt, und ein wiederkehrendes Problem auftritt, wie viel freien Speicherplatz würden Sie empfehlen?Sie könnten an einem einzigen Wochenende ein ganzes SAN füllen.

Eine Auslagerungsdatei mit 1,5*RAM war damals die Norm, als man das Glück hatte, einen SQL Server mit 3 oder 4 GB RAM zu haben.Dies ist nicht mehr der Fall.Ich belasse die Auslagerungsdatei auf allen Produktionsservern in der Windows-Standardgröße und -Einstellungen (mit Ausnahme eines SSAS-Servers, der unter Speicherdruck steht).

Und nur zur Verdeutlichung: Ich habe mit Servern mit 2 GB RAM bis 2 TB RAM gearbeitet.Nach mehr als 11 Jahren musste ich nur einmal die Auslagerungsdatei vergrößern, um einen vollständigen Dump zu erfassen.

Answer 3

Laut Microsoft "nimmt die Notwendigkeit einer Seitendatei ab, wenn die Menge an RAM in einem Computer zunimmt." In dem Artikel wird dann beschrieben, wie Sie Leistungsprotokolle verwenden, um festzustellen Genau genommen verwendet werden.Versuchen Sie zunächst, Ihre Auslagerungsdatei auf das 1,5-fache des Systemspeichers einzustellen, führen Sie dann die empfohlene Überwachung durch und nehmen Sie von dort aus Anpassungen vor.

So ermitteln Sie die geeignete Auslagerungsdateigröße für 64-Bit-Versionen von Windows

Answer 4

Je größer, desto besser, abhängig von der Größe des Arbeitssatzes der Anwendung, bei der die Erträge sinken.Sie können versuchen, dies herauszufinden, indem Sie die Größe langsam vergrößern oder verkleinern, bis Sie eine deutliche Änderung der Cache-Trefferraten feststellen.Wenn die Cache-Trefferquote jedoch über 90 % oder so liegt, sind Sie wahrscheinlich in Ordnung.Im Allgemeinen sollten Sie dies auf einem Produktionssystem im Auge behalten, um sicherzustellen, dass die RAM-Zuteilung nicht überschritten wird.

Answer 5

Wir hatten kürzlich einige Leistungsprobleme mit einem unserer SQL Server, die wir nicht vollständig eingrenzen konnten, und haben tatsächlich eines unserer Microsoft-Supporttickets genutzt, um bei der Fehlerbehebung zu helfen.Es wurde die optimale Auslagerungsdateigröße für die Verwendung mit SQL Server ermittelt, und Microsoft empfiehlt dies 1 1/2 Mal so viel RAM.

Answer 6

Wenn Sie eine hohe Leistung anstreben, sollten Sie das Paging vollständig vermeiden, sodass die Größe der Auslagerungsdatei weniger wichtig wird.Investieren Sie in so viel RAM wie möglich für den DB-Server.

Answer 7

Nach langer Recherche haben unsere dedizierten SQL-Server, auf denen Enterprise x64 unter Windows 2003 Enterprise x64 ausgeführt wird, keine Auslagerungsdatei.

Die Auslagerungsdatei ist einfach ein Cache für Dateien, der vom Betriebssystem verwaltet wird, und SQL verfügt über ein eigenes internes Speicherverwaltungssystem.

Der MS-Artikel, auf den verwiesen wird, qualifiziert nicht, dass sich der Rat auf das Betriebssystem bezieht, auf dem sofort einsatzbereite Dienste wie die Dateifreigabe ausgeführt werden.

Eine Auslagerungsdatei belastet einfach die Festplatten-E/A, weil Windows versucht, zu helfen, obwohl nur das SQL-Betriebssystem die Aufgabe erledigen kann.

Answer 8

In diesem Fall ist die normale Empfehlung des 1,5-fachen gesamten physischen RAM nicht die beste.Diese sehr allgemeine Empfehlung wird unter der Annahme gegeben, dass der gesamte Speicher von „normalen“ Prozessen genutzt wird, deren am wenigsten genutzte Seiten im Allgemeinen auf die Festplatte verschoben werden können, ohne dass es zu massiven Leistungsproblemen für den Anwendungsprozess kommt, zu dem der Speicher gehört.

Bei Servern, auf denen SQL Server ausgeführt wird (im Allgemeinen mit sehr großen RAM-Mengen), ist der Großteil des physischen RAM für den SQL Server-Prozess reserviert und sollte (bei korrekter Konfiguration) im physischen Speicher gesperrt sein, um zu verhindern, dass er in die Auslagerungsdatei ausgelagert wird .SQL Server verwaltet seinen eigenen Speicher sehr sorgfältig unter Berücksichtigung der Leistung und nutzt einen großen Teil des seinem Prozess zugewiesenen RAM als Datencache, um die Festplatten-E/A zu reduzieren.Es macht keinen Sinn, diese Daten-Cache-Seiten in die Auslagerungsdatei auszulagern, da der einzige Zweck, diese Daten überhaupt im RAM zu haben, darin besteht, die Festplatten-E/A zu reduzieren.(Beachten Sie, dass das Windows-Betriebssystem auch den verfügbaren RAM ähnlich wie den Festplatten-Cache nutzt, um den Systembetrieb zu beschleunigen.) Da SQL Server bereits seinen eigenen Speicherplatz verwaltet, sollte dieser Speicherplatz nicht als „auslagerbar“ betrachtet und nicht in eine Berechnung für die Auslagerungsdatei einbezogen werden Größe.

In Bezug auf MEM_COMMIT, das von Remus erwähnt wird, ist die Terminologie verwirrend, da sich „reserviert“ im Sprachgebrauch des virtuellen Speichers nie auf die tatsächliche Zuweisung bezieht, sondern darauf, die Nutzung eines Adressraums (nicht des physischen Raums) durch einen anderen Prozess zu verhindern.Der zum „Festschreiben“ verfügbare Speicher entspricht im Grunde der Summe aus physischem RAM und Auslagerungsdateigröße, und die Ausführung eines MEM_COMMIT verringert lediglich die im festgeschriebenen Pool verfügbare Menge.Es tut nicht Ordnen Sie zu diesem Zeitpunkt eine passende Seite in der Auslagerungsdatei zu.Wenn tatsächlich auf eine festgeschriebene Speicherseite geschrieben wird, weist das virtuelle Speichersystem eine physische Speicherseite zu und verschiebt möglicherweise eine weitere Speicherseite vom physischen RAM in die Auslagerungsdatei.Siehe MSDNs VirtualAlloc-Funktion Referenz.

Das Windows-Betriebssystem verfolgt die Speicherauslastung zwischen Anwendungsprozessen und seinem eigenen Festplatten-Cache-Mechanismus und entscheidet, wann nicht gesperrte Speicherseiten vom physischen in die Auslagerungsdatei übertragen werden sollen.Ich verstehe, dass eine Auslagerungsdatei, die im Vergleich zum tatsächlichen nicht gesperrten Speicherplatz viel zu groß ist, dazu führen kann, dass Windows den Anwendungsspeicher übermäßig in die Auslagerungsdatei auslagert, was dazu führt, dass diese Anwendungen unter den Folgen von Seitenfehlern leiden (langsame Leistung).

Solange auf dem Server keine anderen speicherhungrigen Prozesse ausgeführt werden, sollte eine Auslagerungsdateigröße von 4 GB ausreichend sein.Wenn Sie SQL Server so eingestellt haben, dass das Sperren von Seiten im Speicher zulässig ist, sollten Sie auch die Einstellung für den maximalen Speicher von SQL Server so festlegen, dass dem Betriebssystem etwas physischer RAM für sich selbst und andere Prozesse zur Verfügung steht.

802-Fehler in SQL Server weisen darauf hin, dass das System keine weiteren Seiten für den Datencache festschreiben kann.Das Erhöhen der Auslagerungsdateigröße hilft in dieser Situation nur insofern, als Windows in der Lage ist, Speicher von Nicht-SQL Server-Prozessen auszulagern.Wenn Sie in dieser Situation zulassen, dass der SQL Server-Speicher in die Auslagerungsdatei hineinwächst, werden möglicherweise die Fehlermeldungen entfernt, es ist jedoch kontraproduktiv, da wir bereits zuvor über den Grund für den Datencache gesprochen haben.