Können Performanceprobleme entstehen wenn die pagefile.sys kleiner als der RAM ist?

Ich glaube, das war früher mal so. Ich hab meine Systeme auf "automatisch" stehen und die halten sich da auch nich dran.
Der SQL-Server verbleibt im RAM. Der wird nicht ausgelagert (oder kaum), denn dies wäre eine Verschlechterung.
Eine Möglichkeit zur Laufzeit den Inhalt der Pagefile.sys auszugeben sehe ich so nicht. Die ist dann exklusiv gesperrt.
Du kannst höchstens mit einem Speicherscanner "Prozess Lasso" oder Process Explorer" Dein Glück versuchen.
Der virtuelle Arbeitsspeicher dürfte ebenfalls "adressiert" sein und in den höheren Adressen zu finden. Vielleicht gibt das Aufschluss. Aber das ist nur eine Mutmaßung.

Hi,
Nein.

Nur wenn der RAM zu wenig ist und deshalb ausgelagert werden muss. Wenn die Größe des Pagefile auf "Systemverwaltet" steht, dann belegt Windows nur soviel, wie es in der Spitze benötigt. Das Pagefile wird dabei aber nicht wieder verkleinert. Heißt in Deinem Fall, dass das Sytsem schon mal bis zu 51 GB auslagern musste. Das Argument, dass ein "vorgefertigtes" Pagefile schneller sei, als wenn es erst bei Bedarf dynamisch erstellt/vergrößert wird, ist zwar nicht ganz falsch, aber auch nicht die ganze Wahrheit. Der Engpass ist die Notwendigkeit zum Auslagern an sich. Wenn ein Computer für seine Aufgaben ausreichend RAM hat, dann muss er nicht oder nur wenig oder nur bei Spitzenbelastungen auslagern. Wenn diese Spitzen nur sporadisch sind, z.B. bei seltenen, größeren Abfragen oder beim Wartungstask in der Nacht und wenn während dieser Zeit der Server nicht zu langsam reagiert, dann ist das OK.
Ich würde mir den Performance Counter "Page Fault/s" anschauen. Je kleiner, desto besser. Hinweis: "Page Fault" ist kein "Fehler" in diesem Sinne. So wird eine Speicher-"Seite" bezeichnet, welche im RAM erwartet wurde, welche aber erst vom Pagefile geladen werden musste.

E.

Du hast die ganze Zeit, die der Server bisher lief, die RAM-Belegung aufgezeichnet?
Wenn nicht: Kannst Du ausschließen, dass der Speicher nicht doch mal knapp geworden sein könnte, bei irgendeiner Aktion?

Paging ist immer schlecht für SQL server und sollte tunlichst unterblieben.

Und das verhindert man sinnvoll dadurch daß man dem SQL Server den Arbeitsspeicher abzüglich 2 oder 4 GB fest zuteilt.

Hauptgrund ist daß der SQL Server ja (in den allermeisten Fällen) nur Daten im Speicher cacht, und diese Daten verwirft wenn sie längere Zeit nicht abgeholt werden. Und da stand mal in nem MS Whitepaper "Ram = 20% der Datenbankgröße". Erlaubt man dem SQL Server aber 2 TB Speicher zu allozieren, dann tut der das irgendwann auch mal, aber in der Regel ist das nicht mehr als 100% der Datenbankgröße - wenn denn die User alle Daten querbeet abrufen.

Es ist aber effektiver, wenn der SQL Server die Daten dann erneut vom Storage liest... dem SQL Server paging zu erlauben wäre nur dann vertretbar wenn z.B. Views oder komplexe SQL Befehle ohne den zusätzlichen Speicher im Pagefile GARNICHT ausgeführt werden können.

Das beste Pagefile ist halt eins das von Applikationen ungenutzt ist, und dem Windows-Kernel kann man das Paging nicht wirklich abgewöhnen...

Hi

hier ist ein recht ausführliche Artikel Serie:
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-t ...
Ev. reserviert Windows einfach nur 55GB für die Pagefile weil sie "eh brach" liegen oder ist der Speicher knapp auf dem Server? Crashdump, ... pagefile hat nicht nur die eine Aufgabe.

Wie groß ist denn die gesamte DB? - 55GB, dann liegt sie komplett im RAM und gut ist's.

es gibt die Richtwerte - zb.: 1.5 x RAM oder du kannst auch analysieren - s. Artikel oben.

sg Dirm