Können Performanceprobleme entstehen wenn die pagefile.sys kleiner als der RAM ist?
Hallo,
wir haben einen Kunden mit einer Server 2012R2 worauf ein SQL Server läuft. Der ganze Server hat 72GB RAM zur Verfügung. Der Kunde hat den Server so eingestellt das die pagefile.sys bei 1GB anfängt und bis 55GB wachsen kann. Aktuell verwendet das System ca. 51GB RAM. Gilt nicht die Faustregel, pagefile.sys = 1,5 fache Größe des RAMs?
Der Kunde meint es würde am SQL Server liegen dass die pagefile so groß wird. Kann man irgendwie herausfinden was genau den Speicherplatz in der pagefile belegt?
Ich finde leider keinen aktuellen Microsoft Artikel der da genau Stellung zu nimmt wie man das genau einzurichten hat.
wir haben einen Kunden mit einer Server 2012R2 worauf ein SQL Server läuft. Der ganze Server hat 72GB RAM zur Verfügung. Der Kunde hat den Server so eingestellt das die pagefile.sys bei 1GB anfängt und bis 55GB wachsen kann. Aktuell verwendet das System ca. 51GB RAM. Gilt nicht die Faustregel, pagefile.sys = 1,5 fache Größe des RAMs?
Der Kunde meint es würde am SQL Server liegen dass die pagefile so groß wird. Kann man irgendwie herausfinden was genau den Speicherplatz in der pagefile belegt?
Ich finde leider keinen aktuellen Microsoft Artikel der da genau Stellung zu nimmt wie man das genau einzurichten hat.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 301502
Url: https://administrator.de/contentid/301502
Ausgedruckt am: 05.11.2024 um 04:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
wieviel von der Auslagerungsdatei wird denn verwendet?
Ich würde die Datei auf einen festen Wert einstellen, wenn di eDatei dynamisch ist, muss das OS immer nachrechnen ob noch immer alles hinhaut oder nicht und und und..
Die swap auf eine SSD verschieben kann auch noch ein bissel Performance rausholen.
Ob die 55GB reichen zeigt sich wie nahe dieser Wert in Spitzen erreicht wird.
Da es ein Server ist und keine Energiesparmodie gefahren werden, wo der RAM auf die Platte geschrieben wird um beim "neustarten" wieder vollgeladen werden zu können ist das me. egal ob das nun 1x RAM oder weniger ist.
Wenn die Auslagerungsdatei in Spitzenwerten aber nahe an die 55GB kommt, sollte dieser Wert erhöht werden.
Gruß
Chonta
wieviel von der Auslagerungsdatei wird denn verwendet?
Ich würde die Datei auf einen festen Wert einstellen, wenn di eDatei dynamisch ist, muss das OS immer nachrechnen ob noch immer alles hinhaut oder nicht und und und..
Die swap auf eine SSD verschieben kann auch noch ein bissel Performance rausholen.
Ob die 55GB reichen zeigt sich wie nahe dieser Wert in Spitzen erreicht wird.
Da es ein Server ist und keine Energiesparmodie gefahren werden, wo der RAM auf die Platte geschrieben wird um beim "neustarten" wieder vollgeladen werden zu können ist das me. egal ob das nun 1x RAM oder weniger ist.
Wenn die Auslagerungsdatei in Spitzenwerten aber nahe an die 55GB kommt, sollte dieser Wert erhöht werden.
Gruß
Chonta
Ich glaube, das war früher mal so. Ich hab meine Systeme auf "automatisch" stehen und die halten sich da auch nich dran.
Eine Möglichkeit zur Laufzeit den Inhalt der Pagefile.sys auszugeben sehe ich so nicht. Die ist dann exklusiv gesperrt.
Ich finde leider keinen aktuellen Microsoft Artikel der da genau Stellung zu nimmt wie man das genau einzurichten hat.
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.
Der Kunde meint es würde am SQL Server liegen dass die pagefile so groß wird. Kann man irgendwie herausfinden was genau den Speicherplatz in der pagefile belegt?
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.
Ich finde leider keinen aktuellen Microsoft Artikel der da genau Stellung zu nimmt wie man das genau einzurichten hat.
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,
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.
Können Performanceprobleme entstehen wenn die pagefile.sys kleiner als der RAM ist?
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.
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...
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.
sg Dirm
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.
Ich finde leider keinen aktuellen Microsoft Artikel der da genau Stellung zu nimmt wie man das genau einzurichten hat.
es gibt die Richtwerte - zb.: 1.5 x RAM oder du kannst auch analysieren - s. Artikel oben.sg Dirm
nun ja es bleibt jedem selbst überlassen, die Relevanz eines Artikels aus dem Jahre 2008 auf die heutige Zeit zu bewerten... damals war dank Datensparsamkeit Big Data noch kein Thema, und Arbeitsspeicher war da noch richtig teuer.
Einem Server mit 100 GB Hauptspeicher noch 150 GB an Swapspace spendieren zu wollen ist für normale Anwendungsgebiete einfach nur unrealisitsch.
Einem Server mit 100 GB Hauptspeicher noch 150 GB an Swapspace spendieren zu wollen ist für normale Anwendungsgebiete einfach nur unrealisitsch.