Hoe om te gaan met Pagefile?*

[BlakHawk]

Jaja, het is altijd een discussiepunt
Iedereen heeft er een andere mening over...


Vroeger zei Microsoft, doe het geheugen x 1,5. Tegenwoordig zien we in KB artikelen terug dat de pagefile minder belangrijk wordt, naar mate het fysieke geheugen groeit. Tja, niets concreets verder.

We draaien hier zo'n 500 servers op VMware en daarnaast nog een aantal fysieke bakken.
We hebben hier vanwege standaardisering gekozen voor een 5GB disk, met 4GB pagefile. Eigenlijk ondervinden we nooit problemen met betrekking tot geheugen.

Toch laait de discussie weer op, van zet maar helemaal uit, tot doe 1,5 keer de grootte van het geheugen en alles wat er tussen in zit.

MAar wat is nu het enige juiste antwoord!?

[Rupie]

Ik pas de titel even aan naar iets met wat meer inhoud

[Paul]

Staat op die disk van 5 GB een pagefile van 4 GB of hoe moet ik dat zien? Door (met name) de WinSXS-folder heb je binnen de kortste keren al te weinig aan een systeempartitie van 60 GB

Wij laten het altijd door Windows zelf managen, dat blijkt (ongeveer) uit te komen op 1x de hoeveelheid RAM.

[mieJas]

Paul schreef op dinsdag 17 april 2012 @ 10:19:
Wij laten het altijd door Windows zelf managen, dat blijkt (ongeveer) uit te komen op 1x de hoeveelheid RAM.

Wij bij de kleinere servers ook. Bij de clusters met > 256 GB RAM is het fixed op 1/8 van het geheugen. Anders trek je dat qua diskruimte niet.

[ Voor 6% gewijzigd door mieJas op 17-04-2012 10:23 ]

[Bor]

Uit zetten is nooit een goed idee. Sommige software kan hier niet mee om gaan en mijn ervaring is met zakelijke applicaties dat het vroeg of laat toch fout gaat. 1,5 x gaat ook al tijden niet meer op; tenminste niet bij een 64 bits OS. Daarover zijn bij MS wel KB artikelen en blogs te vinden. Het beste advies is de workload te analyseren maar dat is niet heel erg makkelijk / snel / simpel.

Je vraagt een enig juist antwoord: die is er niet.

[ Voor 6% gewijzigd door Bor op 17-04-2012 11:12 ]

[Question Mark]

Paul schreef op dinsdag 17 april 2012 @ 10:19:
Door (met name) de WinSXS-folder heb je binnen de kortste keren al te weinig aan een systeempartitie van 60 GB

Dat valt voor een server toch wel iets mee? Ik neem tenminste aan dat je niet dagelijks allerlei installaties uitvoert waarbij meerdere versie van bepaalde DLL's bewaard moeten blijven. Houd er verder ook rekening mee dat de meeste files in de WinSXS-folder zogenaamde hardlinks zijn. Het fysieke bestand staat dan gewoon in bv. je system32 folder. Tooling die directory grootte's bepalen rekenen dan met de grootte van het fysieke bestand, terwijl de link qua grootte niets voorsteld.

Zie bv ook: WinSXS Folder not actually consuming lots of space

[Paul]

Die heb ik allemaal al 100x gelezen. Dat het ding geen ruimte inneemt moet je maar tegen Windows Verkenner en (daaraan gerelateerd) onze monitoring roepen die zeggen dat er geen vrije ruimte meer is. Of tegen onze Exchange-bakken, die stopt mail te accepteren als er minder dan x% vrij is

Waren het maar hardlinks, dan was er niet zo'n probleem. Het zijn wel degelijk heel veel bestanden, allemaal met een ander versienummer, plus nog een paar GB aan overhead, backup, manifestcache, temp etc... Ook als ik alle mappen bij elkaar optel kom ik precies uit op (diskspace) - (free space).

As for meevallen: 10 GB op een SBS 2008 van oktober 2009, 6,6 GB op een SBS 2011 van nog geen maand oud, 5,2 GB voor een Web Server Edition van juni 2010.

Toegegeven, op een werkstation is het meer en misschien was mijn 60 GB wat overdreven (dat was voor een SBS waar MS standaard _alles_ op C: zet), maar ik kan het niet weinig noemen. En eerlijk gezegd boeit het me niet eens zozeer welke map nu precies het bestand heeft en welke map de hardlink, het gaat er om dat er zo ontzettend veel versies worden bewaard. En waarom? Voor die paar MB aan DLL's die je ook in de programmafolder kunt zetten in het zeldzame geval dat er inderdaad een conflict is.

Voor dfrenner van belang ivm zijn 500 VM's en zijn SAN provisioning, voor een hoop 'computer enthousiasts' vanwege hun SSD etc ...

Maar goed, dat gaat wel offtopic in een topic over de pagefile

[BlakHawk]

Paul schreef op dinsdag 17 april 2012 @ 10:19:
Staat op die disk van 5 GB een pagefile van 4 GB of hoe moet ik dat zien? Door (met name) de WinSXS-folder heb je binnen de kortste keren al te weinig aan een systeempartitie van 60 GB

Wij laten het altijd door Windows zelf managen, dat blijkt (ongeveer) uit te komen op 1x de hoeveelheid RAM.

We hebben nu aparte disks gedefineerd van 5GB groot, voor de VM's. Deze disks worden geexclude uit de SMVI backup.

De pagefile die daarop staat is maximaal 4GB groot. De minimale waarde vult de ene anders in dan de ander... Daar ontbreekt het dus aan procedures, zodoende laaide de discussie op over pagefile gebruik.

Aangezien we templates gebruiken, is het heel handig dat de pagefile gestandaardiseerd is. Geen aanpassingen achteraf aan deze settings noodzakelijk. Echter nemen we het nu opnieuw onder de loep. Vandaar de vraag.

Per server gaan bekijken is echt ondoenlijk... Aangezien we nu ook niet echt problemen ondervinden is dat misschien ook niet noodzakelijk.

[Question Mark]

Paul schreef op dinsdag 17 april 2012 @ 12:02:
Of tegen onze Exchange-bakken, die stopt mail te accepteren als er minder dan x% vrij is

Ik mag toch hopen dat je je mailstores niet op de C-drive hebt staan

[/offtopic]

Voor de rest kun je een pagefile niet echt standardiseren, het is nl. vaak applicatieafhankelijk. Zo is de recommended pagefile voor Exchange 2010 machine nl. gelijk aan de grootte van het interne geheugen + 10 MB. Voor een simpele fileserver kan dit veel minder zijn.

[ThomVis]

Op servers zetten wij de pagefile op 2GB fixed, ongeacht het fysieke geheugen. Als applicaties de PF echt gaan gebruiken (meestal alleen MS apps als exchange, sharepoint ed) zetten wij het op een andere waarde.
Per applicatie moet je het bekijken, bijvoorbeeld SQL claimt al zijn beschikbare geheugen, dus het OS denkt snel dat geheugen vol zit en wil gaan pagen. Als je dan alleen het OS bewaakt zou je snel geneigd zijn geheugen en/of pagefile te vergroten, terwijl SQL misschien helemaal niets met het geheugen doet. Limiet binnen SQL omlaag stellen: Problem solved.
De applicatiebeheerders die beginnen te morren over de 2GB limiet vertellen we dat we de boel gaan monitoren. Bij "problemen" vergroten we de pagefile, maar meestal lost het niets op: Terug -> 2GB. De meeste niet MS producten gebruiken de standaard geheugenmanager van het OS (ipv rechtstreeks de PF aan te spreken), en daarbij helpt geheugen toevoegen veel beter als pagefile aanpassen, mocht geheugen het probleem zijn.

[Paul]

Question Mark schreef op dinsdag 17 april 2012 @ 12:55:
Ik mag toch hopen dat je je mailstores niet op de C-drive hebt staan

Ooit een pre-installed SBS gezien?

Het ging trouwens niet om de store (die al lang naar D: was verhuist) maar om de queues.