Tuning- und Tweaking-Mythen Teil II: RAM Tuning

Im zweiten Teil geht es um das RAM Tuning, welches ja auch oft wahre Wunderdinge verspricht. Mehr freier Speicher für Anwendungen, schnellere Zugriffe, weniger Abstürze.

7. Kernel Auslagerung abschalten.
Der Eintrag in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management–>DisablePagingExecutive soll verhindern, dass Kernel Dateien auf die Platte ausgelagert werden und stattdessen ständig im RAM gehalten werden. Dummerweise handelt es sich bei dem Eintrag aber um einen Legacy Key, der seit NT4 SP3 nur noch aus Kompatibilitätsgründen in der Registry zu finden ist und der ansonsten genau gar keine Wirkung hat, wovon man sich mit einem Blick in den Taskmanger–>Systemleistung–>Kernel Speicher selber überzeugen kann. Egal, ob der Wert gesetzt ist oder nicht, es wird auf jeden Fall ausgelagert. Unter W2K ohne SP4 konnte es bei gesetztem Key sogar zum Abstürzen kommen, falls ein Treiber nicht sauber programmiert war. The DisablePagingExecutive Setting May Cause Windows 2000 to Hang)

8. Nicht benötigte DLL Dateien aus Speicher entfernen.
HKLM\SOFTWARE\Microsoft\ Windows\CurrentVersion\Explorer –> AlwaysUnloadDLL soll bewirken, dass beim Beenden eines Programms nicht mehr benötigte Dateien aus dem Speicher entfernt werden. Tut er bestimmt auch, jedenfalls wie Windows NT. Bei Windows 2000 und XP ist der Key wirklungslos, wie auch in einem Technet Artikel nachzulesen ist: Debugging with the Shell. Der wichtigste Satz daraus lautet: „For operating systems prior to Windows 2000, you can shorten the inactive period by adding the following information to the registry”. Ein schneller Test bestätigt auch, dass nach dem Setzen des Key auf keinen Fall mehr Speicher nach dem beenden eines Programms zur Verfügung steht als vorher.

9. System Cache beeinflussen.
Zwei Veränderungen im Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, nämlich „LargeSystemCache“ und „IOPageLockLimit“ beeinflussen das Caching Verhalten von XP. Tun sie auch und kann sogar sinnvoll sein. Zumindest dann, wenn man einen Fileserver betreibt. Die Empfehlung, bei einer Workstation LargeSystemCache auf 2 und Size auf 3 zu setzen, führt zusammen mit der Veränderung des IOPageLockLimit dazu, dass das System mehr Speicher für Dateisystemoperationen reserviert. Dieser Speicher fehlt dann aber den Anwendungen. Ergebnis: Es wird mehr ausgelagert, das System wird langsamer.

Details dazu finden sich z.B. in der Dokumentation zum W2K Ressource Kit Registry Reference LargeSystemCache“ Zitat: „Increasing the size of the file system cache generally improves server performance, but it reduces the physical memory space available to applications and services. Similarly, writing system data less frequently minimizes use of the disk subsystem, but the changed pages occupy memory that might otherwise be used by applications.”

10. System Page Table Entries erhöhen
Im bereits genannten Registry Key findet sich auch ein Eintrag namens SystemPages. Manche Quellen empfehlen, dort den Wert 0xFFFFFFFF einzutragen, was Windows anweist, das Maximum an PTEs innerhalb des verfügbaren Arbeitsspeichers anzulegen. Dadurch sollen bei großen Datei- und Speicheroperationen Abstürze vermieden werden. Davon mal abgesehen, dass ich bei XP noch nie abstürze bei solchen Vorgängen hatte, obwohl ich den Key nicht verändert habe, verweise ich wieder auf die MS Dokumentation: Registry Reference System Pages. Zitat: “Caution. Do not change the value of this entry. Changing it prevents the system from calculating an optimal value for your system and adjusting the value when your system changes”. Es ist also bestenfalls nutzlos, diesen Wert zu verändern.

11. Speicher aufräumen und defragmentieren.
Das ist einer meiner absoluten Lieblingstipps. Es klingt ja auch logisch und nachvollziehbar. Viel freies RAM ist gut und wenn es am Stück vorliegt, ist es noch besser. Schließlich will man ja sein Bier auch lieber aus dem Maßkrug anstatt aus 50 verteilten Schnapsgläsern genießen. Und so, wie man Festplatten defragmentiert, geht das bestimmt auch mir dem RAM. Dafür bastelt man sich eine VBS Datei mit einer einzigen Zeile „Mystring = (160000000)“. Um Speicher frei zu räumen, legt man sich ebenfalls eine VBS Datei mit der Zeile „FreeMem = Space(32000000)“ an.

Was passiert nun bei Ausführung dieser beiden Dateien? Nichts. Weder wird mir im Taskmanager mehr RAM freies RAM angezeigt noch wird irgendetwas schneller. Wie denn auch? Das erste Visual Basic Script versucht, im RAM eine Variable von 160 MB Größe anzulegen, die dann sofort wieder beim Beenden des Programms gelöscht wird. Das zweite füllt eine Variable namens FreeMem mit einem String von 32 MB Grösse, die ebenfalls sofort wieder gelöscht wird. Was ist die Absicht dahinter? Sehr grob vereinfacht dies: Es wird möglichst viel Speicher belegt. Der Speichermanager teilt diesen auch zu. Zu Lasten anderer Programme, deren bisher genutzte Speicherseiten jetzt aus dem RAM in den Cache oder im Extremfall sogar in die Auslagerungsdatei verschoben werden. Will man also jetzt mit diesen Programmen weiterarbeiten, werden sie langsamer sein als vorher, weil erst die Daten vom Swap- in den Arbeitsspeicher geladen werden müssen. Dazu kommt, das diese „Aufräumaktionen“ völlig überflüssig sind, da der Speichermanager von Windows die Verwaltung weitaus effektiver vornimmt. Mark Russinovich, der Betreiber von Sysinternals und Autor im Windows 2000 Magazin hat in selbigem einen Artikel unter der Überschrift Schlangenöl für den Speicher veröffentlicht, den ich jedem nur empfehlen kann.

Tuning- und Tweaking-Mythen

Alle paar Monate wieder sind sie da, die bunten Zeitschriftencover mit den nicht zu übersehenden ach so geheimen Tricks zum Tunen und Beschleunigen von XP. Hier mal nur eine Auswahl aus den im Juli 2005 aktuellen Titeln: „XP Hacker Tricks“ (PC-Magazin), „XP-Tricks, die sie garantiert noch nicht kennen“ (Chip), „XP-Cheats“ (PC Praxis) und zu guter Letzt auch „Windows ungebremst“ (PC-Welt). Dazu passend gibt es auch eine Unzahl an freien und kommerziellen Tools, die versprechen, mit ein paar Mausklicks XP schneller, besser, schöner, stabiler und überhaupt zu machen.

Was ist aber wirklich dran an all den Tipps? Warum werden sie immer noch als scheinbares Geheim- oder Profiwissen angepriesen, obwohl sie in nahezu unveränderter Form bereits seit den ersten Betas von XP im Netz und diversen Zeitschriften kursieren? Kann man durch ihre Anwendung tatsächlich zu einem stabileren und schnelleren Windows kommen?

Leider lautet die pauschale Antwort darauf: Nein. Entweder ist der „geheime Tweak“ schlicht wirkungslos oder man bezahlt die marginal bessere Performance mit deutlich verminderter Stabilität, also mit einem Windows, das schneller abstürzt. So gesehen ist das natürlich eine Geschwindigkeitsverbesserung….

Natürlich gibt es ein paar Schrauben, bei denen das Drehen daran tatsächlich positive Effekte ohne gravierende Nebenwirkungen zeigt. Ob es sich aber wirklich lohnt, diese Tweaks einzusetzen, ist in den meisten Fällen eher fraglich. Denn die Verbesserungen mögen (manchmal) messbar sein, spürbar sind sie so gut wie nie.

Jetzt kann ich natürlich viel behaupten, ohne konkrete Messungen bin ich dann allerdings nicht besser als die PC-Zeitschriften und Tuning-Programm Hersteller. Deswegen habe ich mir ein dediziertes Test-System aufgebaut, an dem ich die gängigsten der Tipps mal durchprobiert habe. Alle Tests, bei denen ich Zeitangaben liefere, wurden mit diesem Rechner durchgeführt: Dell Optiplex GX280, Pentium IV, 2,8 GHz, Hyperthreading aktiviert, Intel i915 Chipsatz, 1 GB RAM (2*512 MB DDR2 SDRAM), 80 GB HD (S-ATA, WDC WD 800JD, 8 MB Cache), ATI Radeon X300 128 MB PCI-Express, Sound und Netzwerk onboard.

An Software ist installiert: Windows XP Professional mit SP2 und Patches Stand 11.07.2005, Office XP, Acrobat Reader 7.0.2, AVG 7.0, Irfan View., J2SE runtime 5.0 Update 4, Firefox 1.0.4, .NET Framework 1.1 SP1, 7-Zip 4.20

Der Rechner ist Mitglied einer Windows 2000 Domäne und wurde vier Wochen lang intensiv zum Testen von Software und die normale Tagesarbeit benutzt. Es wurden ~60 Programme installiert und wieder deinstalliert. Vor Beginn der Tests wurde per DriveSnapshot ein Image angefertigt, das nach Abschluss der einzelnen Tests wieder zurück gespielt wurde, um einen definierten Zustand zu erhalten. Die Zeit für die einzelnen Aufgaben wurde nicht mit synthetischen Benchmarks gemessen, sondern ganz altmodisch mit der Stoppuhr.

Die getesteten Tipps teile ich relativ willkürlich in folgende Kategorien ein:

1. XP schneller booten
2. RAM Tuning
3. Dateizugriffe beschleunigen
4. sonstige Tweaks
5. Tuning Tools

Los geht es mit:

Teil 1: XP schneller booten.

Durch Anwendung dieser Tipps soll ein XP System schneller booten können. Sehen wir mal, was wirklich dran ist.

1. Bootlogo abschalten.
Mit dem Eintrag /noguiboot in der Boot.ini kann die Anzeige des Bootlogos von XP unterdrückt werden. Das soll einige Sekunden beim Startvorgang einsparen. Der Test bestätigt das allerdings nicht. Gemessen wurde die Zeit vom Einschalten bis zum Erscheinen des Loginbildschirms für je drei Boo tvorgänge

Dauer des Bootens ohne /noguiboot: 30 Sekunden
Dauer des Bootens mit /noguiboot: 30 Sekunden.
Das verwundert auch nicht wirklich, wenn man sich vor Augen führt, dass der Bootvorgang nicht sequentiell abläuft, also eben nicht das Logo für x Sekunden eingeblendet wird, bevor der Bootprozess fortgesetzt wird, sondern dass beides parallel abläuft. Das Laden des Bootbildschirms spielt sich offensichtlich in kaum mess-/merkbarer Zeit ab.

2. Suche nach Freigaben und Druckern abschalten.
Über „Explorer–>Extras–>Ordneroptionen–>Ansicht–>Automatisch nach Netzwerkordnern und Druckern suchen“ soll man die automatische Suche nach Freigaben während des Bootens abschalten. Egal, ob diese Option aktiviert oder deaktiviert ist, das Booten dauerte beim Test so oder so 30 Sekunden.

3. Regelmäßiges Löschen des Inhalts von \%windir%\prefetch.
Windows XP kennt einen Mechanismus namens Prefetching zur Verbesserung der Performance. Eine detaillierte Beschreibung davon findet sich in einem Whitepaper von MS: Fast System Startup for PCs Running Windows XP. Eine Übersetzung der wichtigsten Punkte hat Helmut Rohrbeck erstellt: Helmut Rohrbeck Hompage

Es macht allerdings keinerlei Sinn, den Inhalt des \Prefetch Verzeichnisses von Zeit zu Zeit zu löschen, weil XP die Inhalte von sich aus reorganisiert und überflüssige Einträge entfernt. Im Gegenteil, der Bootvorgang dauert deutlich länger, nachdem manuell gelöscht wurde.

Dauer des Bootens normal: 30 Sekunden
Dauer des Bootens nach Löschen von \%windir%\prefetch: 40 Sekunden

Das verringert sich natürlich wieder, sobald XP einmal seine Leerlaufttasks durchgeführt hat, Sinn macht diese Maßnahme aber trotzdem nicht.

4. Boot Time Defragmentierung einschalten
Das ist per Default bei XP SP2 aktiviert. Trotzdem geistert der Tipp immer noch durch die Fachzeitschriften und Webseiten. Überprüfen kann man das per Regedit. Im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction muß „Enable Y“ eingetragen sein.

5. Bootvis verwenden
Davon kann ich nur abraten. Bootvis kann selbst bei korrekter Verwendung ein System unbrauchbar machen. Microsoft hat nicht ohne Grund den Download dieses Programms wieder von den öffentlichen Servern entfernt. Sofern die normalen Mechanismen wie Prefetching und Boot Time Defragmentierung nicht von Anwender deaktiviert wurden, bringt Bootvis auch keinerlei Beschleunigung.

6. Der Netzwerkkarte eine feste IP zuteilen
Das ist ein Tipp, der bei nicht vernetzten Systemen tatsächlich sinnvoll ist. XP versucht sonst, einen TCP/IP Adresse von einem DHCP Server zu beziehen und verzögert den Bootvorgang bis zum entsprechende Timeout, um sich dann selber per APIPA eine Adresse zuzuteilen. Bei Rechnern in einem Netzwerk mit einem DHCP Server, wie er z.B. von einem DSL Router bereitgestellt wird, bringt das allerdings keine Verbesserung.