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

Lesezeit
3 Minuten
Bis jetzt gelesen

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

28.03.2011 - 00:00
Veröffentlicht in:
Das System leert die Pagefile nicht richtig
Ein weiterer wichtiger Punkt für Clients und Server ist eine sowohl direkt über die Registry mögliche, wie auch in den Sicherheitsrichtlinien ab XP vorkommende Einstellung, die das Löschen (Überschreiben) der Inhalte der Pagefile beim Herunterfahren eines Rechners ermöglichen soll. Dieser Punkt ist von besonderer Bedeutung. Lassen Sie uns dies etwas genauer erklären: Die Pagefile kann verschiedene Datenarten aufnehmen. Dies kann zum Beispiel ein Druckauftrag (vollständig oder nur in Teilen) sein, Fragmente eines Benutzerprofils, Zertifikate für das Web, Treiber oder Treiberkomponenten (Kernel-Mode-Treiber), benutzerbezogene Einstellungen einzelner Applikationen (etwa MS Office) wie natürlich beliebige Speicherinhalte, was ja der eigentliche Zweck der Pagefile sein soll. Wird beim Herunterfahren eines Rechners die Pagefile nicht gelöscht (Standardeinstellung bei Client und Server), wird der zur Laufzeit angesammelte Datenberg nicht oder nur teilweise entfernt, beziehungsweise als für das System als nicht mehr relevant gekennzeichnet.

Beim Hochfahren des Rechners lässt sich mit einem Microsoft-Tool namens "Bootvis" sehen, dass der Startvorgang auch ein Lesen der Pagefile beinhaltet. Beachten Sie jedoch beim Einsatz von Bootvis speziell auf Servern, dass Sie vor der Installation alle WMI-basierenden Dienste deaktivieren. Nach erfolgreicher Systemanalyse und der Deinstallation von Bootvis können Sie diese wieder aktivieren. Je größer die Pagefile, umso länger kann der Startvorgang hinausgezögert werden. Dies ist an sich noch kein Problem, zu einem Problem wird jedoch die Interpretation mancher Dateninhalte aus der Pagefile und deren Auswirkungen auf das startende oder laufende System. Was genau ist damit gemeint? Hier einige Beispiele:

  • Haben Sie schon einmal erlebt, dass ein abgesendeter Druckauftrag als erledigt in der Warteschlange gekennzeichnet, jedoch nicht ausgeben wurde? Und, dass das Dokument erst nach dem Herunterfahren und Neustart des Clients oder Servers – teilweise mit einer Verzögerung von bis zu 30 Stunden – auf einmal ausgedruckt wird?
  • Haben Sie Clients, die neu definierte Richtlinien nicht oder nach einem scheinbar zufälligen Muster annehmen? Oft klagen Administratoren darüber, dass Richtlinien nicht übernommen werden.
  • Probleme mit dem Aktualisieren von Zertifikaten?
  • Benutzerprofile, die schnell beschädigt werden und neu anzulegen sind?
  • Probleme bei der Treiber-Installation?
  • Sporadisch auftretende Wartezeiten beim Zugriff auf Netzwerkressourcen?
  • Sporadisch auftretende Probleme der Berechtigungsstruktur auf Freigaben?
  • Sporadisch auftretende lange Wartezeiten beim Ausdrucken über Printserver?
Alle oben genannten Probleme lassen sich oft, wenn auch nicht immer ausschließlich, mit der Pagefile in Verbindung bringen. Gerade die letzten drei genannten Punkte konnte ein Industriekunde zu 100 Prozent eliminieren, indem er auf seinen File- und Printservern die Größen der einzelnen Pagefiles auf feste 500 MByte reduzierte und die Inhalte der Pagefiles beim Herunterfahren löschte. Die Praxis zeigt recht überzeugend, dass das Löschen der Pagefile beim Herunterfahren eines Rechners die Häufigkeit aller oben genannter Probleme im Schnitt um bis zu 85 Prozent zu senken vermag. Damit das Herunterfahren eines Clients jedoch nicht für den User zum Geduldspiel wird, sondern maximal 6-10 Sekunden länger als gewohnt in Anspruch nimmt, ist es sinnvoll, die Größe der Pagefile auf die bereits weiter oben genannten 500 MByte einzugrenzen. Eine kleinere, der Nutzung eines Rechners angepasste Pagefile, ist also tatsächlich ein praxiserprobter Weg.


Bild 5: Das Löschen der Pagefile beim Herunterfahren des Systems bewerkstelligen Sie
am besten über eine Gruppenrichtlinie


Hingegen ist das in der Vergangenheit oft diskutierte Dimensionieren der Pagefile mit Bezug auf den verbauten Arbeitsspeicher heute nicht mehr sinnvoll und nur in wenigen isolierten Fällen noch von Belang. Auch ist das bei manchen Serverapplikationen recht beliebte Anlegen von mehr als einer Pagefile (bis zu 16 Dateien maximal; mit einer maximalen Größe von 4.095 MByte und nicht 4.096 MByte) nur in wenigen Sonderfällen nötig. Es kann sich wirklich lohnen, bestehende Systeme auf die Dimensionierung der Pagefile hin zu untersuchen und gegebenenfalls mittels eines kleinen Skriptes in der Registry eine neue globale Größe für eine Vielzahl von Clients, wie auch Servern zu bestimmen. Das Löschen der Pagefile, beziehungsweise das Löschen/ Überschreiben der Inhalte der Pagefile (die Datei selber wird natürlich nicht gelöscht) können Sie einfach und bequem mittels Richtlinien definieren.

Fazit
Wie Sie sehen können, erfüllt die Auslagerungsdatei eine Fülle von Aufgaben. Durch die gestiegene Komplexität der Applikationen und der Betriebssysteme kann es jedoch oft zu ungewollten Nebeneffekten kommen, da alte Datenbestände zur Laufzeit oder beim Hochfahren eines Rechners von der Pagefile geladen werden. Wie Sie dies verhindern, haben wir aufgezeigt genau so, wie wenig Aufwand es erfordert, um die nötigen Anpassungen vorzunehmen und wie einfach es im nach hinein ist, die vorgenommenen Modifikationen zu dokumentieren. Der tatsächliche Vorteil ist in der Praxis recht hoch und sollte es zu Problemen kommen, können Sie sehr schnell alle vorgenommenen Änderungen wieder rückgängig machen.

Wichtig ist nur, dass Sie Ihr System, sei es ein Client oder ein Server, vor dem Anpassen der Größe der Pagefile gründlich defragmentieren. Damit eine möglicherweise bereits bestehende und über mehrere Abschnitte fragmentierte Pagefile dies nicht verhindert, kann es sinnvoll sein, die Pagefile neu auf ein anderes Laufwerk auszulagern, oder wenn keine weiteren Laufwerke verfügbar sein sollten, das System kurzfristig und nur für das Defragmentieren komplett ohne Pagefile einzurichten.



         <<Vorherige Seite                          Seite 3 von 3





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.