Seite 2 - Pagefile-Tuning ohne Registry für Windows XP und Server 2003

Lesezeit
3 Minuten
Bis jetzt gelesen

Seite 2 - Pagefile-Tuning ohne Registry für Windows XP und Server 2003

28.03.2011 - 00:00
Veröffentlicht in:
Betriebssystem missachtet Einstellungen des Administrators
So schlüssig und logisch die "Deaktivierung" der Pagefile auch ist – sie basiert auf einem großen Irrtum. Tatsächlich ist das Betriebssystem beim Client und auch beim Server mittlerweile nicht mehr an die Einstellungen in der Registry gebunden und kann die vom Administrator vorgenommenen Einstellungen jederzeit überschreiben. Um diese Aussage in der Praxis zu überprüfen, reicht ein kurzer Blick auf den Taskmanager nach dem Neustart unseres frisch angepassten Systems (siehe Bild 3). Wie Sie anhand des Screenshots unschwer erkennen, ist im Bereich für die Auslagerungsdatei ein Wert zu finden, der auch im laufenden Betrieb nach oben oder unten variieren kann und wird, jedoch nicht 0 MByte beträgt.

Sollten Sie der Anzeige des Taskmanagers nicht trauen, lassen sich zur Sicherheit weitere Hilfsmittel von Fremdanbietern einsetzen. Hierzu zählen die Demo- und/oder Freeware-Versionen von Everest, SiSoft Sandra, System Info von Gabriel Topala, wie auch eine Fülle anderer Hardwareinventur- Applikationen von weiteren Herstellern.Als Bestätigung zur Anzeige des Taskmanagers haben wir dies mit "Everest Home Edition" überprüft (Bild 4): etwa 690 MByte belegt die Pagefile nach einem Neustart des Systems – eingestellt haben wir jedoch "keine Auslagerungsdatei verwenden". Zusätzlich zum Taskmanager liefern die Tools der Drittanbieter jedoch weitere und sehr interessante Informationen zur Auslagerungsdatei. Wir beschränken uns im weiteren Verlauf des Artikels auf die von Everest ermittelten Werte, andere Applikationen liefern jedoch identische Angaben, so dass es letztendlich Ihnen überlassen ist, welches Werkzeug Sie einsetzen möchten.

Wir können also mit einer Vielzahl von Analyse-Applikationen den schlüssigen Beweis erhärten, dass das Betriebssystem, auch wenn vom Administrator explizit anders eingestellt, immer mit einer frei konfigurierten und dimensionierten und – das ist besonders wichtig – im Dateisystem nicht sichtbaren (als PageFile.sys) Auslagerungsdatei arbeitet. Zusätzlich sehen wir bei der Systemanalyse mit Fremdanbietertools, dass Systeme mit unterschiedlicher Speicherbestückung vom Betriebssystem aus mit einer dynamischen, maximal nutzbaren Größe der Auslagerungsdatei versehen werden. In unserem Beispiel sehen Sie diesen dynamischen Wert in Bild 4 in der rechten Spalte unter "Auslagerungsdatei / Gesamt: 2.396 MByte".


Bild 4: Auch Drittanbieter-Tools wie Everest Home bestätigen, dass Pagefile trotz anderer Einstellungen noch existent ist

Die Funktion der Auslagerungsdatei sollte beim Einsatz von Windows XP, Server 2003 (auch R1) und Windows Vista neu überdacht werden. In der Praxis bedeuten die gewonnenen Erfahrungen, dass es – wie auch im vorherigen Beitrag erläutert – mittlerweile keine Notwendigkeit mehr gibt, an der vom Hersteller vorgegebene Formel fest zu halten (Startgröße der Pagefile = 1,5 x RAM, die Endgröße entspricht der zweifachen Startgröße). Die Diskussion, wie die Pagefile zu dimensionieren ist, ist also in Bezug auf Windows-Systeme ab XP eigentlich hinfällig. Etwaige Tuning-Tipps, die noch aus der Zeit von Windows 95,Windows NT und Windows 2000 stammen, müssen uns nicht mehr kümmern und können sogar den gegenteiligen Effekt haben.

Praktische Umsetzung der gewonnenen Erkenntnisse
Die Art und Weise, wie die neueren Betriebssysteme die Pagefile verwalten, sollten Sie bei der Optimierung eines Systems berücksichtigen. In einem etwa zwölf Monate andauernden Test bei Industriekunden, die einige oder alle der hier besprochenen Maßnahmen umgesetzt haben (auf der Client- wie auch auf der Serverseite) haben wir folgende Erfahrungswerte gewonnen:

  • Das Arbeiten ganz ohne Pagefile (Einstellung von 0 MByte für die Größe) ist in seltenen Fällen möglich und in der Praxis riskant. Es gibt eine beachtliche Anzahl an älteren Applikationen, die das Vorhandensein einer echten, im Dateisystem eingetragenen Pagefile.sys erwarten. Ist die Datei nicht vorhanden, ergeben sich eine Fülle – nicht immer eindeutiger – Fehlermeldungen.
  • Eine bestimmte Größe für die Pagefile, wie etwa durch die Konvention von Microsoft vorgesehen, ist nicht erforderlich. Erst recht nicht, wenn ein Client über 1 GByte RAM oder mehr verfügt. Bei Servern ist die Thematik anders zu betrachten: Eine zu große Pagefile kann und wird den Rechner beim Hochfahren und unter Umständen auch beim Herunterfahren stark ausbremsen. Dazu gibt es eine ganze Reihe an Problemen, die explizit mit der Pagefile zusammenhängen und sich durch eine korrekte Dimensionierung nachhaltig beheben lassen.
  • Beim Client genügt in über 95 Prozent der Fälle eine feste Größe für die Pagefile von 500 MByte und zwar als Start- und Endgröße. Dies ist nicht abhängig vom installierten Arbeitsspeicher, sofern der Rechner über mindestens 768 MByte RAM verfügt. Clients mit weniger RAM können mit einer größeren Pagefile versehen werden (800 MByte sind hier sehr praxistauglich)
  • Wichtig: Eine kleine Pagefile bedeutet nicht, dass das System irgendwann an die Grenzen dieser Pagefile stößt. Vielmehr ist das Betriebssystem dynamisch in der Lage, über den vom Administrator eingestellten Wert bis zum maximal möglichen Wert zusätzlichen Speicher anzufordern und zu belegen, wenn dies erforderlich werden sollte. In sehr seltenen Fällen kann es jedoch bei älteren Applikationen vorkommen, dass Sie die Pagefile über unsere Empfehlung hinaus anpassen müssen. Dies ist in der Regel immer dann der Fall, wenn eine Applikation mit der dynamischen Größenzuweisung durch das Betriebssystem nicht zusammenarbeitet oder diese nicht erkennt.
  • Bei Servern sollten Sie die Größe der Pagefile der Funktion des Servers anhängig machen. Ein File- und/oder Printserver kann eine kleine (500 MByte) Pagefile vertragen. Bei Applikationsservern sollten Sie die Herstellerempfehlungen für die jeweilige Applikation befolgen – hierbei ergeben sich individuelle Abhängigkeiten bezogen auf die verwendete Applikation und dem installierten Arbeitsspeicher, wie auch der Größe der zu verwaltenden Daten (bei einem DB-Server) oder der Anzahl gleichzeitiger Nutzer (bei Terminal- oder Citrix-Servern). Aufgrund dessen lässt sich keine pauschale Empfehlung abgeben.



<<Vorherige Seite                Seite 2 von 3                     Nächste Seite>>






ln/jp/Nikolay Taschkow

Ähnliche Beiträge

Im Test: Heimdal Patch & Asset Management

Ein zeitgemäßes Patchmanagement darf sich angesichts der vielfältigen Bedrohungen nicht allein auf die Microsoft-Produkte konzentrieren, sondern muss sich auch verbreiteten Drittanbieteranwendungen widmen. Der dänische Anbieter Heimdal Security geht noch einen Schritt weiter und hat eine ganze Suite zum Schutz vor Cyberbedrohungen im Programm. Mit dem Fokus auf das Patchen haben wir uns das cloudbasierte Angebot genauer angesehen.

Device-Management mit Microsoft Intune und Office 365 - Zwei Wege, ein Ziel

Um Geräte im Netzwerk oder mobile Geräte, die auf das Netzwerk zugreifen, zu verwalten, bietet sich für Unternehmen entweder Office 365 Mobile Device Management oder Microsoft Intune an. Ein Unterschied zwischen den beiden Lösungen besteht vor allem im Preis. Während das Device-Management zu vielen Abonnements in Office 365 gehört, muss Microsoft Intune gesondert abonniert werden. In diesem Beitrag stellen wir beide Ansätze vor.