Server 2012 R2 Pagefile.sys fast 50GB

Bruzla

Captain
Registriert
Okt. 2013
Beiträge
4.035
Servus zusammen,

ich hab gerade mal wieder das Problem, dass auf einem unserer virtuellen Terminalserver das Pagefile sehr groß ist.

Ich würde jetzt in den Einstellungen für den virtuellen Arbeitsspeicher eine benutzerdefinierte Größe festlegen, so 10GB.

Spricht da was dagegen? Reagiert Windows da vielleicht empfindlich?
Ich könnte auch "Auslagerungsdateigröße für alle Laufwerke automatisch verwalten" wählen.

Danke euch!

Edit: Der RAM ist nie voll, gerade sind 10 von 30GB belegt.
 
Andere Frage:
Wie viele User?
Wie viel RAM habt ihr?
Was bedeutet "sehr groß" ?
 
1,5 fache vom RAM
 
  • Gefällt mir
Reaktionen: borizb
50GB ist das Papgefile, steht im Titel.
30GB RAM, User aktuell 7 Stück, MAXIMAL 35.
 
1,5xRAM = Pagefile

Unabhängig von der aktuellen Auslastung, bei Prozessen die keine PAE Unterstzützen, gehen maximal 3,xGB und der rest geht ins Pagefile. Ist das zu klein = Anwendung schmiert ab.
Wenn du sicher weißt das alle Prozesse 64Bit sind --> Kleineres Pagefile denkbar.
 
LasseSamenström schrieb:
1,5 fache vom RAM
So groß? Das wären 45GB Pagefile, in den Windowseinstellungen steht, dass 7400MB empfohlen sind.
Ergänzung ()

Naja, das wusste ich nicht!
Wenn das quasi so in Ordnung ist, dass das Pagefile so groß wird, dann geb ich der Kiste einfach ein bisschen mehr Festplattenspeicher.
 
Selbst Microsoft beschreibt das in ihren Artikeln so
 
LasseSamenström schrieb:
1,5 fache vom RAM

Falsch! Längst veraltet und auf einem 64bit System absolut unsinnig.
1597397456797.png

https://docs.microsoft.com/de-de/windows/client-management/determine-appropriate-page-file-size

Grundsätzlich stellt sich dabei nur die Frage ob du einen Speicherdump beim Absturz haben möchtest und in welchen Umfang er ausgeführt werden soll.
1597397606084.png


Auf einem Terminal Server ist es auch zu überlegen, die Auslagerungsdatei komplett zu deaktivieren, vor allem wenn der Datenträger auf einem SAN oder ähnlichen übers Netzwerk angebunden Speichergerät liegt.
 
  • Gefällt mir
Reaktionen: Bob.Dig und Yuuri
Ich hab mir ja eben gedacht, es kann doch nicht normal sein, ein 50GB Pagefile zu haben auf einem Terminalserver der auf flotter Hardware läuft.

Ich hab gerade gesehen, auf nem anderen Server ist der Haken bei "automatisch Verwalten" aktiv, da hab ich keine Probleme.
Dann setzt ich den Haken jetzt mal bei der anderen Kiste auch.
 
Nein, es spricht nichts dagegen, den Wert fest einzustellen.

Aus der Erfahrung her: Lass es auf Systemverwaltet und mach die C:-Partition größer. Wenn nichts auf C: liegt kann es zu Problemen kommen. Und auch mit einem festen Wert gab es schon Probleme, sofern der Wert bei einer RAM Erhöhung nicht angepasst wurde. Es könnte unter Umständen bis zu 2x RAM von der Pagefile Size belegt werden und noch mal 1x RAM für den MEMORY.DMP (je nach Windows Version: sofern der nicht auf Minimum umgestellt wurde, bzw. von Minimum auf voller Dump umgestellt wurde). Von der Erfahrung her wurden aber auch beim vollen Dump nicht die volle RAM Menge gespeichert, sondern eher so maximal 8GB (bei Systemem mit auch mal 32 oder 64GB RAM). Wichtig ist: C: muss groß genug sein, dass eben SWAP und MEMORY.DMP drauf passen.
 
Okay! Ich hab der Platte jetzt 50GB mehr Speicher gegeben und die automatische Verwaltung wieder aktiviert, muss nur noch neustarten..
 
@xexex
Im nächsten Artikel steht schon wieder was anderes:
https://docs.microsoft.com/de-de/windows/client-management/system-failure-recovery-options

1597398230684.png


Im Artikel davor (https://docs.microsoft.com/de-de/windows/client-management/introduction-page-file)
Für Windows Server 2012 Hyper-v und Windows Server 2012 R2 Hyper-v sollte die Auslagerungsdatei des Verwaltungsbetriebssystems (gemeinhin als Hostbetriebssystem bezeichnet) standardmäßig auf "System verwaltet" festgelegt werden.

Schätze Microsoft ist sich selbst nicht einig, aber das kennt man ja schon...
 
Steht da bei ausgelagerter Pool auch 50 GB?
Windows vergisst oft die Pagefile wieder kleiner zu machen.

Ich hab auch schon Server gehabt die viel auslagerten, da hab ich einfach eine SSD eingebaut und dort eine fest pagefile erstellt.
 
Bruzla schrieb:
Ich hab mir ja eben gedacht, es kann doch nicht normal sein, ein 50GB Pagefile zu haben auf einem Terminalserver der auf flotter Hardware läuft.
Wenn ich ein großes Bild in Photoshop öffne sind auch 30+ GB nur für Photoshop im RAM keine nennenswerte Größe. Es ist doch einzig relevant was für Anwendungen ausgeführt werden. Wenn der RAM knapp wird, schmieren die halt mit ner Fehlermeldung ab.

Willst du lieber das Szenario von einem unzuverlässigem System mit abstürzenden Anwendungen und definitiv vorprogrammiertem Datenverlust haben?

Das Pagefile zu verkleinern ist nie eine Option, da es nur Symptombekämpfung mit fatalen Nebenwirkungen ist. Falls du Anwendungen mit Memory Leaks nutzen musst, analysier lieber das und schick dem Entwickler nen Report. Ein Neustart der Anwendung kann da temporär helfen.
 
Es laufen exakt die gleichen Anwendungen wie auf dem anderen Server: ERP, Office, Browser, PDF.

Ich hab die Platte vergrößert und lass die Einstellung auf automatisch.
 
LasseSamenström schrieb:
Schätze Microsoft ist sich selbst nicht einig, aber das kennt man ja schon...

Aus deinem Link
Page files in Windows with large physical memory
When large physical memory is installed, a page file might not be required to support the system commit charge during peak usage. For example, 64-bit versions of Windows and Windows Server support more physical memory (RAM) than 32-bit versions support. The available physical memory alone might be large enough.

However, the reason to configure the page file size has not changed. It has always been about supporting a system crash dump, if it is necessary, or extending the system commit limit, if it is necessary. For example, when a lot of physical memory is installed, a page file might not be required to back the system commit charge during peak usage. The available physical memory alone might be large enough to do this. However, a page file or a dedicated dump file might still be required to back a system crash dump.
 
@Bruzla Guck in den Task Manager und zieh ggf. RAMMap zu Hilfe. Irgendwo muss es ja einen Auslöser dafür geben. Das System selbst wird den RAM ja kaum beanspruchen, dass dort ein entsprechend großes Pagefile existiert. Falls exotische Hardware genutzt wird, kann sich der Treiber dort natürlich auch entsprechend am RAM Pool beteiligen und Speicher leaken. Das lässt sich mit RAMMap herausfinden. Glaub hier bei CB hat Hisn dazu auch mal nen Guide geschrieben...

Ich bin auch schonmal nen Montag auf Arbeit gekommen, wo sich ein Firefox 30+ GB RAM gegönnt hat... Neu gestartet, gut wars. Problem war, dass eine Seite pro Sekunde nen Request gemacht hat und der Browser das ganze WE durch lief. Die Garbage Collection hat dort wohl nicht so wirklich funktioniert.

Und falls du das Problem findest, kannst du wie gesagt ggf. den Entwickler benachrichtigen oder die User anweisen, dass es Problem X gibt und sie sich wenigstens einmal an Symptombekämpfung Y erinnern sollen, damit ihr nicht sinnlos Kosten verursachen müsst, was eigentlich kein Problem darstellen sollte. Oder falls möglich die Anwendung wechseln, mit der es auftritt. Falls das nix hilft, notfalls die Anwendung im Leerlauf zwangsweise abschießen und neu starten.

Aber ich denke, dass man da einfach mit leben kann, insofern es sich hier nicht um mehrere hundert GB handelt. Wobei ich mir das bei nem Terminalserver durchaus vorstellen kann... Hab damit allerdings kaum Erfahrung im Praxiseinsatz.

Imho verkleinert sich das Pagefile im laufenden Betrieb auch nicht, zumindest hab ich es noch nie beobachten können und ich hab darüber auch noch nichts gelesen. Also wenn ich jetzt viel RAM beanspruche, dann bleibt das Pagefile bis zum nächsten Restart bei seiner entsprechenden Größe, auch wenn die Anwendung bereits längst geschlossen wurde.
 
Hey, nochmal Danke an Alle, die mir hier Tipps und Meinungen dagelasse haben.

Ich hab die Verwaltung wie gesagt auf Automatisch gestellt und sicherheitshalber die Platte erweitert, heute sind wieder viel mehr User online und die Auslagerungsdatei ist anstatt 50GB nur 30GB groß, variiert immer um ein paar GB, aber jetzt scheint das ja zu funktionieren.
 
Zurück
Oben