Entsprechende Windows O/S-Auslagerungsdateigröße für SQL Server

Question

Kennt jemand eine gute Faustregel für die entsprechende Auslagerungsdateigröße für einen Windows 2003-Server mit SQL Server?

Answer 1

Unabhängig von der Größe des Arbeitsspeichers benötigen Sie immer noch eine Auslagerungsdatei, die mindestens das 1,5-fache des physischen Arbeitsspeichers beträgt. Dies gilt auch, wenn Sie eine 1 TB RAM-Maschine haben, benötigen Sie 1,5 TB Auslagerungsdatei auf der Festplatte (klingt verrückt, ist aber wahr).

Wenn ein Prozess MEM_COMMIT-Speicher über VirtualAlloc/VirtualAllocEx anfragt, muss die angeforderte Größe in der Auslagerungsdatei reserviert werden. Dies war in dem ersten Windows NT-System wahr, und ist auch heute noch so sehen Managing Virtual Memory in Win32:

Wenn der Speicher ist verpflichtet, physische Speicherseiten zugeordnet sind und Raum in einer Auslagerungsdatei vorbehalten.

Bare einige extreme ungerade Fälle, SQL Server wird immer nach MEM_COMMIT Seiten fragen. Und angesichts der Tatsache, dass SQL eine Dynamic Memory Management Richtlinie verwendet, die im Voraus so viel Pufferpool reserviert wie möglich (Reserven und commits in Bezug auf VAS), fordert SQL Server beim Start eine riesige Reservierung von Speicherplatz in der Auslagerungsdatei. Wenn die Auslagerungsdatei nicht richtig dimensioniert ist, werden die Fehler 801/802 in der SQL-Datei ERRORLOG und den Operationen angezeigt.

Dies führt immer zu Verwirrung, da Administratoren irrtümlicherweise davon ausgehen, dass ein großes RAM die Notwendigkeit einer Auslagerungsdatei beseitigt. In Wahrheit passiert das Gegenteil, ein großer RAM erhöht die Notwendigkeit für Auslagerungsdatei, nur wegen der inneren Funktionsweise des Windows NT-Speicher-Manager. Die reservierte Auslagerungsdatei wird hoffentlich niemals verwendet.

Answer 2

Wenn Sie auf der Suche nach einer hohen Leistung sind, sollten Sie den Seitenwechsel vollständig vermeiden, sodass die Größe der Auslagerungsdatei an Bedeutung verliert. Investieren Sie in so viel RAM wie möglich für den DB-Server.

Answer 3

Je größer desto besser bis zur Größe des Arbeitssatzes der Anwendung, in der Sie anfangen, in abnehmende Erträge zu kommen. Sie können versuchen, dies zu finden, indem Sie die Größe langsam erhöhen oder verringern, bis Sie eine signifikante Änderung der Cache-Trefferraten feststellen. Wenn die Cache-Trefferrate jedoch über 90% liegt, sind Sie wahrscheinlich in Ordnung. Generell sollten Sie dies auf einem Produktivsystem im Auge behalten, um sicherzustellen, dass es seine RAM-Zuweisung nicht überschritten hat.

Answer 4

Wir hatten in letzter Zeit einige Leistungsprobleme mit einem unserer SQL Server, die wir nicht vollständig eingrenzen konnten, und tatsächlich nutzten wir eines unserer Microsoft-Support-Tickets, damit diese bei der Fehlersuche helfen. Die optimale Größe der Auslagerungsdatei für die Verwendung mit SQL Server wurde ermittelt. Microsoft empfiehlt, dass es die 1 1/2 fache Menge an RAM ist.

Answer 5

Laut Microsoft, "wie die Menge an RAM in einem Computer steigt, sinkt die Notwendigkeit für eine Auslagerungsdatei." Der Artikel fährt dann fort, um zu beschreiben, wie Leistungsprotokolle verwendet werden, um zu bestimmen, wie viel von der Seitendatei tatsächlich verwendet wird. Versuchen Sie zunächst, die Auslagerungsdatei auf den 1,5-fachen Systemspeicher zu setzen, führen Sie dann die empfohlene Überwachung durch und nehmen Sie von dort aus Anpassungen vor.

How to determine the appropriate page file size for 64-bit versions of Windows

Answer 6

Nach viel Forschung engagierten SQL Server mit Enterprise x64 auf Windows 2003 Enterprise x64 haben keine Auslagerungsdatei.

Einfach gesagt, die Auslagerungsdatei ist ein Cache für Dateien, die vom Betriebssystem verwaltet werden, und SQL verfügt über ein eigenes internes Speicherverwaltungssystem.

Der MS-Artikel, auf den verwiesen wird, qualifiziert den Hinweis nicht, dass das Betriebssystem Out-of-the-Box-Dienste wie File-Sharing ausführt.

Wenn Sie eine Auslagerungsdatei haben, wird die Platten-E/A nur belastet, weil Windows versucht zu helfen, wenn nur das SQL-Betriebssystem die Aufgabe erfüllen kann.

Answer 7

Bei allem Respekt für Remus (den ich sehr respektiere), stimme ich absolut nicht zu. Wenn Ihre Auslagerungsdatei groß genug ist, um einen vollständigen Speicherauszug zu unterstützen, führt sie jedes Mal einen vollständigen Speicherauszug aus. Wenn Sie sehr viel RAM haben, kann dies dazu führen, dass ein winziger Blip zu einem größeren Ausfall wird.

Sie möchten nicht, dass Ihr Server 1 TB RAM auf die Festplatte schreibt, wenn ein vorübergehendes Problem auftritt. Wenn es ein wiederkehrendes Problem gibt, können Sie die Auslagerungsdatei vergrößern, um einen vollständigen Speicherauszug zu erfassen. Ich würde warten, dies zu tun, bis Sie von PSS (oder jemand anderem qualifiziert, um einen vollständigen Dump zu analysieren) wurde aufgefordert, einen vollständigen Dump zu erfassen. Ein extrem kleiner Prozentsatz von Datenbankadministratoren kann einen vollständigen Speicherauszug analysieren. Ein Mini-Dump reicht aus, um die meisten Probleme zu beheben, die auftauchen.

Plus, wenn Ihr Server so konfiguriert ist, dass ein vollständiger Speicherauszug von 1 TB zulässig ist und ein wiederkehrendes Problem auftritt, wie viel freien Speicherplatz würden Sie empfehlen, zur Hand zu haben? Sie könnten ein ganzes SAN an einem einzigen Wochenende füllen.

Eine Seitendatei 1.5 * RAM war die Norm in den Tagen, als Sie Glück hatten, einen SQL Server mit 3 oder 4 GB RAM zu haben. Dies ist nicht mehr der Fall. Ich belasse die Auslagerungsdatei mit der Windows-Standardgröße und -einstellungen auf allen Produktionsservern (mit Ausnahme eines SSAS-Servers, der unter Speicherdruck steht).

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

Answer 8

In diesem Fall ist die normale Empfehlung von 1,5-fachen Gesamt-RAM nicht die beste. Diese sehr allgemeine Empfehlung wird unter der Annahme gegeben, dass der gesamte Speicher von "normalen" Prozessen verwendet wird, die im Allgemeinen ihre am wenigsten genutzten Seiten auf die Festplatte verschieben können, ohne massive Leistungsprobleme für den Anwendungsprozess zu verursachen, zu dem der Speicher gehört.

Für Server, auf denen SQL Server ausgeführt wird (in der Regel mit sehr viel Arbeitsspeicher), ist der Großteil des physischen Arbeitsspeichers dem SQL Server-Prozess zugewiesen und sollte (falls korrekt konfiguriert) im physischen Speicher gesperrt sein in die Auslagerungsdatei. SQL Server verwaltet seinen eigenen Arbeitsspeicher sehr sorgfältig unter Berücksichtigung der Leistung. Dabei wird ein großer Teil des Arbeitsspeichers als Datencache verwendet, um die Datenträger-E/A zu reduzieren. Es macht keinen Sinn, diese Daten-Cache-Seiten in die Auslagerungsdatei auszulagern, da der einzige Zweck, diese Daten im RAM zu haben, darin besteht, die Platten-E/A zu reduzieren. (Beachten Sie, dass das Windows-Betriebssystem den verfügbaren Arbeitsspeicher ähnlich wie der Festplattencache verwendet, um den Systembetrieb zu beschleunigen.) Da SQL Server bereits eigenen Speicherplatz verwaltet, sollte dieser Speicherplatz nicht als "seitensicher" betrachtet und nicht in eine Berechnung für Auslagerungsdatei einbezogen werden Größe. In Bezug auf MEM_COMMIT, das von Remus erwähnt wird, ist die Terminologie verwirrend, weil "reserviert" sich im virtuellen Speichersprachgebrauch niemals auf die tatsächliche Zuweisung bezieht, sondern die Verwendung eines Adressraums (nicht physischen Raums) durch einen anderen Prozess verhindert. Speicher, der für "committed" verfügbar ist, entspricht im Wesentlichen der Summe aus physischem RAM und der Größe der Auslagerungsdatei. Wenn Sie also MEM_COMMIT ausführen, wird der verfügbare Pool im Commit-Pool verringert. Es tut nicht zuordnen Sie eine übereinstimmende Seite in der Auslagerungsdatei zu diesem Zeitpunkt.Wenn eine festgeschriebene Speicherseite tatsächlich geschrieben wird, dh wenn das virtuelle Speichersystem eine physische Speicherseite zuweist und möglicherweise eine andere Speicherseite aus dem physikalischen RAM auf die Auslagerungsdatei wirft. Siehe MSDN VirtualAlloc function Referenz.

Das Windows-Betriebssystem verfolgt den Speicherdruck zwischen Anwendungsprozessen und seinem eigenen Festplatten-Cache-Mechanismus und entscheidet, wann es nicht gesperrte Speicherseiten von physisch auf die Auslagerungsdatei stoßen soll. Mein Verständnis ist, dass die Tatsache, dass eine Auslagerungsdatei viel zu groß im Vergleich zum tatsächlichen nicht gesperrten Speicherbereich ist, dazu führen kann, dass Windows den Anwendungsspeicher übermäßig in die Auslagerungsdatei auslagert, was dazu führt, dass diese Anwendungen die Folgen von Seitenfehlern (langsame Leistung) erleiden.

Solange der Server keine anderen speicherhungrigen Prozesse ausführt, sollte eine Auslagerungsdateigröße von 4 GB ausreichend sein. Wenn Sie festgelegt haben, dass SQL Server das Sperren von Seiten im Arbeitsspeicher erlaubt, sollten Sie auch die Einstellung für den maximalen Arbeitsspeicher von SQL Server in Betracht ziehen, damit dem Betriebssystem für sich und andere Prozesse physischer Arbeitsspeicher zur Verfügung steht.

802 Fehler in SQL Server zeigen an, dass das System keine weiteren Seiten für den Datencache festschreiben kann. Das Erhöhen der Größe der Auslagerungsdatei wird nur in dieser Situation hilfreich sein, da Windows in der Lage ist, Speicher aus Nicht-SQL Server-Prozessen auszulagern. Wenn Sie zulassen, dass SQL Server-Speicher in dieser Situation in die Auslagerungsdatei hineinwächst, werden die Fehlermeldungen zwar möglicherweise gelöscht, es ist jedoch kontraproduktiv, da der Grund für den Datencache bereits erwähnt wurde.