Systemoptimierung leicht gemacht (2)

Lesezeit
3 Minuten
Bis jetzt gelesen

Systemoptimierung leicht gemacht (2)

21.03.2011 - 00:00
Veröffentlicht in:
Im ersten Teil dieses Online-Workshops haben wir uns mit drei Themenfeldern beschäftigt, die für eine optimierte Festplatte wichtig sind: dem Datendurchsatz der Platte, der Dimensionierung der C-Partition sowie der Fragmentierung und Clustergröße. Im zweiten Teil unseres Online-Workshops zur Systemoptimierung gehen wir genauer auf die Auslagerungsdatei ein und erklären, warum die Standardeinstellungen für die Auslagerungsdatei nicht immer optimal sind und wie Sie diese an den Einsatzzweck Ihres Servers anpassen
Da die Auslagerungsdatei Pagefile.sys plattengebunden ist, ergeben sich daraus teilweise massive Verzögerungen beim Lesen und Schreiben von Speicherinhalten. Welche Position der Pagefile.sys am sinnvollsten ist, ist sogar innerhalb der offiziellen MS-Unterlagen der Knowledge Base nicht ganz unumstritten. Auf die genaue Position kommen wir jedoch später im Text zu sprechen, es geht uns erst einmal um das Berechnen der korrekten Größe dieser Datei, da die Default-Werte des Systems einige Tücken in sich bergen.

Auslagerungsdatei korrekt berechnen
Die Größe der Auslagerungsdatei wird bei der Installation von Windows XP und den Servervarianten dynamisch in Abhängigkeit vom installierten Arbeitsspeicher eingerichtet. An jedem System lässt sich über die Systemsteuerung über "System / Erweitert / Systemleistungsoptionen" die aktuelle Größe der Pagefile einsehen. Um die Größe und die Position manuell zu ändern, können Sie die Registry nutzen, Sie können jedoch auch über den Button "Ändern" die Einstellungen (siehe Bild 1) öffnen.

Nachteile der Default-Werte
In diesem Menu lassen sich die Default-Einstellungen modifizieren. Nach dem Willen des Herstellers existieren immer eine Start- und eine Endgröße (eine Ausnahme stellt hier Vista dar, hier wird der Wert automatisch vom System ermittelt und verwaltet). In der Praxis führt dies dazu, dass die Auslagerungsdatei innerhalb der vorgegebenen Grenzen wachsen kann. Durch dieses teilweise unkontrollierte Wachstum fragmentiert die Auslagerungsdatei, womit die Lese-/Schreib-Performance noch einmal kräftig verringert wird.

Parallel dazu fragmentiert zwangsläufig auch die gesamte Partition, welche die Pagefile beinhaltet (in der Regel das Installationslaufwerk, sofern ausreichen freier Plattenplatz vorhanden ist). Im Unterschied zu Windows NT 4.0 hat Microsoft mit der Einführung von Windows 2000 die Problematik eingesehen und zugegeben, dass auch NTFS- und NTFS-5-Partitionen stark fragmentieren und es sinnvoll ist, diesem Verhalten entgegen zu wirken. Deswegen finden wir auch das länger bekannte Tool Diskeeper als Bestandteil des Systems, wenn auch in einer optisch etwas abgewandelten Form, wieder (das Defragmentierungstool bei Vista ist zwar das gleiche, liefert jedoch nicht mehr das von XP und Windows 2000 gewohnte visuelle Feedback).

Wie können wir also diesem Verhalten entgegenwirken? Hierzu einige grundsätzliche Überlegungen:
  • Da die Größe abhängig vom installierten Arbeitsspeicher ist und die Default-Endgröße abhängig vom Startwert ist, empfehlen wir die Start- und die Endgröße gleichzusetzen.
  • Davon abweichend bestimmt das System von sich aus den Startwert der Pagefile mittels der Formel 1,5 mal RAM, wobei sich diese Formel als sehr statisch erweist und nur den bei der Installation des Systems vorgefundenen Arbeitsspeicher berücksichtigt.
  • Beim Aufrüsten eines Clients oder eines Servers werden die Werte nicht dynamisch der neuen Speichergröße entsprechend angepasst.
  • Genau so statisch ist auch die Definition des "Endwertes" der Pagefile, welcher immer das Doppelte des Startwertes ausmacht (sollten Sie mit Windows 2000 arbeiten, so gilt hier die Formel Endwert = dreifacher Startwert und nicht zweifacher Startwert).
Korrekte Dimensionierung der Pagefile
Aus dem oben geschriebenen geht hervor, dass ein direkter Zusammenhang zwischen RAM und Pagefile-Größe existiert. Dieser Zusammenhang führt jedoch dazu, dass das System an physikalische Grenzen stoßen kann, beziehungsweise die vom System empfohlenen Werte bisweilen abenteuerlich anmuten. Insbesondere gilt dies für Systeme (Client, wie auch Server), die über mehr als 2 GByte RAM verfügen. Da insbesondere 1 GByte RAM mittlerweile ein "üblicher" Wert sogar bei XP-Clients ist, sollten wir uns anschauen, welche Empfehlungen daraus das System ableitet, genau so, wie bei Servern mit 4 GByte RAM oder mehr. Auffällig hierbei ist auch die Tatsache, dass Sie oftmals den Empfehlungen gar nicht Folge leisten können. Versuchen wir die Größe der Pagefile den Systemempfehlungen folgend zu ändern, so werden wir oft mit einer Fehlermeldung konfrontiert.

Technische Limits bei der Dimensionierung der Pagefile.sys
Im TechNet und der Knowledge Base finden sich reihenweise Artikel zur Größe der Pagefile, die übereinstimmend eine maximale Größe von 4.095 MByte (nicht 4.096 MByte) pro Pagefile-Datei definieren. Dafür kann ein System pro Partition oder logischem Laufwerk jeweils eine Pagefile beherbergen, in der Summe jedoch maximal 16 einzelne Dateien (fast 64 GByte insgesamt) – sofern Sie so viele einzelne (auch logische) Laufwerke eingerichtet haben.

Das ist auch gleichzeitig die Lösung für viele bekannte Probleme und einige (wenn auch seltene) Blue Screen-Meldungen des Systems. Sie sehen auch anhand der oben genannten Formel schnell, dass ein System mit 2 GByte RAM schlecht eine Pagefile von 6 GByte (am Stück) eingerichtet bekommen kann, da diese Dateigröße das technische Limit des Systems sprengt und damit die Pagefile mit 6 GByte nicht nutzbar ist. Bei einem System mit 4 GByte RAM errechnet sich der Formel entsprechend sogar eine 12 GByte große Pagefile (am Stück), was genauso sinnlos wäre.




                                                Seite 1 von 2                     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.